支付系统设计小结

从内容的角度来看产品，我们会发觉现市场中存在的所有APP产品都是扮演着内容提供方的角色，而用户则扮演着内容消耗方的角色。这样来看，线上的交易行为其实就是 内容提供方和消耗方针对内容使用权限的交易行为 。线上的内容交易早已不限于实体物，还包括大量的虚拟内容，用户可以在线上挑选自己满意的内容进行免费消耗或付费消耗，这就是所谓的内容付费时代，这两年很流行的知识付费时代的概念就是基于内容付费延伸出来的。（20年前我国实现了第一笔网络交易，而现在线上交易已经是极平常的事情，感叹技术发展的如此快。技术发展的摩尔定律还能延续多久？——题外话）。归根结底来说，产品本质是要商业化的，要收益的，因此产品能满足用户支付的需求就显得至关重要（排除部分传统的、大金额的B端业务是进行线下支付的，这类特殊业务目前线上支付还无法很好的满足，故还是采用线下支付的流程，这里暂不考虑）

在准备对产品进行支付功能设计之前，我们先要对自身产品进行分析，分析产品现阶段是否需要支付环节，然后再进行后续工作。通常我们从用户角度和业务角度两个方面进行分析：

1. 用户角度

1）用户想要查看产品中某些指定内容或想要使用产品中某些特色功能，但这些内容功能只有收费才能获得使用权限，此时用户会产生一定的支付需求。例如美颜APP中的特效，视频APP中的付费内容等

2）用户想要对产品中其他用户进行打赏等操作，此时产生支付需求。例如的赞赏，直播APP中的礼物等

2.业务角度

1）产品的定位。产品在企业内当前阶段中战略定位为获得利润的、背盈利指标的产品时产生支付需求。（某些产品在企业的战略定位上为获得流量、打造爆款或者打造品牌等，这类产品中的交易属性不是衡量其是否成功的关键要素，所以这类产品的支付模块可暂时省略）

2）产品发展到一定阶段，大量可变现的点出现，可尝试进行变现，随即产生支付需求。例如产品积累大量流量，广告变现就会水到渠成等

通过以上的分析我们能够清晰知道支付对产品的意义，有助于我们更好的理解支付对产品的重要性。产品都是商业性的，不论产品是从用户端收益还是从广告渠道端收益等，其目的都是需要进行交易，不同的只是支付环节可能出现在产品进程的不同阶段而已。

我们已经知道产品现阶段需要支付环节，之后我们要确定产品是需要 充值 + 支付 两个流程，还仅仅是 支付 一个流程。其实大多数产品是完全不需要 充值 流程的，因为现在用户进行消费时可以走第三方支付直接支付掉，不需要先往产品中充值。但是由于某些产品的商品属性、运营、商业等要求，会使得产品增加充值流程。从产品进程角度来看，如果需要充值+支付，则在功能流程上就要增加钱包、充值入口、提现等多个功能流程，会在一定程度上增加产品的开发成本和时长；而如果只需要支付，则只需在产品内跑通第三方支付流程即可，相对来说更加简单和快速。建议业务上没有特殊要求时，产品只跑通支付流程即可。

从流程可知，我们的支付流程设计本质是对【支付触发页面】，【选择支付方式】，【支付成功】三个部分进行设计。由于我们是调用第三方支付，所以【支付中】流程不是我们可以干涉和设计的，直接调用就好（Tips：若产品中有''钱包支付''的选择项，就需要考虑【支付中】流程的设计）。之后我们就对这三个部分进行设计分析。

1. 支付触发页面

优质的支付触发页面，需要由 支付内容 + 支付金额 + 支付入口 三个部分组成：

1）支付内容：合理的展示内容的名称、数量、单价等信息，有助于付款用户进行内容的核对和确认，一定程度上增加用户使用体验感

2）支付金额：明确的向用户展示待支付的金额，且需要清晰的展示出该金额的 由来 。例如用户购买一本原价为30元的书籍，但是今天网店做活动，书籍品类打5折并且免邮费，此时用户只需付款15元就可买到该书。这种情况下，产品需要把支付金额15元是由“原定价30元打5折并免运费后得来的”这一原因进行清晰的描述展示，让用户知晓。（对于涉及到 钱 的事情，一定要说明的格外清楚，即是 对支付者的负责，也是对企业自身的负责 ）

3）支付入口：也就是支付按钮。该按钮的设计集中在视觉和文案上。例如视觉上将按钮采用不同的颜色让其更易辨认、按钮放在屏幕底部靠右的位置上让其更易点击、按钮中的文案采用倒计时的样式增加时间紧迫感（和开团原理相同，但强度低于开团）等小细节的设计，减少用户操作负担

