要想理解梳理清楚交易平台的模块与要点，我们需要从哪些方面入手呢？笔者结合业务、风控、支付、结算等方面进行了说明。
上文我们说了支付的一些模块和名词定义，这篇文章说下交易平台。
我将交易平台简单地分为：
业务管理
风控管理
支付管理（收银台+渠道管理）
结算管理
先看下一笔订单交易支付时，简版的时序是什么样的？
一、业务端
以电商类收银台举例，支付的上游是购物车模块，订单的对应关系是n个商品组对应一个业务订单号。
业务单号：支付流水号=1：n
这种对应关系代表同一个业务单号可以在收银台进行多次支付。
举个例子：
小A买东西时用微信支付失败了，此支付流水号和微信订单号是失败的并且是终态不可再改变，业务订单号也是失败的但不是终态；
当订单再次用支付宝支付成功时，该业务订单状态改为成功且为终态。
业务单号：支付流水号：渠道订单号=1：n：n
这样不会重复付款吗？
会。简化来说当支付成功信息没有及时回送到业务端，导致业务端再次发起支付时，这种情况下业务端仅收到一次成功结果就会成功，第二笔支付成功的结果无论是否送达都不会被记录，就产生了重复付款，这也是为什么在结算版块，业务端和支付端会记两次帐的原因。
那为什么业务端要不改变单号进行支付呢？
这个也是根据场景来的，并且会搭配定支付时效来进行组合使用。例如像日常速达类的15min，火车票/机票30min等，都是会有占库存的情况，像服装类的就很少使用同一个单号支付。
我们还以电商举例：当购物车的商品点击结算后，实际上会占用对应商品的库存。取消单号的意味着需要先释放库存再占用库存。如果业务单号不变，一方面可以减少库存占用和读取的压力，特别是商品sku多，时效快的公司；另一方面可以通过时效增加客户紧迫性引导支付。
二、风控模块
目前我接触到的风控相对较少，有相关经验的欢迎分享。
其中不是所有公司都设置风控版块，一般互金公司和大公司会设置风控部门，小型的公司一般是并在it部门内。在交易的时候，如果公司没有能力做风控，就可以将相关风控的职责转嫁给支付渠道，风险控制也是三方渠道提供的服务之一，像支付宝和微信就是渠道自行承担交易风险。
交易风控一般分为三个板块：
1. 事前策略
按照 《中华人民共和国网络安全法》发规定的要求，对用户进行一些信息获取，根据已有信息进行策略配置、标签处理、黑白名单、规则路由等方式来阻挡风险用户。
2. 事中监控
交易发生时，系统根据事前策略进行规则分析，对订单信息、用户信息分析来判断用户的风险系数。根据系数进行对应的拒绝、挂起、通过等操作。
3. 事后处理
事后案件最常见的有两个来源
通常第一例风险用户未被发现当后续该用户再次交易时会把之前的用户订单拉出来比对。此时案件小组就需要进行参与人工处理，包括对应的原订单止损、现有订单拦截、案件分析结果及策略组完善规则等。
当被害用户通过发卡行、媒体渠道、交易平台进行投诉，也是事后风控的处理范畴。
三、支付渠道
一个交易平台渠道的接入和使用的流程如下：
1. 支付渠道挑选
分析现有业务场景，再判断需要的交易模式。不必担心没有相关支付产品，因为可以应势而生。举个例子，国家严查二清，渠道就推出了空中分账产品。
根据自身的优先级挑选渠道，一般接入前能看到的有：渠道的背景、支持的产品、开出的限额、费率、支持对账对款的模式、结算周期等。但近几年 《银行卡收单业务管理办法》严格实施，让各家支付公司从拼价格到拼服务，使得支付的服务向着标准化方向飞速发展。
2. 支付渠道的接入
渠道接入开发时，一般区分为以下两个模块：
交易模板：交易模块一般指代收、代付等。
对账模块：对账一般区分为对交易、对手续费、对资金(支持资金自动结算及账户余额查询时系统可以自行核对)。
3. 支付渠道的使用
当渠道接入完成后，就需要切量了，此时需要根据渠道的限额、签约产品、费用等情况先做备份处理，根据自家路由的规则配置放量。
一般试运营2周左右需要进行第一次渠道试运营报告，报告内容为：渠道成功率、结算情况、服务时效、报错码准确性等板块进行打分，结合现有渠道的评分情况进行路由策略调整及优化。
四、结算管理
当交易支付完成后，实际上整个订单在系统内并没有结束，结算才刚刚开始。
结算简单的说就是交易完成后进行的资金结算，结算常见词汇如下：
1. 资金结算周期
实时结算：资金实时到账，这种结算方式一般是支付渠道垫资行为，所以相对费率比较高。
T+n：工作日+n天结算
2. 结算方式
全额结算：指资金结算的时候不扣除手续费，手续费从另外一个账户结算或者按照一定周期独立扣除
3. 对账管理
通常财务在进行结算的时候使用的是：账实核对和账账核对。
账实核对：渠道账单+渠道资金核对，对账时首先要确认对方入账的资金和对方给到的账单是一致的。
账账核对：业务系统账单+交易系统（支付收银台）账单+渠道账单，此时有任何一个版块的内容有错误都会影响对账结果。
4. 对账差异
将对账异常订单全部放入异常池中，根据以下两种表现形式进行对应处理：
长款：
需要退还用户，通过调用原渠道的退款或代发接口将资金退回。
需要补单，根据原订单 号进行关联单号补单处理。
短款：
秉承谁欠钱找谁要的原则。比如是渠道错误，那资损由渠道承担。系统错误内部承担进行拦截订单止损等。
其实本篇文章中很多东西还可以更细，比如路由策略、报错码管理、对账管理、对账异常池，但我计划是把自己的支付框架先搭起来后再写细节各个功能设计，所以文章看起来框架感较强，我会在后续文章中继续细化版块内容。
从业三年半，面对人生第一个转型及瓶颈，挣扎向前！
欢迎同行伙伴留言：你曾从事支付几年了？现在在做什么？
