A. 怎么样使用支付宝手机网页支付接口
摘要 商户系统按照手机网站支付接口alipay.trade.wap.payAPI的参数规范生成订单数据，然后在前端页面通过Form表单的形式请求到支付宝。
B. 接微信支付还需要自己开发对账系统和订单管理系统吗
当然需要自己开发啊
C. 订单拆单的流程中，系统需要做哪些工作
什么是拆单？
在网上购买商品下单成功后，过一段时间再次浏览时，有时会发现你的订单会变成两个或多个，这就是系统做了拆单而导致的。
拆单，就是将一个大的订单依据某些规则的集合，将其分解成两个或多个子订单的过程，原来的订单称之为父订单。
拆单的重要性
通常我们所说的拆单一般情况下是指用户的销售订单，但在实际业务中，拆单情况随处可见，如采购订单的拆分、调拨单的拆分等等。本篇后续都是以销售订单的拆单讲述的，请知悉！
在互联网电商系统中销售订单是与C端用户关联最紧密的，单据量是最大的，是影响用户体验的，且拆单的规则相对来说是比较复杂的。
折单要求数据 准确、及时 ，因为拆单后的子订单是需要流入到仓储进行生产作业的，它会进行 拣货、出库、配送 等一系统的流程， 它也是后续财务系统对账或结算、数据分析的重要数据来源 。
拆单的场景
用户在APP等平台下单后，由于商品的库存数量不满足，可能在前端进行拆单，即用户自己选择是否需要拆单，可以按 最快送达 或 最小拆单 的规则进行。
看到这里您可能会有点疑惑， 库存不足时还能下单吗？ 现在很多网站上当商品不足时用户需要自行修改数量，然后才能下单。
确实如此，现在这种场景少了，但是有的商家为了提升客户体验，对于商品可以多仓发货时。因为单仓缺货而需要拆单时，由用户来选择决定是否购买，这应该也是为了 提高转化率 的一种方式。
还有一种场景，订单涉及多商家，需要单独付款的情况下，前端会直接进行拆单，但现在基本上都是合单支付了，这种拆单会使用户体验降低。
此外，有的商家既卖国内商品，也卖海淘商品，如果都混在一块，那么在支付前是需要进行拆单的，因为海淘商品要求用户的身份认证等信息的检验。
在多数情况下，都是用户下单完成后，由系统进行在后台进行拆单，拆单是要结合公司业务场景去考虑的。
用户购买涉及几种拆单
拆单除了以上几种场景，对于用户下单时系统上还会有什么操作吗？
有一种情况即用户下单时系统要根据用户选择的收货地址、商品等信息，判断是否有库存，订单应该归属哪个仓库，是否可以购买等，这个服务严格来讲应该归属于商品库存服务，但是也可以将其称为 预拆单 。
预拆单一般是调用仓储服务进行库存的判断，同时还要根据促销活动进行一些优惠计算，所有的这些都需要前端系统在处理时对订单商品进行一些标识，以便当用户支付成功后，订单流转到OMS系统进行物理拆单。
前端用户下单成功后，订单经过OMS的拉单服务快速流转到订单中心，便开始订单的再生成过程，订单拆分后的子订单会展示给用户，原订单一般不需要再展示，便于用户跟踪和查看。
所以在从用户角度来看，一种是可以直接看到结果的拆单和一种无感知的预拆单过程。
拆单的时点与地点
预拆单是伴随着购物流程进行的，这里不多讨论，因为这个究竟是否属于拆单也是要看我们如何定义。正常情况下用户选购商品完成后，系统不会拆单，因为用户有可能取消订单或未支付成功。
拆单的时点是要在 "订单支付成功" 后进行，且需要前端订单已经流转到后端生产库，在订单中心进行处理。
在前面有一种场景，如果购物中心不能合并支付时，在购物车中便拆分为几个订单，这时的拆单可以定义为 一次拆单 ，也可以归属于购物流程，因为用户不提交就不会生成订单号，不会保存各个订单的数据。
在用户支付成功后，各个订单同样是要向后台流转，经过拆单服务的处理才可以继续进行下面的生产。
在前面讨论拆单场景时提到一种 缺货拆单 ，这种场景的拆单是在用户下单支付成功后，订单有可能已经拆分为不同的子订单，但因某种原因仓库无货而导致的拆单。
这时拆单的时点是灵活的，一般是在客服系统中，根据用户的反馈确定是否拆单的。
缺货是影响用户体验的，但是缺货是始终客观存在的。
拆单分几级
从上图看，拆单应该为 三级 ，即用户创建的订单为父订单，然后经过拆单服务正常的分为多个子订单为第二级，后续因为缺货等原因子订单再次拆分为子（孙）订单。
在数据设计上，一般情况子订单与父订单的关联都通过ParentID来进行关联，但三级以上时，涉及原始订单的查询较麻烦。
具体看数据结构如何设计了，可以再增加一个原始订单号来记录最初的订单号，方便统计查询等，负责拆单服务的同学可以详细讨论下。
为了避免订单的复杂度及系统的查询、统计、分析等数据处理的难度， 订单最好最多到三级，不宜过多 。
拆单状态
以前专门梳理过订单状态的文章，详见《 订单信息与状态流转看这个应该足够了! 》,在拆单过程中也涉及订单状态的变换。
当父订单拆分为子订单后，子订单生效，父订单应该置为无效。
子订单或父订单经过缺货拆单后，原订单状态是无效还是其它？
订单拆单后状态应该置为“待下发”即需要通过下发服务，将订单推送给仓库发货。
如果订单已经下发到仓库后需要缺货拆单，单据状态应保留原状态。
这些都属于细节，但不得不考虑，因为订单的状态涉及到其他业务系统的计算和统计。
如：财务系统在应付报表时是根据支付订单进行统计和对账的，如果订单状态是无效的，那么系统如何获取此部分数据。
BI有些统计分析是按状态和订单数量等进行统计的，如客单价、有效订单数等等。
所以针对拆单而导致的订单状态是否应该区分原有的订单状态分别标识，是需要综合考虑的。
拆单原则
拆单的原因我们已经清楚，拆单的目的是为了保证履单，拆单的原则是什么？
首先是最小拆单原则， 即能拆两单，不能拆成三单，因为多拆一单不仅是单据数量的增加，它会增加系统的复杂度，降低用户体验，加大仓库作业量，增加运费费用等。
最快送达原则， 拆出的子订单要快速生产，快速送达，这个是增加用户体验的最好办法。但是快速送达，依赖于仓储物流的布局，这个在多仓可以发送到一个城市时尤为重要。
一般情况下，拆单要遵循这两条原则，同时我们也看到拆单服务，是依赖于基础信息配置的，电商系统最复杂的是很多地方都有关联。
拆单规则
拆单的规则因每个公司的业务不同而不同，这里罗列一些常见的规则供参考。
（1）不同商家的订单需要进行拆分
这个主要应用于平台型的电商，一般情况用户购买商品都进入不同的店铺，创建的订单也是归属这个商家的。但有的平台采用合单支付，即用户选购不同商家的商品，但支付是一次的。
这个和淘宝有些不同，淘宝上每个商家的收款账号是不同的，所以不能一次支付，但平台商家是平台代收款的，所以可以一次支付后再拆单分摊金额。
（2）不同仓或不同供应商的商品需要进行拆单
仓库不同订单需要分开，对于不同的供应商订单主要是指由供应商直接发货的订单即商品不存储在仓库，由供应商直送到用户，这个和平台商家类似。但是区别是签署的合同不同，一个是购销合同，一个是佣金扣点合同，细节不展开了，有兴趣可以留言交流。
（3）商品类型不同需要拆单
一般区分奢侈品或有特殊要求的商品，这个需要业务根据商品要求进行设置。因为商品要求不同，后续在物流环节采用的物流产品类型也不同，物流费用也不同。这部分也可以根据商品信息，在仓储进行处理，但最后在上位能够提前区分。
（4）商品温控属性不同要进行拆单
此部分一般是指生鲜电商而言，同一个仓库有常温仓、冷藏仓、冷冻仓，存储着不同的商品，商品的拣货、包装等都有不同的要求，所以需要进行拆单。
（5）大件商品拆单
大件商品与普通商品不同，它在仓库的存储位置、拣货方式、包装、运输都有所区别，所以大件商品需要每一件都拆单，大件商品一般遵循最快送达，不需要最少拆单原因的限制。
（6）根据库存拆单
这个是针对缺货商品进行的拆单，即有库存的一单，无库存的一单，如果是二级订单，则父订单相同，子订单衍生出子订单，子订单1的过程。
（7）线下门店商品不拆单
如果是线下门店购买商品，则不需要拆单。
（8）组合商品不能拆单
在促销活动中，有时会有一些大礼包等商品的组合销售，即A,B,C等商品经过仓库的组合包装后出库，所以针对此类商品不能拆单。
在拆单服务中需要调用物料单信息，进行判断，具体的要看系统如何设计了。
拆单的规则很多，在系统处理时，要依赖于规则设置的优先级来进行。
拆单算法
（1）稀缺商品算法
找所有商品在所有库房最稀缺的商品，获取该商品的阶数。
（2）降阶
找稀缺商品的都需要仓库组合，这些仓库是必须发货的，把这些仓库计入发货列表，这样就降阶了，剩余仓库再计算组合，减少运算数量。
（3）抽屉原理算法
找第一阶的仓库列表（发货量最大的仓库），这个库房的库存是必须要发的，然后再找次发货量最大的仓库，以此类推，用于后面的组合计算。
（4）找组合
按照仓库顺序逐渐增加仓库个数找组合。
算法也只是拆单过程中的一个路径参考，且算法依赖于拆单的规则而制定，无论如何要保证拆单的结果准确，拆单的速度要快。
拆单服务两步重要工作
以上一直在讨论拆单是由 1变2 ，由 2变4 的一些内容，在具体的拆单服务系统中要考虑哪些内容， 又有哪些工作？
前面所说的都应该在设计时考虑，而且最重要的是要依赖规则进行设计，数据的流转，时序等等。
金额分摊是拆单中最重要的一部分工作，也是最复杂的。
父订单的拆分，商品的重新组合，生成新的订单是第一步，第二步就是要将父订单的金额合理的，正确的分摊到各个子订单上。
订单一般分为订单主表和订单商品表、订单支付明细表和订单活动表。
订单金额有几个主要的部分 ：订单商品金额、折扣金额、礼品卡支付金额、积分支付金额、优惠券支付金额、订单支付金额等几个部分。
运费 是订单表中一个特殊字段，运费如何分摊是要特殊考虑的，一般情况是按金额占比进行。所以生成的子订单中各部分金额，也要保证与父订单金额一致。
订单商品表、支付明细表、活动表属于明细信息，要根据原始订单明细表的数据和标识进行计算分摊。
子订单的金额要保证 横向、纵向 都正确才行， 横向 是指子单的合与父单金额一致， 纵向 是指子单订单主表与明细表金额一致。
此外，在金额分摊计算过程有一项重要规则不可避免，即开票金额的考虑。
这部分金额的分摊与公司缴税息息相关，单据与发票要一致，要考虑商品信息、活动规则等等，非常复杂。
有的拆单服务将金额分摊独立出来，以降低对拆单的影响，提高订单流转速度。
拆单的速度要求
由于拆单后订单才会下发到仓储或商家进行生产，所以对于速度要求就是 快 。
在系统设计时可以依据规则等综合考虑，多线程是最常用的方法，但多线程需要考虑资源竞争和安全性。一般情况，如果下单后已经确定了仓库，那么可以按仓库启动多个服务，这样可以避免程序的难度。
对于拆单和下发在系统上也要有数据监控，不能出现积压的情况。如果拆单有异常时，在定时任务中，很多情况都是依赖一个信息字段的状态来进行循环处理，在服务中要有 容错处理 ，不能一直停滞不前。
拆单的影响
什么是拆单？为什么拆单？如何拆单？前面说了很多， 但对于拆单有什么影响呢？
先说一个场景，公司搞促销活动，买A赠B，但A与B商品的温控属性不同，所以用户下单后一定会拆单。
拆单后仓储拣货、发货是根据子订单进行的，很有可能赠品B先发货了，A后发货。用户先收到B签收了，然后A进行拒收或取消。此时，如果在拒收或取消A时不判断关联子订单，那么公司就会损失B。
如果判断关联子订单的状态，那么系统的复杂度将会非常之大，因为实际场景中一个父单拆为多单时是很常见的。
拆单后，子订单数量增加，对于客单价、统计分析等报表需要考虑其影响，维度和统计口径不同，数据结果必然不同，从而会影响到经营分析及决策。
影响，对于不同的业务有不同的理解，作为产品研发应该在拆单设计时还是需要要将利害与业务说清楚，尤其是运营人员(活动方面重点考虑），虽然这属于一个后台服务。
总结
拆单是复杂的，合理的拆单会加快订单的流转，友好的用户体验，过度拆单则会产生冗余的数据，增加订单的复杂关系，统计、计算、售后等各个环节。
以上是我对拆单的一次梳理与总结，感谢您的阅读！
D. 单页网站在线订单付款系统怎么制作
1必须在支付宝处进行申请，，难度很大
2通过支付宝给的API以及相关技术文件，针对你目前这个网页的接口来进行交接
3对接成功，搞定。
最后，你是弄不成的。你这个网页估计是静态的，不可能做成支付端，
然后你真要做先得弄个动态的，然后再和支付宝做一个技术上的接入，，
E. 交易单号和商户单号一样吗
不一样。
交易单号为支付系统的订单号，由支付系统生成，并在回调时传回给商户，用于回调，也可查询订单状态。商户单号为商户平台的订单号，一般在商户平台生成，自己可以设计自己的规则，如通过时分秒等生成随机数订单一般不重复
。
(5)前端支付有商户订单系统吗扩展阅读
交易单号记录的是网上交易所产生的资金流向，一般只做为银行和支付平台之间的对账，个人一般不会用到这个单号。
但是当有特殊的情况之时，如遇到手机充值话费后流量未到账，购买的充值卡未收到以及参与优惠活动等与微信支付相关的问题时，此单号可以作为充值后的交易凭证，来辅助解决相关问题。
此单号作为唯一的交易凭证，请妥善保留，交易成功后，请不要基于删除交易单号，以备不时之需。
交易状态解释：
1、待买家支付——买家还未完成支付；
2、订单已关闭——订单已作废（买家还未完成支付）；
3、买家已支付——买家已完成支付；
4、交易结束——交易已完成；
5、全额退款——已将订单的全额退还给用户。
F. 支付系统设计小结
支付作为平台最核心的基础能力，其重要性不言而喻。
对于平台而言，支付功能最简单粗暴的实现方式是业务系统直接接入支付渠道，支付和业务耦合在一起。流程见下图。
但随着业务的多样性和复杂度的变化以及业务量的提升，需要有独立的系统来维护支付规则，管理支付渠道，记录支付信息。因此引入支付系统，业务流程升级为：
在一个消费者付款流程中，支付系统需完成以下任务：
1、接受业务系统的业务订单；
2、根据业务订单类型及金额判断可支持的支付产品并返回给前端页面，让用户选择；
3、根据用户选择的支付产品，选出具体执行扣款的支付渠道；
4、根据选出的支付渠道要求组装指令，调用渠道执行扣款任务；
5、获取支付渠道通知的扣款结果或主动查询通道扣款结果；
6、通知业务系统支付结果；
以上6个任务在具体执行中可以分化出以下几个单体：
1、支付应用
平台交易每天有无数订单，支付系统需要将订单进行分类。不同类型的订单对支付渠道有着不同的需求，可以将订单类型对支付渠道的需求规则维护在支付应用层。
支付应用提供给上层业务统一模块化的调用方式，业务层而不再需要关注支付的实现。一般来说，支付应用可分为： 即时消费（消费类订单），充值（钱包类业务），转帐（钱包类业务），提现（钱包类业务），退款（异常情况处理）等。
2、支付核心（支付产品）
支付核心将下游支付渠道自身带有的原子化功能（鉴权，签约，扣款等）封装后提供给上游统一调用。上游通道仅需明确具体支付产品和金额后，由支付核心根据路由选出的渠道的接口要求组装指令，调用渠道支付接口。
支付核心应封装渠道包括验证要素，支付额度，手续费，结算账户，查询方式等属性。也要能新渠道接入的可扩展性，屏蔽各渠道的差异，将渠道差异统一维护在单个系统中。
3、支付路由
用户选择支付产品后，可以有多个支付渠道支持对应支付产品。系统需要根据特定逻辑选出具体的支付通道去执行扣款，而这个特定逻辑就是支付路由。
这里至少要包括以下几个逻辑：
1) 指定走某条通道、指定不走某条通道；
2) 选出限额满足订单金额的支付通道；
3) 选出手续费较低的通道；
4) 现有的支付要素是否满足通道要求，是否仍需要用户参与。
另外，支付应用中支持的具体支付产品，也可在路由中实现。
4、渠道管理
支付路由，和支付核心都需要根据通道特性进行判断，可以独立维护一个系统来记录通道的特性。当通道属性发生变化时，比如需要参数发生变化，费率发生变化等，通道维护时，可以在渠道管理系统中配置相关信息即可，而不需要重新发版。
基于上面的讨论，可以抽象出下面两张模型图。
支付模型
支付系统
以上仅是收款环节的设计概述，其中仍有很多单体可以展开来讲，快捷产品设计，支付路由，账户系统等等，有机会再提。
以上仅是个人在实践中的总结，如有不对的地方，还请指正。
G. 简谈订单管理系统(OMS)
订单管理系统即处理订单的系统，主要管理订单的输入，处理，输出。其在一般电商系统中或在有交易功能的系统中，都是核心系统/功能之一，有一定的复杂度；但是虽然复杂，并不代表理解起来困难。
关于商品的文章里面，我们已经从商品的输入、维护、输出的流程来介绍了商品系统，那订单也一样，我们本文把订单看成一个流程即订单流来理解。
订单系统会与购物车、商品系统，营销系统、会员系统、支付系统、物流系统、仓库系统、财务系统、内容系统，具体请看示例图：
1. 购物车 ：个人认为是订单的起点，商品会被加入购物车，然后会被提交
2. 商品系统： 在提交订单页面会看到该订单所包含的商品信息，例如商品名称、所购买数量、价格、售后信息等
3. 营销系统： 会显示商品是否优惠信息，例如满减、优惠券
4. 会员系统： 会显示该会员是否有基于会员等级的折扣信息(如淘宝的88会员)，或是否有可抵扣金额的会员点数(如京豆)；会显示该会员下面的收货地址信息、也会显示该会员下面是否有充值卡、运费券等。
5. 仓库系统： 基于收货地址信息显示发货仓库，自提地点等，并且订单最终会流转到该系统进行发货操作。
6. 支付系统 ：显示支付方式(如货到付款、在线支付等)、并且在支付的时候计算该会员实际应付的金额，以及显示银行卡信息等。
7. 物流系统： 显示配送时间、配送方式、运费等，并且在订单发货后会显示实际的配送路径。
8. 财务系统： 显示开票信息等，在订单完成后会生成发票。
9. 内容系统： 显示订单留言等
个人认为订单的输入(亦可称之为来源)可分为内部和外部两种方式：
1. 内部： 即自建商城传输过来的订单；
a. 自建商城的订单系统涉及的其他系统比较多，基本上上图所示的系统都涉及到了。
b. 自建商城订单在订单创建时有着更多的判断逻辑，如是否需要事先拆单的、优惠信息是否可用、商品库存是否满足要求、会员是否正常等
c. 内部订单由于存在支付的动作，所以会有多出待付款，待评价这2个状态，
d. 内部订单由于涉及支付和营销，所以对订单系统的并发能力、负载能力以及支付能力有相当高的要求，每一步都不允许出错，一旦出错就意味着营业额的损失和用户的流失。
e. 订单数据计算和处理的要求更高，商品多少金额，优惠了多少金额，抵扣了多少金额，实付多少金额等都需要准确计算，在财务报表内能够清晰展示。
2. 外部： 即第三方系统传输过来的订单，一般代表性的就是分销订单，如供应商的订单系统会接收外部系统的订单，
a. 第三方系统传输的订单，由于订单比较独立，所以涉及的相关系统会少很多。
b. 第三方订单在订单接收时主要判断传输方是否有资格，商品是否上架状态，库存是否满足，收货人信息是否完整等。
c. 由于该类订单相对来说不需要很高的实时性(意思是该类订单对于消费者来说已经付款了，现在只是后端处理)，所以对接口负载性能等要求相对就没有那么高。
d. 订单数据处理方面，一般都是线下核对账单，线下结算款项，所以主要在数据记录和处理的准确性方面有很高要求。
以上就是订单的输入，接下来我们聊订单的处理。
个人认为主要有3种处理方式：
1. 流转处理
在订单系统内，系统会对订单进行各种逻辑规则判断，判断后就会根据业务规则分发订单，可简单看示例图：
基本上订单的流转处理是秒级，甚至是毫秒级就能处理完毕的，不能处理的或者处理失败的都会把订单归类到异常订单。
下面是订单各状态的流程图：
2. 发货处理
订单一般流转到仓库进行发货操作，发货后仓库会把物流信息回传到订单系统，订单系统接收消息后会对订单进行发货：
a. 如果是内部订单则订单状态直接改变(消费者端也会同步看到订单状态变化)；
b. 如果是外部订单则会通过接口告诉第三方系统该订单的物流信息；
3. 特殊情况处理
在特殊情况下，就需要对订单进行人工处理，例如订单无法流转到下一级、订单有备注等。人工处理的结果可能是跟消费者协商后让其退款，也可能是手动的传输订单等。
1. 内部订单：
内部订单的完成并不在发货后就完成，一般来说在客户接收到订单商品后即算完成。但是对不同类型的商城有所区别：
a. 自营商城：一般客户收货后就完成订单，例如京东。
b. 非自营商城：客户需要自己点击确认收货或经过一段时间后系统自动确认收货。
2. 外部订单：
外部订单系统订单一般在发货后就算完成。
1. 在我们设计订单系统的时候应该先思考下公司业务类型和逻辑，理清业务上订单流的起止。理清后从订单源头开始设计订单系统：
a. 如果是自建商城类的那么订单模块会涉及到其他系统，需要与其他系统的产品经理(如多人)去讨论，如何让订单系统与他们负责的系统进行对接；如果是供应链类型的订单系统，则需要考虑如何让订单能够从外部顺利传输到系统，是我们提供统一标准的API呢还是我们去各自对接第三方系统等等。
b. 考虑输入方式后，我们就要依据公司业务运营方式来考虑订单的处理逻辑，订单进入系统后如何 让系统自动处理订单，依据什么规则；同时也要考虑对异常订单的处理。
c. 在考虑好订单处理逻辑后，就要考虑如何输出订单，是直接输出给WMS还是会再输出给其他ERP等等。由于是自动化的输出，也就要考虑与其他系统的对接方式。
d. 最后，我们就要用把公司业务代入到系统内，看看是否能行程闭环，是否还有欠缺或者是否遗漏了细节等。
2. 订单管理系统涉及的其他系统比较多，所以在系统设计上应该具有独立性、拓展型和准确性，独立性代表订单系统的维护或者异常不会影响到其他系统；拓展型代表订单系统在以后增加功能的时候方便快捷；准确性是指订单数据涉及到财务方面，所以应该严谨和准确。
3. 后台系统订单页面的设计：
a. 订单列表页面的设计
根据公司业务需要来设计列表页展示的数据和布局，以及筛选查询的关键字段，具体可看示例图：
b. 订单详情页的设计
订单详情页一般来说是模块化的展示设计，订单基础信息、商品信息、物流信息、支付信息等都需要有所区分，这样设计有利于详情快速查看以及在系统研发的过程中让开发小哥哥不容易搞错哦，具体可看示例图：
c. 订单规则设计
订单规则根据业务的大小有简单和复杂，所以具体需要看业务规模。如果公司现阶段刚起步，则订单规则可直接写进订单系统；如起步有一段时间了或者发展比较快，则可事先就开发好订单规则模块，以后有新的订单规则直接通过运营人员设置即可，更加的方便和更快速的适应业务的发展。
H. 前端订单拆分和支付功能用到了什么技术
支付的话您可以使用支付宝的沙箱支付
I. 小程序对接哪家第三方支付
这要根据小程序而定，例如网络小程序可以对接：商家需要有自己的智能小程序，需要接入网络钱包、微信支付、支付宝等第三方支付，完成支付闭环。
第三方支付平台提供一系列的应用接口程序，将多种银行卡支付方式整合到一个界面上，负责交易结算中与银行的对接，使网上购物更加快捷、便利。第三方支付整合了后端各大银行的不同支付接口，对外提供统一的接入平台，方便商户接入。
商户已有小程序，在小程序上展示商品或服务，用户在小程序内下单或享受服务使用支付时，商户发起本服务通过服务商下单，由服务商呼起微信支付并完成支付。在此支付过程中，作为具有一定开发能力的普通服务商，协助小程序上的商家完成入驻、支付接入、技术开发及其他相关工作（如分账、分润、退款等）。小程序商户接入普通服务商，有两种接入方式：由服务商新申请特约商户方式（以下简称特约商户）以及绑定已有微信普通商户方式（以下简称普通商户）。两种方式下，服务商都是作为商家与微信支付之间的连接者，服务商本身不经手资金，支付成功后资金直接进入特约商户商户号，无论哪种接入方式，当前微信支付的普通服务商仅面向通过微信认证的企业类型服务号开放申请，服务商主体需与小程序主体一致。需要通过小程序的APPID获取微信支付的能力。
J. 各支付SDK流程
一、微信支付
微信支付官方流程链接： https://pay.weixin.qq.com/wiki/doc/api/app/app.php?chapter=8_3
简要来说流程如下：
1.用户点击商品下单：“商户客户端”调用“商户服务端”生成订单，“商户服务端”后台调用“微信支付系统”的“统一下单API”接口，生成预付订单后，返回给“商户服务端后台”，商户后台再回调给“商户客户端”。
2.用户确认支付：“商户客户端”调用“调起微信支付”接口，界面跳转到微信进行支付。
3.用户支付成功：这里有三个回调，其一、“微信支付系统”通知“商户管理后台”支付信息。其二、“微信支付系统”通知“微信客户端”支付结果。其三、“微信支付系统”通过“商户客户端”实现的回调中处理支付状态，“商户客户端”可通过调用“商户管理后台”的接口查询当前订单状态。（商户管理后台也需要调用“微信支付系统”查询订单接口）
二、支付宝支付
支付流程图：
支付宝支付对比微信支付流程还进行了简化，即在生成订单时，不需要商户后台请求支付宝生成订单，基本流程如下：
1.“商家APP”请求“商家后台”下单，“商家后台”返回订单信息。
2.“商家APP”根据订单唤起“支付宝App”进行支付。
3.支付成功后，“支付宝支付后台”返回支付结果给“支付宝App”，“支付宝App”返回支付结果给“商家App”、“支付宝支付后台”异步通知支付结果给“商家后台”。
三、苹果支付
流程图：
支付流程：
1.用户点击购买，“App客户端”请求“App服务端”创建交易订单。
2.“APP客户端”拿到交易信息，然后开始调起“IAP 服务器”创建订单。
3.“IAP服务器”通知购买成功，并把收据信息写入APP沙盒中。
4.“APP客户端”去沙盒中拿到收据信息，并将收据信息上传到“APP服务器”,“APP服务器”把收据信息请求“IAP 服务器”验证，如果有则返回到“APP客户端”，把订单结束。
参考链接： https://juejin.im/post/5a3b14f36fb9a045104aa6c8