2. 选择支付方式

现存在的支付方式的选择看似很多，但是要用起来后就会发现效果最好就是那么两个，即【支付宝支付】【微信支付】。2018年第一季度支付宝和财付通这两大巨头占据了中国第三方移动支付交易规模市场份额的90.6%。其他的如云闪付、NFC支付等方式只占了9.4%。所以对于APP的支付选择来说，毫无疑问首选是这两者，将二者都集成是最好的方式。

这两者作为目前最普及的线上支付工具，一个是出生就自带支付基因，一个是基于社交延伸发展起来，都已经在国人认知中标上了线上支付的标签。并且由于两种工具在用户中大面积（线上线下布局）、长时间的使用，使得用户在工具中形成了一套自己的信用体系，产品方再基于沉淀的信用体系开发提供给用户更多信用服务，使得用户对产品的粘性再一次加强，从而让这两款支付工具牢牢地占据着市场，形成双寡头局势，位置极难撼动。

当然支付宝支付和微信支付在不同的场景下被用户使用的偏好也存在着明显的差异：线上支付场景更偏好支付宝支付，线下支付场景更偏爱微信支付；大额支付场景更偏好支付宝支付，小额支付场景更偏好微信支付。我们可以根据自身产品的需求进行支付方式的选择，最好是将两者都进行集成，这相当于产品覆盖了全国90%有支付能力的网民。如果你的产品处在从0到1的阶段，且时间、开发资源等都很有限的情况下，优先选择微信支付。因为微信支付是基于微信社交属性延伸起来的，也就表明微信支付能应用于更多社交场景上，并且微信的装机量要大于支付宝，公众号、小程序的运营也都需要使用微信支付等等原因，所以在这里，作为0到1阶段的产品首选支付方式为微信支付，之后在集成支付宝支付，处在其他阶段的产品，尽可能的将两者全部接入

3. 支付成功

此环节为一个反馈环节，其设计要点是：用户支付成功后给出正确的提示反馈和跳转反馈。

1）提示反馈

可以采用类似“支付成功，正跳转回xxAPP”的提示语

2）跳转反馈

我们可采用两种设计逻辑

4. 其他

每笔支付完成后，都需要留下痕迹，用户会在各种原因促使下回来查看，所以就需要我们留个【交易明细】的入口给用户，帮助用户进行交易回溯。【交易明细】的入口放在钱包、订单管理中即可

以上我们基本完成了产品支付流程的设计。之后我们再对充值流程进行设计分析

从流程可知，对充值流程的设计集中在【充值触发页面】，【选择充值金额】，【选择充值方式】，【充值成功】四个环节的设计。【充值支付中】我们不干涉，原理和上文的支付流程相同。

1. 充值触发页面+充值金额选择

1）充值触发页面需包含 选择充值金额 + 充值入口 + 充值教程 + 充值说明 + 常见问题 五个部分

2. 选择充值支付方式

关于充值方式安卓应用可以采用微信、支付宝等充值方式；苹果应用则采用苹果应用内支付（有部分应用可以不采用此方式充值。例如像摩拜、ofo这类应用是可以采用第三方充值。原因在于苹果对充值后的钱用途的定义，定义为购买非虚拟商品则不需要进行应用内支付，反之则需要应用内支付）

3. 充值成功

设计原则和【支付流程设计】中的支付成功设计原则基本相同，这里就不再赘述

4. 其他

有了充值环节，则钱包功能连带出现，有了钱包功能，则支付方式的选择中就会出现 钱包余额支付 的选项，这是一个连锁反应。所以在进行充值功能的设计时，需要同时进行钱包功能流程的设计、钱包余额支付流程的设计，这样才能保证从 充值-选定商品-支付-结果反馈 的闭环完整。

和钱有关的，都要打起十二分精神 ，支付功能的测试环节是非常非常非常重要（重要的事说三遍）

测试点如

1）正确流程是否实现

2）取消订单时的处理是否正确

3）弱网等网络情况下的处理是否正确

4）支付过程中交叉干扰时的处理是否正确。例如支付过程中出现电话、短信等干扰

5）支付安全的保护处理是否完善。例如假单，拦截请求，修改订单等

6）多用户并发时的处理是否完善

7）设备上无支付宝、微信第三方支付软件时的处理是否正确

8）支付宝、微信等第三方支付软件为登录时的处理是否正确

9）订单金额校验的处理是否完善。例如用户购买100元虚拟币时，进行第三方支付时金额被篡改成0.1元，就造成用户用0.1元得到了100元的虚拟币

10）连续点击支付按钮时的处理是否正确

......

等等测试点都需要产品经理和测试工程师一同进行、多次测试，确保准确无误了才可进行上线。

