订单视角看支付
支付是指为清偿商品交换和劳务活动所引起的债权债务，货币债权从付款人向收付人的转移的过程。支付能力是电商产品的核心能力之一，作为订单同学，有必要了解关联域支付的流程以及基本概念，同时支付领域的很多设计思路与资损防控经验对订单域的系统设计也很有借鉴意义。本文将从支付系统的历史、基本概念、系统设计、资损防控与订单与支付交互等方面予以介绍。
一
支付系统历史与演进
支付的历史演进可以追溯到现金交易的起源。随着时间的推移和科技的不断进步，支付系统经历了多个阶段和变革。
起源：票号与钱庄
票号是应埠际汇兑需求而开设的金融专营机构，主要经营存款、汇款、汇兑三大基本业务，是现代银行的雏形。客户在票号交了银子之后，票号就开出汇票给客户。客户可以随身携带汇票而不用携带大量的银子，只要凭票就可以到全国各地的分号兑出银子。分号给客户兑换之后先内部记账，各分号间定期会当面进行对账。镖局就专为票号来运送银子、为商人运送票据。在这种模式下，汇票+账本（手工记账）是票号在支付环节的信息载体，解决了信息流问题；镖局替票号运送资金，解决了资金流的问题。
第一阶段：手工联行（1989前）
早期，国内的金融环境没有达到让央行推行全国统一结算制度的客观条件。于是央行当时提出商业银行要“自成联行系统，跨行直接通汇，相互发报移卡，及时清算资金”。同一家银行的总行及分支机构称为“联行系统”。同一联行内的资金结算，由联行总行自己做。跨行业务可以由央行清算，也可以由商业银行自己清算。在这种模式下，各银行需要告知其他行的交易信息构成了特定的公文，加盖印鉴后在银行间传送。这种公文叫做联行信件，而当时的邮电局则承担了收发联行信件的重要业务。
联行信件整个过程基本都是手工处理，与明清时期的票号相比，并没有太大的改进。虽然运行成本较低，但容易出现差错，且资金汇划效率依旧不高，导致占压在途结算资金较多，如异地间资金的汇划，少则 10 多天、多则半年才能完成资金到账。
第二阶段：电子联行（1989~2005）
1990 年，中国人民银行清算中心建成，专门为金融机构提供支付清算服务。清算中心包括 NPC（National Process Center，国家金融清算总中心）和 CCPC（City Clearing Processing Center，城市处理中心）。1991 年 4 月 1 日，全国电子联行系统（EIS）开始试运行。EIS 是基于金融卫星通讯网的，它是人民银行专门用于处理异地（包括跨行和行内）资金清算和资金划拨的系统。它连接了商业银行、央行、NPC 和 CCPC。以一位上海招行银行卡的用户要给持有北京工行银行卡的朋友进行汇款，使用 EIS 完成一次支付清算的案例如下图所示：
借助全国电子联行系统，传票和凭证已变为加密后的电文，与纸质联行相比，进步巨大。客户的资金在途时间缩短到了一两天，大大提高了资金清算的效率，可以说是一个重要的里程碑。
第三阶段：现代化支付系统（2005~至今）
中国人民银行支付清算系统（China National Automatic Payment System）是为我国金融机构之间以及金融机构与人民银行之间的支付业务提供最终资金清算的重要核心业务系统，整体架构如下图所示：
简单介绍下该系统的几个核心子系统：
在现代化支付系统投产之前，即使是电子联行系统也需要一到两天才能能够到账，而现代化支付系统将支付后实时到账变为可能，极大的提高了支付效率，提升了消费者的支付体验。技术变革往往会带来新的商业机会和变革，推动企业进行创新。国内的主流电子商务与电子支付平台起也从 2003 年开始兴起，这里现代化支付系统的投产时间（2002年、2005年）非常接近，很难说两者之间毫无联系。
二
支付系统基本概念
核心概念
支付系统一般指提供支付清算服务、实现支付指令传送及资金清算的系统，由有支付牌照的支付公司提供。支付系统是连接消费者、商户（或平台）和金融机构的桥梁，实现了支付、资金清算、查询统计等功能。这里系统的解释一下涉及到的相关名词，便于我们后文展开详细介绍。
常用支付形式
平台支付
用户提前注册并登录到第三方支付平台，并且已经在该平台上完成绑卡等操作后，通过第三方支付平台进行支付。
网银支付
用户在完成必要的银行网银开通手续后，可以通过银行的网银系统进行在线支付和转账。在进行网银支付时，用户需要登录银行网银系统，输入相应的支付信息并进行身份验证，然后可以完成在线支付交易，移动互联网时代较为少用。
快捷支付
一种简化了支付流程的支付方式。通常情况下，用户在首次支付时需要绑定银行卡或者进行一次认证，之后就可以使用该支付方式来完成交易，无需重复输入银行卡信息或进行繁琐的身份验证。在后续的支付过程中，用户只需进行简单的确认操作或者输入支付密码，就能够快速完成交易。
协议支付
协议支付也称代收或者代扣，代收指渠道授权商户可以从用户的银行账户中扣款，一般用于定期扣款，如水电煤气、有线电视费、包月/包年会员费等。
虚拟货币支付
不少公司会有自己的虚拟币，这些虚币也可以作为一种支付方式。一般会有一些金额、品类的限制，如虚拟支付不得超过每笔订单结算金额的 50%。
余额支付
为用户建立本地账户并使用账户来完成支付，账户支持充值、提现等操作。
信用支付
指使用信用账户进行透支，类似信用卡支付。需要较强的风控能力。
三
支付系统简介
整体架构
在了解了支付系统相关演进与基本概念后，我们再来看一下支付系统的整体架构。对于订单同学来说，在实际支付业务的接入过程中，可以接触到两类支付系统：
第三方支付系统：即订单同学理解里的“支付渠道”。比如我们作为商户直接对接到微信、支付宝的支付系统中，从而具备支付收款能力。整个系统中的“核心系统”功能往往是大家最为熟悉的部分，它概括了我们平时各种消费支付场景。我们平时进行的电商交易、红包转账等都是“支付应用”的体现形式。实践中，三方支付系统往往可以拆分为网关、金融交换、收单域、支付域以及账务域、会员域、营销域等多个领域。
聚合支付系统：即订单同学通常理解里的“支付”。主要功能为屏蔽各种第三方支付系统的差异性，提供统一的接入方式和支付产品，比如得物的汇金系统。一个比较典型的电商平台的支付架构
支付流程
用户支付流程
从流量角度来看，对于一次用户发起的支付行为，请求首先达到支付网关，经过必要的安全验证和流量限制后，被转发给对应的支付服务模块。随后用户跳转收银台页面选择支付方式后确认支付，由支付系统对接银行/第三方支付机构的支付接口进行后续的支付。
支付接口
以业内某支付产品为例，其提供了多种集成支付能力的方式，其中「手机网页支付」适用于商户无独立 App，通过移动端 H5 网站进行传播的方式。我们以一次手机网页支付为例，了解支付的核心接口。
如上图所示，可以从交易支付的几个环节进行分析。
支付接口 在商户的 H5 网站下单并确认支付。商户系统生成订单信息并构造支付请求发送到该支付产品系统。系统校验通过后拼装本次支付所需参数返回给商户前端。商户前端将页面跳转至该支付产品官方中间页，如果用户手机上安装了该支付产品 App，则自动唤起 App；如果未安装，则继续在当前页面进入官方 H5 收银台。用户完成密码输入并支付。系统内部完成本次支付单处理流程。处理完成后，以异步消息形式通知商户后台 Notify_URL，确认此次交易成功。处理完成后，从官方中间页跳转商户自定义支付结果页 Return_URL，展示支付结果。完成本次支付。交易关闭接口针对需要的业务场景，支持主动取消订单（针对未支付订单，已支付单可走退款流程）。
用户发起/商户后台管理员发起订单取消申请。商户系统向该支付产品系统发起关闭订单请求。后台判断处理后返回取消结果。交易查询接口 商户后台发起交易查询请求。系统判断交易单存在，并返回交易结果。退款接口 用户/商户发起退款请求商户系统审核处理退款申请是否合法。合法情况下，商户系统向该支付产品系统发起退款请求。系统处理并返回结果。相关渠道将资金返回（有一定时间延迟）。退款查询接口 用户/商户发起退款查询请求。系统处理后返回结果。下载对账单接口 商户系统根据业务对账需要，发起对账申请，查询最新的对账单下载地址。系统返回对账单下载地址。商户系统根据对账单下载地址下载对账文件。系统返回对账单文件。资金流与信息流
央行在 2017 年 8 月发布《关于将非银行支付机构网络支付业务由直连模式迁移至网联平台处理的通知》，规定了非金融支付机构受理涉及银行账户的网络支付业务全部通过网联处理。目前业内采用的都是“间连”模式提供网络收单服务。这里以一次银行卡网络收单支付交易流程为例，整体资金流与信息流如下：
从上图看，步骤 1 到步骤 6 体现了付款方付一笔钱的流程，表示了三方支付一笔收单业务的信息流和资金流，其中步骤 4 中付款方的银行卡余额会被实时扣减，发卡行侧记应付未付。步骤 5 网联记录支付交易相关数据作为跨行清结算业务的依据。步骤 6 三方支付侧更新支付交易结果并逐层通知至订单系统，同时把支付成功消息同步给三方的清结算，清结算依据交易支付的结算要素做清分分录，记录商户应结资金和应收手续费。步骤 7 属于资金流。由网联负责跨行周期清算，网联通过央行清算系统完成资金划拨后资金到了三方备付金账户。步骤 8 属于资金流。三方支付完成周期性结算凭证生成后通过网联发起结算打款，最终资金到账时间依赖于网联清算+资金划拨的时间。自此，一笔电商交易经过用户银行卡扣款、网联清结算、三方支付清结算，最终实现钱货两清。
资金结算
清结算是对交易支付数据进行全面整理、计算、汇总、检查核对和最终结算的过程，可拆分为清算和结算两个子域。清算域服务根据交易推送的信息，按照约定的计费规则进行清分、汇总，记录主体因商业交易而产生的债务债权，并定期生成相应的结算凭证。结算域根据约定的结算周期和方式，对商户主体产生的债权债务进行清偿。清结算确保了金融交易的安全性和准确性，保障各方权益。
抽象的来看，支付涉及业务主要可分为收、付、退、提、转、充等 6 大类（对于订单同学来说更关心的是收、付、退三大功能，对应订单的购买、履约、售后三个子域 ）。资金结算一般分实时结算与定期结算，我们以定期结算为例，分析整体资金结算的简版流程。
计费
计费为通过对应的计费规则将业务流水消息转换为清结算的资金语言，生成对应的结算资金明细。
匹配 以交易业务的流水信息路由匹配到相应的计费规则。清分 根据计费规则，将资金划分给交易中的不同角色，生成对应的计费结果与资金分摊明细。简单来说就是算清楚哪个费用项，多少钱，谁给谁。分录 落地计费明细与结算明细变更。汇总
根据清算明细，按照资金指令以及时间段进行汇总操作。
校验
主要是对整个结算的模型、指令以及单据、任务的完整性校验，以及账务资金核对检查等，确保最终结算前的数据无误。
结算
生成账单并执行相应的资金指令，完成最终的资金转移。
资金安全
支付业务的资金安全主要可以从准确、合规两个方面理解：
准确信息准确：即信息不错不漏不重。应对思路为流程上的容错机制以及核对来实现。时机准确：即不早不晚，应对思路为核对以及监控预警。合规二清合规流程容错
单据关联
正如某些订单域内部的多种单据间存在关联关系一样，支付设计上也有单据间关联的设计。例如从流程上来说所有的逆向过程都必须持有正向的单据，因此退款必须要关联到原来的支付，退款支付单要关联到原支付单。单据之间的关联只要有以下用途：
状态一致性：正如订单域中的订单单据如果成功，则订单关联的营销单、支付单一定成功一样。支付场景的各个单据的状态也存在关联关系，例如创建退款支付单的前提是所关联的原支付单必须成功。金额一致性：金额控制是退款的一个核心问题，控制不好很容易产生资损。由于支持多次部分退款，金额必须防止退超，这里包含两个维度，一个是总金额不能退超，一个是各个维度的资金组成组成不能退超。具体的做法是，每一笔退款的金额，都会在原单上累加记录到已退金额，记录已退款的总金额，校验不可超。幂等
通过唯一键实现幂等是较为常见的实现方式。例如订单侧常见的重复支付退款是以订单号关联 PaymentNo 做重复支付校验的唯一键，支付侧交易单以外部单号 + 商户号为唯一键，支付单以交易单号 + 操作码作为唯一键。幂等可以有效的防止操作不重复，这里需要额外注意的是，幂等的可重入问题：例如对于一笔整单退的请求，上游请求退款 200 元，支付域已经处理成功，上游由于超时基于同一笔支付单号进行进行退款重试，此时应该返回成功而非业务校验异常。
重试
最大努力通知是支付领域常见的流程容错手段，分布式环境下，网络抖动、服务暂时不可用等都会造成业务流程处理异常，常见的策略为将请求放入 MQ 进行异步重试，重试间隔逐次拉长，重试如果成功，则回调交易，如果失败或者处理中，则继续重试（所以接口幂等支持可重入很重要，对重试更友好）。
例如订单收到支付成功回调后，开始处理订单流程。如果在下单阶段仅锁定库存、营销等资源，需要在支付回调流程真正扣减资源的话，这里需要对超时等场景进行重试（调用下游需要做好幂等），如资源扣减失败则关单退款重试指定次数如业务单据仍未到达终态，则将订单信息持久到数据库中，通知人工进行处理。
例如用户卡注销，会员销户等问题导致退款退不出去，重试一定次数后支付单只能置为失败。等待产运联系用户后，在支付层重新生成退款支付单进行退款。核对
核对是保障资金安全的重要机制。从时效角度来看，主要有（准）实时核对与离线核对（如 T+1 核对），实时核对的准确性不如离线核对，且需要相应的实时核对平台建设（例如得物的 DCheck 平台）。离线核对主要的问题是发现问题的时机较为后置，部分场景会影响系统的时效性。例如清结算与账务侧的每日资金核对失败会影响结算时效性。
从核对维度来看，主要可以有如下几种核对方式：
一致性核对：
资金在从业务端起点（数据由业务产生）到财务端终点（最终流入财务系统）中，在链路中的各个系统/表中都留有相应的凭证。例如交易一笔订单的实付金额对应着支付的一笔支付单的支付金额，商户一笔收单或支付退款会在对应的商户待结算户发生一笔动账，对应在清结算会做一笔有资金方向的清分分录。对这些金额我们可以建设相应的一致性核对任务进行核对验证。
一致性核对包括双向一致性核对和单向一致性核对两种，单向一致性核对无法发现单边数据缺失问题。
业务正确性核对：
在特定的业务场景下，业务有自身的业务规则，可以针对这些业务规则进行校验。常见有以下四种方式：
一般正确性校验：例如某些支付业务只能用于特定的商品类型，则可以通过自定义SQL校验规则来进行校验。
总分校验：各个子金额汇总应当等于总金额。
顺序性核对：业务流程中有依次执行的处理流程，则可以校验是否有流程缺失。
幂等性核对：校验是否有业务被异常的重复处理，如重复退款等。
时效性核对：
主要核对时效相关，如未支付的支付单在超时后是否及时关闭，结算时机是否满足时效要求等。
风险额度核对：
对一些可能有高风险的关键配置与金额相关额度进行校验，如分账比例 <=30%、不能负佣、总营销金额不能超过每日上限等。
总的来说，对实时性较高的任务采用实时核对，而日终检查等采用离线核对，通过对支付全过程的监控预警以及失败 case 产研及时介入处理，从而保证了资金安全的准确性。
资损攻防
也就是我们业内常说的混沌工程，通过注入故障可以有效的验证我们的系统是否足够健壮以及监控核对是否及时有效，常见的实现方式有：
通过模拟核心依赖超时等异常场景，验证容错重试流程是否可以正常工作。模拟资损核心字段落库异常的场景，验证监控核对是否可以及时发现。当然也可以通过旁路攻击的方式，如修改数据库的binlog字段而非直接修改数据来查看是否触发告警，这样对线上业务的影响会更小一些。二清
对订单同学来说，二清就是在下单时查询商户对应的支付二级商户信息并传递到支付与结算。那么什么是二清？二清合规问题是如何解决的？
什么是二清？
首先我们通过几个案例来了解下什么是二清。
二清问题实际上可以分为“资金二清”与“信息二清”：
资金二清：指无证机构通过平台或大商户模式截留沉淀了应直接结算给二级商户的资金，再通过其他方式完成二次清算，实质性的控制整体结算资金。信息二清：信息二清层面，监管不仅要求平台不能进行“资金二清”，同样也要求其提供的交易信息真实可追溯，且分账信息是商户真实意愿。信息二清主要为了避免平台使用了合规的三方支付机构，虽然不触碰具体的资金结算，但掌握了原始的交易订单数据、分润信息和商户资金结算的入账规则，使银行或支付机构根据其提供的分账规则、指令为商户入账，实质上通过平台分账指令传输主导了结算资金的方向。
电商公司早期求生存是更主要的问题，在整体支付系统演进过程中，往往都采用二清的模式。这里面用于公司统一收款的账号我们称之为“大账户”。资金通过用户流向公司的大账户，在通过结算最终流向卖家。这里存在一定的合规风险：
资金挪用风险：平台代为几种收款，有擅自挪用的风险资金监管风险：无证机构向平台入驻的商家结算资金，游离于监管体系之外交易信息风险：无法保证平台提供交易信息的真实性，有伪造的风险近些年随着监管越发成熟，电商公司因为支付不合规被责令整改的新闻屡见不鲜，随着公司业务规模的发展，二清合规问题也愈发迫切的需要得到解决。
二清解决方案
对于二清问题，通常有两种解决方式：
通过申请或收购的方式获得支付牌照，使平台获得合法的资金清算能力（牌照较昂贵，成本较高）。接入三方支付公司的二清解决方案（聚合支付系统需配合接入改造）。目前得物采用的是第二种方案，我们以某宝的二清解决方案为例，简单介绍得物是如何通过某宝的互联网平台直付通产品解决二清问题。简单来说，得物平台上的二级商户需要入驻某宝成为某宝的商家，买家在得物的订单支付成功（支持多个商家的订单合并支付）后，某宝记录对应商家待结算资金，待平台确认可结算时，某宝将资金直接结算至商家指定的收款账号。同时支持平台按订单灵活抽取佣金（也就是我们常说的分账）。
这里面有几个核心的概念：
分账抽佣 ：可根据实际业务场景将交易资金分账到其他业务参与方的支付产品账号（例如：平台抽取佣金、其他方服务费等）。目前支持单个平台最多 20000 个 参与方的分账，单笔交易订单 最高分账比例 30% 。结算 ：买家确认收货后，得物通过资金确认结算功能，将整笔订单结算给二级商户收款账号，最长账期支持 365 天，超过 365 天订单自动结算。营销补差 ：平台举行平台出资的营销活动，如跨店满减、全场通用券等营销手段，资金结算后，平台向该支付产品发起补差指令，将营销资金补到二级商户的账号。简版流程：
买家支付订单，订单触发分账，将钱转入卖家待结算户，此账户金额对卖家不可见 用户确认收款，得物平台发起结算指令，该支付产品将卖家待结算户的钱按照事先在该产品后台配置的分成规则进行分账。分别流入得物的该支付产品账户与二级商家已结算户，此时卖家就可以看到自己的账户余额增加了。 卖家将二级商家已结算账户的钱提现等操作。当然这里还有一些撤销分账、补差等细节流程，这里就不做过多的展开了，感兴趣的同学可以阅读三方支付公司的二清解决方案相关文档。
四
订单与支付
得物订单与支付交互
由于监管 KYC 的要求，一笔支付单不仅需要支付相关信息的如支付方式、支付金额、支付有效时间等，也需要订单的买家信息、卖家信息、商品信息等等。这些信息客户端无法全部给到，且基于安全的角度，也不能由客户端通过公网传参的方式传递，需要订单域与支付域进行交互传递相关信息。目前得物支付提供了下单模式（业务方调用支付系统创建支付单）和反查模式（业务方实现 PayInfo SPI，支付系统反查业务方获取支付信息）两种模式，目前订单是按照反查模式与支付交互。
订单开发中常见支付相关问题
0 元订单
微信/支付宝等常见三方支付文档里有说明，支付金额 Total_amount 字段取值最小为 1（1 分钱）。因此如果 0 元订单还创建预支付单的话会失败。之前有订单域通过注册定时回调任务，伪装成一个收银台支付回调的方式来实现 0 元单回调，实践下来会踩坑（与实际业务流程不符，伪装的回调需要不停适配支付回调的改动）。正确做法是对于 0 元订单，只走创建商户订单的流程，并直接更新订单状态，不走支付回调流程。
支付订单过期时间设计
在电商交易系统中有两个过期时间的概念：订单过期时间和支付单过期时间。这两个时间会产生时间差的原因在于：用户在「确认订单页」点击「提交订单」就会创建订单并跳转至收银台，此时开始锁定库存并计时；而用户在收银台停留的时间是不确定的，这部分不确定时间造成了时间差。具体来讲，如果用户点击「去支付」创建预支付单时传递的过期时间是个固定值，那么就有可能会出现一种情况：在订单系统该订单已经过期失效了，但用户在支付平台内还能支付该笔订单（而此时支付成功回调订单系统，订单已取消，系统是不会进行后续发货流程的）。因此，支付单的过期时间要结合支付单创建当前时间和订单创建时间一起动态计算得出，保持一致，从而给平台用户提供更好的消费体验。
五
总结
总的来看，了解支付系统有助于订单交易方向的同学理清上下游，更加全面理解电子商务四流中的资金流。同时支付系统在资金核对、流程容错方面有着非常经典的设计，值得我们去学习借鉴。
参考文章：
1.银行、票号兴替与清末民初金融变革
2. https://baijiahao.baidu.com/s?id=1774618341934674551&wfr=spider&for=pc
3. https://download.csdn.net/blog/column/9276612/108820800
4. https://www.sohu.com/a/314762715_348231
作者:申尧
来源:微信公众号:得物技术
出处:https://mp.weixin.qq.com/s/NvG9wR_GwEnKTHMfkTJWng
解决电商二清？支付行业可不止一种解决方案
电商行业原来发展已经这么长时间了，对于电商行业，大家都有什么看法呢？下面是笔者整理分享的关于解决电商二清？支付行业可不止一种解决方案一文的相关内容，大家一起来看一下吧！
电商行业至今已发展多年，国内从淘宝网的一方独大，到拼多多、抖音等新电商平台的横空出世，标志着国内电商的不断发展和竞争。电商购物作为小额高频消费的典型场景，自然和第三方支付有着密切的联系。目前网上有关“电商&支付”相关的文章已经比较多了，不同的作者老师从不同的角度对行业情况、系统框架有较多的介绍。
故本文本的重点就如标题所言，会侧重于说明目前业内对“二清”的解决方案，如：各方案有哪些环节？方案之间有啥区别？等等。
一、电商的类型
首先电商主要分为两种，自营型和平台型。
自营型就是企业搭建自己的销售平台出售自己的货物，比如大疆（https://www.dji.com/cn）。
平台型比较常见，淘宝、京东大多属于这类，企业负责搭建平台，提供商户入驻、商品展示，对接支付系统等，但平台本身不直接销售商品，商品所有权属于入驻商户。
两种不同的类型，导致整个链路的“信息流”、“资金流”、“票据流”均不同。
所以对自营型电商而言，理所应当的收自己的货款，不存在二清情况；而对平台型电商而言，平台作为支付请求的发起方（向下游支付公司发起扣款请求），所扣金额实际上是入驻商户的货款，所以原则上应该直接入账到入驻商户名下，一旦被平台收入（由平台再次结算给入驻商户），则可能出现平台卷钱跑路等重大资金风险（即二清问题）。
至此，在介绍电商类型的同时也说明了为什么只有平台型电商存在二清问题。下面具体说下目前支付行业是如何解决的。
二、业内两种解决方案
1. 基于支付公司的解决方案
首先有个客观事实，即目前中国大陆主流的支付工具只有微信和支付宝，故两家支付公司早已推出了成熟、合规的行业解决方案。以微信为例，其解决方案为“平台收付通产品”。
1）方案说明
平台收付通（原电商收付通）是微信支付专为平台商户进行交易场景打造的支付、结算解决方案，主要面向对实物商品交易进行线上撮合和管理的平台。在发生交易纠纷或其他负向风险时，此类平台有能力介入管理，并对交易负责。
平台商户在申请之前需入驻成为微信支付开发者。平台上开展交易的商户入驻微信支付，成为二级商户。平台收付通支持将多个二级商户的订单进行合单支付（如电商购物车中的多笔订单合并支付），合单支付款项分别进入到二级商户各自的账户（资金为冻结状态）；平台商户在满足业务流程条件下（如确认收货等），可将二级商户的冻结状态的资金解冻，并收取平台佣金。
（上述话术源自微信官网：https://pay.weixin.qq.com/wiki/doc/apiv3_partner/open/pay/chapter3_3_0.shtml?eqid=de52cd8700068a0900000006645681da）。
该方案在合规的同时，也很好的解决了合单支付、平台分账（抽佣）、营销补贴等电商行业的特殊需求。
2）角色关系
在使用该方案时至少存在三类业务主体。
3）方案信息流：
（简化的信息流程图，完整的交互链路请查阅微信支付官网：
https://pay.weixin.qq.com/wiki/doc/apiv3_partner/open/pay/chapter3_3_3.shtml）。
4）方案资金流：
由用户银行卡至微信ACS，再出款给平台银行结算账户（分佣）、入驻商户银行结算账户（货款）。
微信收付通方案因为已经非常成熟、公开的信息也很多，就先简单介绍至此。
2. 基于银行的解决方案
了解这种方案的读者可能不如第一种方案的多，以平安银行见证宝为例，是平安银行针对电子商务平台搭建的支付结算网络，在为电商平台搭建一整套交易资金见证总分账户体系的同时，向平台及平台用户提供总分账户的开立、账户鄉定及鉴权验证、密令控件输出、交易担保支付、充值、提现、交易资金清分、清算和对账等一体化资金管理服务。
(上述话术源自平安银行官网：http://www.orangebank.com.cn/zhifutong/dsjianzhengbao.html）。
1）角色关系
这次我们先来看下角色关系（支付公司仍以微信为例），在使用该方案时至少存在四类业务主体：
可见方案变的更“复杂”，也更“怪”了。
2）方案说明
带着这四个角色，我们进一步开展方案说明：
该方案由平台和银行达成业务合作，银行为其开立一个监管账户，平台在微信侧开立收单商户（注意：是收单商户，微信原则上不感知平台下入驻商户的交易），微信侧的资金结算账户绑定为银行开立的监管账户。从而实现入驻商户的应收款入账至平台的微信账户中，再由微信结算至监管户，由银行对用户支付的货款进行统一监督管理。
对平台的入驻商户而言，需要由平台将商户的资质信息、结算卡信息送往银行核验鉴权。通过后银行会在平台监管账户下为入驻商户开立二级账户，用来管控入驻商户的应收款项。
当用户发起微信支付时，不论场景上是否为多个入驻商户的合单支付，请求微信时都只有一笔交易单（没有分账信息），微信向用户扣款成功后，再由平台通知银行进行分账操作，基于平台的分账信息银行在入驻商户的二级账户上入账。T1微信将实体资金结算给平台的监管户，银行完成清算对账后，平台可向银行发起入驻商户结算指令，最终实现商户收款。
综上，从微信视角来看，这更像一个自营型平台的支付业务，而分账、分佣、资金管控的功能和责任全交给了银行，用户支付的货款也从微信ACS挪到了银行账户。
3）方案信息流
（注：同样是简化的信息流程图，支付机构以微信为例，合作银行以平安为例）
4）方案资金流
由用户银行卡至微信ACS，再结算至银行监管户，再由监管户出款至平台银行结算账户（分佣）和入驻商户银行结算账户（货款）。
5）其他说明
各位聪明的读者看到此处时，心中应该也有不少疑问，比如银行是怎么对账的？银行账户结构是怎么样的等等，在此稍作解释：
a.银行的账户结构
如图，银行账户下是有多个子账户的，一部分子账户用于平台，一部分用于入驻商户。如，挂账子账户：当监管户有实体资金进入时，会先记在挂账子账户上，比如微信T1的资金结算，平台发起的监管户充值等。手续费账户：即平台抽佣的金额会记在该账户上，该账户可以绑定平台的银行结算账户，以实现手续费收款提现。入驻商户子账户：是入驻商户在银行入网登记通过后开立的账户，用来记录商户的应收款项，该账户也绑定了商户的银行结算账户，以实现资金结算。
①银行的对账处理
既然银行承担了资金清分、结算的职责，那银行是怎么对账的呢？分为三个部分，在当日微信交易完成后，平台需要把交易信息、分账明细包括分佣要求送给银行，银行侧会记录这些交易，并给相关子账户入账。次日，平台需将获取到的微信交易账单同步给到银行，同时，银行又收到了微信的结算资金。此时银行有了三个数据：商户请求的交易数据（含分账信息）；微信的交易账单；实体资金总额。银行开始跑批核对，确认明细账和资金总账的一致性。
②入账金额的状态管理
除了对账外，银行既然要确保资金的安全，就需要对用户支付的沉淀资金有所保护，所以银行的资金分为几种状态：“待清算”、“冻结”、“可用”。待清算是指银行当日收到平台交易（分账）指令后，会实时给每个商户子账户加值，但此时为待清算状态，需等到银行次日对账成功后，这些资金才会被划出待清算状态。冻结、可用相对常见，通过资金冻结保护用户货款，仅当解冻转为可用状态后，入驻商户才能完成提现请求。
③其他细节问题
上述说的都是正常链路下的正常情况，但在实际合作与使用中存在各种细枝末节的问题。比如，微信会向平台收取支付手续费，一般会轧差收取，此时会导致一个问题，即T1微信实际结算给银行的资金会小于平台接口请求的交易金额总和（银行实收＜银行应收），这个时候对账会出现异常。针对这种情况有两个解决方案，其一是开立微信的手续费账户，渠道收取费从该账户扣除，从而不影响微信T1的资金结算；其二是见证宝通常会绑定一个平台的自有资金账户，如果出现银行实收＜银行应收的小额偏差，银行会从平台的自有资金账户中扣出这部分钱补上。
又比如一种退款异常的情况，比如微信T1结算（全额结算）后，平台当日在没有正向交易的情况下发生了用户退款（交易量小的平台会有这个问题），此时平台的微信账户余额为0，原则上无法退款。但又由于退款链路会先请求银行扣除商户子账户余额，此时就出现了商户子账户余额扣款成功但微信给用户退款失败的尴尬情况。针对这种情况，可以修改微信结算规则为非全额结算，留存一部分的资金以应付T1的退款，并对发起轮询的退款重试或人工介入。
三、两方案对比
最后来说一说两个方案的区别，帮助各位读者进一步认识这两种行业解决方案。
首先是“平台收付通”，作为支付公司给出的解决方案，在合规层面上受日趋严格的监管影响，所以微信的风控、合规、商户入网、KYB做的都更加严谨。
其次，如果平台使用了微信收付通方案，在未来要拓展支付宝等支付工具时，则需要如法炮制，相关的合作、平台及入驻商户的入网流程需要重来一遍，操作成本较大。再者，由于是支付公司自己的方案，所以用户体验上会更好，比如用户可以在微信订单中看到分账金额，收款商户等信息，这也更符合合规的要求。
最后，电商的一大特点是在于用户货款的长时间沉淀，这部分沉淀资金对平台和支付公司而言是没有收益的（更严谨的说，支付公司有微量的备付金收益）。
但对“见证宝”而言，作为银行给出的ToB解决方案，相对而言更加“灵活”，并且对接服务上做的更好（可以咨询相关技术、产品老师）。其次，平台如果一开始只接了微信支付，未来即便要拓展支付宝或其他支付工具也会相对简单，因为入驻商户不需要在各支付公司重新入网登记，只需要在银行入网一次即可。再者，用户体验上就显逊色，用户只能在微信订单中看到一笔平台全额收款的订单。最后，由于平台愿意将这部分沉淀资金给到银行监管，所以银行就多了一笔（或者一大笔）钱，银行可以将这部分沉淀资金的收益分成给平台。
所以，总结如下：
本文由 @一一一 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
相关问答
电子商务 常用的 支付 手段有哪些,各有哪些优缺点?_作业帮[最佳回答]1、传统支付方式(1)现金支付.(2)邮局汇款.(3)银行转账.现金支付的优点:简单易用,便捷,直观,适用于低价值的交易.现金支付的缺点:受时间和空间的限...
为移动 支付 提供了一个可以 实践 的平台.目前 电子支付 在支付...[最佳回答]TenPayasanewmeansoftransactionandcreditintermediarytothethirdpartypayment,providesa...
B2C 电子商务 的 支付 的主要方式有哪些?B2C电子商务的支付的主要方式有:1、汇款。银行汇款或邮局汇款是一种传统支付方式,也是目前为止电子商务支付方式中最常用的支付方式。2、货到付款。货到付款...
电子商务 常用的三种 支付 手段是什么?以下是目前的支付方式:1:支付工具.支付宝微信钱包QQ钱包京东钱包这些都属于这一类。2:在线支付。主要就是银联在线支付和信用卡在线支付。3:电...以下...
支付 网关是什么意思?支付网关是一个用于处理电子商务交易的软件应用程序,它充当商家和客户之间的中介。它的主要功能包括验证客户的支付信息、将订单信息发送给商家和支付处理机构...
网络 支付 的产生与 电子商务 的联系?网络支付的产生,大大方便了电子商务的发展网络支付的产生,大大方便了电子商务的发展
解决 电子支付 安全的两个协议是?解决电子支付安全的两个协议分别是:1.SSL(SecureSocketsLayer)协议:SSL协议是一种加密通信协议,用于在互联网上保护数据的安全传输。在电子支付过程中...
电子商务支付 方式有哪些?1、转账汇款,这个最传统,最不安全;2、第三方支付,支付宝、安付通、块钱,还有百度、苏宁、京东自己的支付系统等,非常多;3、信用卡、银联刷卡;4、手机...1...
电子商务 平台常见的 支付 方式有几种?自己做一个平台设置哪几种 支付 方式比较好?其实这个并不是多多益善,你可以从客户来源上解决这个问题,你从微信引流就只要微信支付,你从阿里系引流就只要支付宝,如果都有,那么你需要都做。但是不要考虑...
支付 结算是什么意思?支付结算是指在商业交易中,买方向卖方支付货款的过程,以及卖方确认收到货款并将货物或服务交付给买方的过程。在支付结算中,通常会涉及到银行、支付机构等第...