以上通过对模块的 接入时机、支付流程、充值流程、测试环节 四个方面的思考和分析，再结合产品的 时间、成本、业务 等实际情况，设计出符合自身产品的 安全 稳定 易用 的支付模块

在任何模块的设计中时间和成本是产品经理必定要考虑的事情

支付宝的系统采用的是一个典型的从渠道到产品到服务到支付渠道的应用架构，其中服务根据业务的发展，一方面考虑平衡业务的增长与创新，另一方面考虑系统的安全、稳定、可伸缩。所以系统架构设计上需要构建稳定的基础业务服务，通过服务重用实现业务敏捷，同时保障核心安全稳定。

对于各类的支付场景，其典型处理模式如上图所示，互联网商户访问渠道系统，通过API平台接入，经过产品层，封装订单处理，然后调用收银台或者直接调用交易，交易过程中附加计费、营销、风控，然后到支付处理，支付处理再到清算处理和账户会计处理，最后通过渠道通信前置调用银行渠道完成支付交易落地。

支付交易的处理在上述流程下就很好理解了，首先，业务系统通过收银台或者支付API将交易发到支付系统，支付系统通过账务交易记录账务并给到会计系统，然后通过清算模块与银行渠道完成支付落地，最后将清算模块与会计记录进行核算。

账务和会计相关我之前专门有一篇文章分析，此处就不再赘述。

传送门： 【支付系统设计从0到1】支付宝架构中记账功能设计分析

在支付清算这页里我们看到，支付宝分了支付系统和清算系统作为联机交易，其实这就是我们之前讲的支付系统设计中的支付产品和支付渠道，然后通过记账指定给到账务系统里再做记账，联机记录交易流水，异步做复式记账。这其实也是我们在设计支付清算系统的时候的一个原则：为提高交易性能，交易必须与账务分离，以提高交易处理性能和效率，从而有针对性的分块解决复杂业务逻辑。所以，我们在支付系统设计中一般是将记账为分2个步骤，支付成功后系统同步记录流水账，异步通知会计系统做复式记账，如下图所示。

支付系统中实现四种的支付方式，充值，提现，内转，充退等。而清算系统完成跟渠道之间的渠道管理、任务调度、实时处理以及文件处理、还有接收异步清算处理。

支付宝架构中的交易系统就是我们之前支付系统架构设计中支付产品所实现的功能，包括各种支付方式的实现（担保交易、即时到账交易、货到付款交易等）。

另外，这里面还包括了：数据持久、流程引擎、规则引擎、超时处理、资金处理、产品账接入、收费接入、商户通知、统一事件等。

商户通知和统一事件通过消息系统异步交易时间处理。

异：微信支付和线下场景结合，支付宝支付和信任度结合。同：都可以利用支付宝搞社交和移动支付。

使用微信支付您可以和现金支付使用一样的记账逻辑的，微信支付主要是移动支付方式，所以目标是简单快捷

比如说：不用找零，没有收到假币的烦恼，顾客不用带钱包，所以满意度更高等。

不管定位、框架和界面风格都是结合自身优势、补齐其他短板，争夺对方优势，都有被迫性在里面。

微信：先是移动社交老大，流量多起来就开始走关于消费的移动支付，这是必然趋势。

支付宝：线上金融龙头，以支付起家，交易的背后就是交流，交流就是社交，只是现在支付宝逐渐意识到他不该仅仅看着微信这个对手，而是要面对更大的用户群体，所以相对以前没有刻意搞社交。

扩展资料

微信与支付宝最可怕的在于场景，微信本身属于高频应用，而支付宝相对低频,移动支付的使用习惯是支付战争的核心战役。谁先抢占和培养了移动支付习惯，谁就是胜利者。支付宝在利用他们pc端的优势诱导用户使用支付宝钱包,而微信则通过小型内嵌游戏、双十一易迅促销等测验微信支付的体验和效果。

不同于即时到账支付产品，分账支付需要对接微信和支付宝另外的接口，跟普通支付产品的主要区别在于在支付时需要指定对于二级商户号（要求一个二级商户号一个子订单），多个子订单支持合并支付，另外如果是分账支付在用户支付端的页面跟普通即时到账产品也稍有不同，下面会详细介绍，另外API详情请参考三方开放平台文档

2. 支付计费分账流程

正向支付分账流程相对逆向来说还是比较简单的，参考以下流程

在流程图中有个判断是否锁定分账用的，这个地方重点在逆向退款退分账中会说明

3. 单据&属性设计

目前我司在分账时设置了三个层级的单据，分别是分账的 - 分账商品明细 - 费用明细，三层层层递进，已对多的关系，计费完成后会分账金额统一记录在分账单商品，再向三方发起分账

单据名称用途属性说明

分账单支付时子单的概念，是后续分账的依据，属性包括子单号、订单创建时间、支付方式、支付三方流水号、支付完成时间、订单完成时间、订单总金额、订单折扣金额、订单运费金额、用户实付金额(分账总金额) 、是否锁定分账、商家应分账金额、平台应分账金额、商家冲抵金额、平台冲抵金额、商家实际分账金额、平台实际分账金额、分账申请单号、发起分账时间、是否发起状态、应分账时间、分账成功时间、分账状态、分账失败原因、计费状、计费失败原因

分账商品明细商品或者服务明细，属性包括子单号、商品编码、商品名称、单价、数量、折扣、销售总额、优惠券金额、实付金额、计费状态、计费失败原因、佣金扣点（或者供价）等等

费用明细商品对于的费用明细，属性包括费用类型编码、费用类型名称、费用金额、费率类型（指定、扣点）、分账账户（平台、商家）

另外分账其实是依赖于计费状态的，以下是两者之间的流转关系

4. 支付

支付API大家可以直接去微信和支付宝开放平台看下（支付宝文档好像是定向开通的），这里重点说明下即时支付产品和分账支付产品在用户体验有哪些不一样的地方

开通的要求不一样

前面在进件环节大家也看到了，分账产品需要有二级商户进件完成后才可以进行交易和支付

页面展示不一样

由于分账产品资金账户所有权是归属平台商家的，因此在用户支付页面展示的信息跟普通即时支付也不一样，这个环节微信做的还是不错的，重复的把资金收款方也详细的说明了，详情参考下图

资金流转不一样

即时支付产品资金是直接支付给平台的，账户归属权属于平台，分账产品资金是支付给商家的，这样相对来说降低了平台“跑路”的风险

5. 计费

计费这里可简单可复杂，主要看业务的复杂度怎么样，下表把常见的费用项目整理了下，供大家参考

费用项分账对象说明

【货款】：二级商户货款金额为顾客支付金额减去各类费用后的余额

运费二级商户顾客支付的运费

【运费险或者其他附带保险】：分账至二级商户-保险公司，顾客下单时选择的服务保障，需要分账到对于的保险产品提供公司

【平台佣金】：分账至平台，平台收取的跟订单交易相关的费用，比如扣点或者指定的供价售价价格差（固定费用正常不会通过分账来收取）

【平台促销补贴】：分账至二级商户，前提是需要平台向平台补差账户进行充值后方可分账

【顾客返现平台】：分账至平台，发放给顾客的返现，比如会员返现，推荐人返现等等需要商家承担的部分

【售后退款抵返现】：比如本应退顾客100，但是前期已发放返现10元并且无法回收（已经使用掉了），这时退款给顾客只退90元，少退的10元属于“售后退款抵返现”，退分账时不需要退还

另外需要充分考虑计费失败的情况，保证系统的容错能力。

5. 分账

设计好了单据、和计费流程的话分账其实就是很简单的事情（其实真正负责的是逆向退款，后面文章详细介绍），分账后账户资金会由冻结胡划入可用用，商家就可以提现了。

整体分为交易系统（OMS）、支付系统、清结算系统、对账系统、会计报表（非必须）等几个部分。

支付系统是负责电商系统收款和出款的子系统，需要支持电商平台与外部渠道间，所有收款和出款的功能，以及电商平台内部账户间转账的功能。简单来说，支付平台需实现充值、提现、转账、退款四方面的功能。

一般来说，支付系统由以下几个功能组成。

第三方支付：微信和支付宝占据国内移动支付的绝大部分份额，因此是一定要接入的。

按照结算类型来分，收款类一般有即时到账、担保交易两种，出款类有转账、银行卡代付等。

如果电商平台有支付牌照，可以自己分账，或者收款类型为年费等无需分账的交易，那么可以选择即时到账方式收款。

如果电商平台没有支付牌照且需要给实现二级商户分账，则可以选择微信的收付通或支付宝的直付通等产品。但用户通过微信支付的订单才能通过微信的产品来分账结算，支付宝支付的订单才能通过支付宝的产品来结算，对于平台对接、商户收款皆有不便之处，因此电商平台很少选用这种方式。

银行卡支付

一般来说，电商平台接入了微信和支付宝后，已经可以满足大部分支付需求，无需再接入银行卡支付。而对于购买了支付牌照的大型电商平台，想要打造自己的支付工具，才会对接各大银行，接入快捷支付功能。或者有一定规模的电商平台也可以直接与银行签约，开通快捷支付接口。

和第三方支付不同的是，银行卡收单、退款，一般都不是实时结算的。而支付公司与电商商户的收单交易，是实时结算的，实际是支付公司提前垫资。

快捷支付

现在市面上大部分电商app中，银行卡支付功能都是使用的快捷支付方式。对于电商平台，如果需要接入银行卡快捷支付功能，有两种方式：

例如电商平台在工行开通了快捷支付接口，用户签约了工行卡快捷支付，用户付款后，资金扣款成功结算后，会进入电商平台在工行的结算账户。注意快捷支付是有经营业务种类限制的，只允许在签约经营范围内的业务收款，即MCC码。

如果是第三方支付公司，因为不允许与银行直连，需使用银联或银行提供的网联接口，用户支付后，网联结算后，金额会转移到支付公司在银行开设的备付金账户。

对于电商平台，与银联对接要方便快捷得多，一次接入即可搞定大多数银行卡的快捷支付；而对于有支付牌照的电商平台或第三方支付公司，为了更低的手续费，才会选择与银行直接对接。

银行卡快捷支付，需要先绑卡签约，后续则无需任何验证完成扣款，而为了安全性，电商平台会加上指纹、人脸、短信或支付密码验证，仅小额支付可以免验证。

快捷支付的签约，需要提供三要素（姓名，身份证号，银行卡号）或四要素（银行预留手机号），信用卡可能额外需要有效期和背后后三位数cvv。注意支付公司或电商平台是不允许保存用户的cvv码的。在快捷支付签约前，用户需先完成实名认证或更高级别的认证，以保证签约卡为本人银行卡。国家法规对于第三方支付用户的信息验证有3个等级，三级为最高安全等级，对应的付款限额和支付范围限制也更大。

对于第三方支付公司，为了安全性、手续费等原因，会与同一家银行，不同的总行分行，或者银联等其他通道，分别签约快捷支付；用户在绑卡签约时，或者后续签约支付时，可能在签约一个需短信验证的通道的同时，还签约了其他无需短信验证的通道。后续用户使用快捷支付时，支付渠道路由会自动选择当前最合适的支付通道发起扣款。对于同一张卡的快捷支付额度，使用不同的支付通道的额度是独立的，但总额不超过发卡行的限制。

对于产品侧来说，如果要实现快捷支付功能，前端需要实现签约卡管理、新增签约（录入卡信息 - 识别卡信息 - 签约结果返回）、解绑功能。

不管是第三方支付还是快捷支付，和支付公司签约时，都可以绑定多个收款账户，有时为了财务上的区分，不同业务可使用不同收款账户收款。

银行转账基础原理

跨行转账有超级网银和小额转账两种，限额都是5w以内，开放时间都是7*24小时，不同的是超级网银实时结算，小额转账银行跑批处理，是准实时的。大额转账是在5w以上，开放时间是工作日的 8:30 ~ 17:00，实时结算。银行提供的转账产品，基本都是基于上述三种方式包装的。

电商业务的退款、商户结算、佣金结算、供应商货款结算等业务都涉及到出款。

退款：一般来说，在支付后一段时间内（一般3到6个月），可以使用原支付渠道的退款功能，将资金原路返回。如果超过时间限制或部分退款次数限制，则无法原路返回。退款最多可能5~7个工作日才能确认返回状态；对于银行来说，一笔已经清算的收单交易，手续费已经扣取；就算产生退款，之前的收单手续费也不会退回。如果在结算之前退款，银行侧可能支持按比例退回手续费。第三方支付公司与电商平台之间退款手续费的收取，由双方协议决定。

银企直连：若电商公司已接入银行的银企直连产品，且支付对象已绑定银行卡，则可使用此方式。

第三方支付的代付功能：对于高频小额的付款需求，且用户已绑定第三方支付账号情况下，可使用此方式。

企业网银：一般用于2B的大额资金转账。资金结算或者用户提现。

对于第三方支付公司，用户提现时，同一个出款账户，会归集一定量（金额或条数）之后批量提交银行处理，所以提现不一定能够实时到账。

出款的前提是用户已实名认证，并绑定了实名对应的银行卡。绑卡需要验证四要素，会需要用到第三方支付提供的信息验证接口，或直接与银行对接。已经签约过快捷支付的借记卡，也可以用于该账户资金提现，无需再次验证。

各个支付渠道的接口指令各不相同，为了方便业务调用以及日后拓展维护，需要建立一个统一的支付网关，开放给业务使用；业务调用时同时指定支付渠道，支付网关请求渠道路由，按照事先配置的路由规则，返回最合适的支付通道，发起支付请求。

网关需实现不同类型的功能接口，一般来说就是支付通道侧接口能力的并集，如充值、提现、转账、退款、签约查询、实名认证校验等等。

引导路由：是指用户在付款时，给用户展示支付方式的规则，包含可见状态，可用状态，展示顺序等。引导路由的意义是，根据用户支付的场景，引导用户选择平台侧希望用户选择的支付方式。平台侧的需求一般是支付成功率高（通道稳定，额度充足）、费率低等，也有因不同支付渠道商务合作关系，限定额度分流的原因。

匹配接入的支付渠道比较少时，引导路由作用不大，一般可能只有一个简单的权重配置后台，即所谓的静态路由，或者直接记住用户上次选择的方式即可。

渠道路由：对于电商平台来说，如果只接入了第三方支付，则不存在渠道路由。对于支付公司来说，如果接入了不同银行、银联网联的快捷支付接口，且用户选择的银行卡签约了多个通道时，渠道路由则按照路由规则去匹配权重最高的渠道，发起扣款请求。

在断直连之后，支付公司的代收服务，只能通过银联或网联接口，因此渠道路由意义也削弱了。对于代付服务，支付公司会在各大银行都开设收付账户，将跨行转账都转化为同行转账，以提高转账速度免除手续费，同时支付公司需要做好备付金管理系统，自动或人工管理监控调拨各行备付金。

当业务向支付网关发起支付请求时，支付网关需要对业务方进行鉴权判断，确定请求是否合法。一次支付请求一般包含以下元素：业务标示，支付时间，支付金额，支付账号，支付客户端信息，支付订单信息等。支付网关需要确认各个元素都合法，比如支付时间是否在有效期内，此支付单是否过期；支付账号状态是否正常，支付订单是否是可支付的，商品是否有库存等等。同时还需要将这些信息过一遍风控，风控那边会根据各种规则判断此次支付是否有风险。风控是一个比较复杂的系统，属于另一个专业领域，在此不细说。

电商平台向支付渠道请求支付后，支付渠道会同步或异步返回支付结果信息。如果支付渠道不主动返回结果，电商平台侧则需要定时去轮询结果。同时电商侧需要将支付请求信息、结果信息、结果凭证等保存下来，也就是支付流水记录。支付流水记录是之后电商与支付渠道对账的凭证。

拿到支付结果记录后，支付系统需要向支付请求方返回支付结果，同时通知账务系统，触发对应的记账操作。

各个支付渠道都会按日和按月生成交易记录文件和资金流水账单，分为支付、退款、提现等类型。交易记录文件相当于信息流凭证，资金流水账单相当于资金流凭证。

银行渠道一般也会推送资金流水文件，但不是所有银行的交易都有业务对账文件，通常收单交易业务对账文件会普遍一些。

电商的支付系统或者对账系统，需要做的事情：

支付系统同样需要和上游各个业务系统进行对账，包装支付状态金额的一致性。一般采用明细轧帐的方式。

收单对账常见问题：

长款：用户支付了但是交易系统未确认支付成功，这种情况需要及时补单或者退款处理，一般如果业务侧订单状态是待支付则可转为支付成功，状态是已取消则自动退款；也有可能是测试数据混入了生产环境；也有可能能与之前的短款差错互相抵消；

短款：一般是日切问题导致，挂账后下个会计日继续对账；或者看是否能与之前的长款差错互相抵消；

重复支付：一般支付渠道都不允许重复支付同一个订单，发现重复支付也可以自动退款处理；

金额不一致：可能用户支付后，支付结果返回之前，交易系统订单金额变化了

退款常见问题：

网络问题或接口问题导致退款失败，这种情况可自动再次提交退款；

对方账户状态异常导致退款失败，这种无法走原路返回退款方式，只能转账/代付；

退款时需要处理好支付手续费的退款，以及退款手续费谁来承担的问题，一般是按比例退；

对于短款差错，可挂账7天处理。

提现常见问题：对方账户状态异常导致退款失败，需要及时通知用户处理。对于短款差错，可挂账3天处理。

产品侧需要设计对账管理后台，可查看支付流水，对账批次记录，差错处理后台等。对于固定处理方式的差错类型，可做成自动化处理。

合单支付是指用户一次支付多笔订单，在电商中很常见。电商业务侧需要自己做好订单拆分，支付系统中，如果使用支付渠道的合单支付接口，则会自动拆分记录支付流水，是最佳的方式；如果支付渠道没有合单支付接口，则可拆可不拆，按原始记录保存简单不易出错，拆分记录则可方便其他业务处理。

混合支付是通过多种支付方式，支付一笔订单，比如余额+快捷支付。混合支付会按照不同支付方式，生成多笔支付流水。

因为不同支付方式，支付成功率不同，可能会发生有的支付方式扣款失败的情况。因此混合支付需要按照支付成功率，优先扣款成功率较低的支付方式；如果有某些支付方式扣款失败，需要判断是取消支付，全部退款，还是提醒用户换其他方式继续支付；全部支付方式都扣款成功后，这比订单才支付完成。后续订单发生退款，如果是部分退款，需要判断，优先退款手续费最低的支付方式。

电商平台或支付公司有时候会做营销活动，出钱补贴支付，也可以用混合支付方式处理。

据说余额+卡的混合支付有洗钱风险，目前已逐渐少见。

对于大额订单，可以采用分次、分阶段支付的方式，实质也是一种混合支付。

订单完成时，电商平台需要扣取平台佣金，结算货款给商家；若涉及推广服务，则需要计算推广用户的佣金和税额，再结算给推广用户。

按照法规，没有清结算牌照的电商，不允许自行截存货款，之后再结算给商家。电商平台可以选择第三方支付公司或者使用银行的电商清结算产品，由他们代为保存货款，之后再结算给商家。此类产品需要先提交商户资料给支付渠道或银行审核，审核通过后，用户支付此商户订单，提交支付同时上送清分规则（分给哪些人，按照什么比例或金额）。在订单交易完成时，电商侧提交结算请求，支付平台按照此前支付时上送的清分规则进行分账结算。部分支付平台，需要在结算时由电商平台指定分账对象和金额，但这样略有二清嫌疑。

选择这类清结算产品时，还需要注意以下几点：

接入此类产品后，除了后端的支付、结算接口对接以外，电商平台商户侧客户端，也需要对接好商户入驻进件，提现账户绑定，结算账单等功能。

电商平台常见的分销、主播代销、拼团、淘宝客等销售模式，其中“分销商”或“团长”角色，本身不是销售主体，在订单完成后可获得推广佣金。一般来说，这部分推广费用，在订单生成后，商户侧可在订单费用明细中看到此支出项；在订单结算时，可将推广佣金与平台佣金一起扣除，再由平台将推广佣金结算给推广人员。

这类支出属于劳动报酬，平台有为推广人员代缴税的义务，需要按月计算税率和金额。因此部分平台采用月结的方式，每个月指定日期，计算每个待结推广人的税费，扣除后再将税后金额结算给推广人。也有部分平台（比如O2O，网约车平台等），会自己承担此部分税费（羊毛出在羊身上），在订单结算时，即时将推广佣金结算给推广人，次月再统计推广人税费，平台自己为推广人交税。

平台也可以采用各种税务筹划方式，比如“灵活用工”的方式，与推广人建立非全日制劳务关系，这样推广人可以享受更低税率。

平台自行结算给推广人，可使用银企直连、支付平台代付等功能进行出款。而平台代缴税需要推广人的实名信息，所以在推广人在提现佣金之前，需要先实名制认证。

不管采用哪种结算方式，电商平台都需要计算订单结算时的各类费用明细（清分），负责清分的模块，也叫做计费系统。

电商平台有花样百出的扣点规则，比如按商品、按商户、按品类、按营销活动等规则扣点，以及各类推广佣金等。扣点规则路由对应着各类扣点规则，比如针对商品、商家、类目的扣点规则管理后台，基本元素是扣点对象、扣点比例、扣点上线、规则生效时间范围、规则状态等。产品经理需要和运营人员确认好扣点规则判断逻辑，即根据怎样的条件判断顺序，确认订单适用的扣点规则。之后加入新的扣点规则时，也需要维护这个扣点规则路由。

扣点规则路由各电商平台都不一样，可能包含营销活动、下单/支付客户端、买家身份、扣点规则权重等等。

一般在订单创建时，扣点规则路由就需要根据订单相关的信息，判断出订单适用的扣点规则并记录下来。同时也需要将用于判断的信息元素保存下来，以作为之后核对凭证。

如果订单有推广员的参与，则也需要在订单创建时，计算出需要扣除的推广费用，并保存记录相关推广员信息。

在计算各方分账明细时，需要注意几点：

与订单交易相关的清算，一般来说，是在订单状态变为终态（交易完成，退款完成），且订单尚有待结算金额时，由交易系统向清结算系统提交清结算请求。也有一些多次结算的场景，比如订单里有部分商品先确认收货时，也可以先结算部分金额，后续再结算剩余金额。

对于有支付牌照的大型电商平台，为了提高商户的回款速度，也可以在订单尚未变为终态时给商家结算货款，比如用户确认收货时或者商家发货时。如果结算后订单发生退款，则再在商户钱包中扣除相应金额。此类结算方式需要平台侧有比较成熟的风控能力，通过风险控制和风险转移的方式，防止平台资金损失。比如和商户签约协议，设置商户保证金，商户&买家风控，购买对应的赔付保险等等。

交易系统向清结算系统发起结算请求时，需提交结算订单、结算金额、结算类型（完全/部分结算）等字段。清结算收到结算请求后，可能实时结算，也可能异步周期结算，比如每X小时一次等，视业务量大小决定。

开始结算时，计费中心从账务系统获取订单待结金额，根据结算类型核对结算金额，核对无误后，冻结待结算金额，并提交到计费中心；计费中心找到订单快照中的扣点规则，计算分账明细。

计费中心计算出各方分账明细后，需要和账务中心进行实时或准实时的对账，保证需结算的金额等于各方分账明细之和。核对无误后生成预结算单。

大部分订单，此时结算中心可将结算单提交到支付系统，进行最终的资金转账。小部分订单，结算单可能需要人工审核，则需要审核通过后再提交到支付系统，或者驳回撤销此次结算。

各分账方一般会提前在支付系统内部开设好账户，支付系统会将资金结算到各方的资金账户中，对于支付系统来说，仅涉及内部账户间的资金转移，因此很少会出现结算支付失败的情形。

支付系统返回结算成功结果后，结算单状态变为结算完成；结算系统需要实时通知交易系统和账务系统，账务系统记录各账户资金变化，更新账户余额；交易系统则触发对应的消息通知等关联服务。如果有会计系统的话，也需要异步通知会计系统，进行会计分录记账。

对于成熟的支付公司，会有账务系统和会计系统两套系统。这两套都是以会计分户模型来设计，不同的是账务系统是直接面向业务使用，随着业务信息流实时记账并更新余额，账务流水更多记录交易相关内容；会计系统是面向财务会计使用，一般是异步入账，使用严格的复式记账法。

账务系统中的账户，必须是在是账务系统分户中的叶子科目下。两套系统之间的分户模型，会有多对多的关系。账务系统这套体系可称为分户账户（外），会计系统这套称为分户账户（内）。

按照复式记账法，一般分为资产、负债、损益、共同类等。

交易的实质就是各金额账户间资金的转移，因此首先需要建立好对应的账户。

账户设计遵守三户模型：客户、账号、账户。

客户：指自然人或企业，必须要实名认证才可以开通支付账户，客户以身份证号为唯一标识。

账号：登录账号，一个客户可以有有限多个账号，即一个身份证可以用于有限多个账户用来实名认证。但对于同一个支付公司，一个身份证下多个账号，支付额度上限是共享的。根据身份认证信息丰富程度，支付平台余额账号等级分为一二三类，3类拥有的支付额度和权限最高是20万/年。余额提现、余额宝支付、信用支付无年度额度限制。银行卡快捷支付签约、提现银行卡绑定等操作，也是以账号为主体操作。

账户：每个账号在支付平台或电商网站，都会有多个不同功能的账户。商户侧有货款结算账户，保证金账户；买家侧有支付账户，信用支付账户，积分账户；或者电商平台侧的内部账户，比如活动补贴账户，订单担保账户等。

账务核心主要有四张表：分录流水、分户账、明细账、总账。

首先需要有一个交易码 - 分录规则的分录规则表，用来维护每种用交易码区分的交易场景，发生时应该如何拆成会计分录的规则。比如定义交易码1001为订单银行卡快捷支付，那一笔订单付款流水，经过支付平台，同步到账务中心时，根据同步过来的交易码1001，找到对应的分录规则，按照规则中的定义，生成会计分录：

当一笔业务发生时，首先生成分录流水，然后驱动账户余额变化，账户余额变化后，生成明细账。日终根据分录流水生成总账。根据业务需要，也可以先修改账户余额，然后异步生成分录流水，但是无论先生成会计分录，还是缓冲异步生成会计分录，都要保证分录流水与分户账余额的一致性，这一点通过日终系统的检查来保证。

每天首先需要做支付渠道的对账，然后再进行账务系统和会计系统内对账。

需要做到：

错处理需达到2个效果，一个是完成对账，另外一个是将账务对平，常见的账务处理方式有挂账、登账、调账。

补单：通过人为干预方式，将原有业务进行下去，如通过接口人工干预订单状态

挂账：对于不平账单，先挂起，等查明后再进行相应处理

登账：会计记账，伴随虚拟资金从一个账户向另一个账户转移的过程（原始凭证）

1、多账

多账主要存在2种情况，一种是异步通知未收到，优先采用补单处理，另外一种是同订单2次支付，一般通过登账处理

2、短账

基本不会出现，一般通过签名防抵赖机制与第三方协调处理。协调一致后通过人工增加对账单进行平账。

3、金额不一致

出现概率极低，一般为电商平台内部计算有误。

首先得先解决此bug，然后根据异常订单相应处理，比如说撤销对账，修改系统或对账单金额后再进行对账。