一、主题分享

hi 大家好，今天我主要分享我16年末到17年初第一次做支付产品的案例（支付路由与对账），当时主要在互联网P2P公司第一次做支付相关产品，可能比较初级

1 需求背景

  1. 受制于快捷支付通道绑卡成功率底下，为了提升通道的绑卡成功率（绑卡关联了实名认证）
  2. 受制于通道限额的影响（主要是代扣），还款金额过大（先息后本）需要多通道拆分代扣
  3. 所有支付订单入账t之后都需要次日通过结算指令结算到存管银行账户，对账采用次日对上一日的交易；

2 前期准备

  1. 支付公司选择主要选择背后支撑通道尽量不一致，比如银联系和非银联系不 支付公司地区不再统一地区，比如北京一个、深圳一个
  2. 支付公司的通道需支持无短信绑卡，代扣限额尽量高（对私）

当时设计的方案大致包含了支付路由设计、风险的控制、账务的三个板块。

3 支付路由

绑卡环节采用2-3个支付通道进行快捷绑卡（主要采用无短信绑卡），即用户首次绑卡之后程序将自动在其余的通道进行快捷绑卡，绑卡的的顺序是先根据银行配置默认的快捷通道，优先在默认的支付通道进行绑卡，不论绑卡是否成功都会在下一个绑卡通道绑卡，最终只要银行卡在任何一个支付通道绑卡成功即绑卡成功；

备注：公司的实名认证主要参考四要素绑卡，用户必须实名认证通过之后才能进行充值、投资、融资等，多通道快捷绑卡更多解决实名问题；用户主动快捷支付（环节）考虑安全的问题，故当时快捷支付更多是单一通道支付，不能实现一次短信多通道拆分资金路由； 样式如下：

20180527_163927

代扣环节主要用于还款，在还款环节由于部分融资金额相对较大（先息后本、一次性还本付息）的情况造成某一期还款资金较大，造成单一通道单日只能代扣部分资金，故采用两个通道代扣还款资金，在支付公司选择上主要偏向于先锋、宝付之类的，因为用户代扣（代扣授权协议书比较简单，基本能够所有支付公司通用）；

路由规则前期主要根据银行来路由，与快捷支付一样都会配置某一个银行的默认支付通道，首先采用默认支付通道，若是默认支付通道代扣成功，将不再启用第二代扣通道；

4.风险控制

由于快捷支付（绑卡环节）无需短信绑卡，而同卡进出不利于用户体验，故当时风控主要采用了同人进出的原则控制，比如用户当日充值的资金未发生任何交易就立即提现会列为关注名单，必须人工确认无误之后才能执行代付；比如用户新更换的提现银行卡没有提现记录，而用户入金渠道多样化，风控时主要采用每张卡入金总额来判断每张卡出金金额的限制，若同一张卡出金金额大于本张卡（新卡）的入金总额，提现审核时需要人工确认；

5.财务对账

账务核对主要采用业务-通道-账务的方式对账，每笔业务充值会对应多条（快捷支付）或（资金代收）记录，系统会根据每次业务发生进行一次账号记账流水（可用余额变化或冻结金额变化）

备注：目前公司系统暂未实施复式记账法，从需求上来说账号流水记账满足当前需求，复试记账更多是财务通过ERP之类的每月单独记账;

20180527_164027

支付订单与支付公司次日提供的对账单进行对账，确保我方记录的支付订单不存在掉单等情况；若存在异常则需要标记异常订单并记录到异常记录表；

支付订单再与业务订单（充值订单或提现订单）进行对比，确保业务订单的发生金额与支付公司入（出）账金额一致，若存在异常则需要标记异常订单并记录到异常记录表；

业务订单在于账号流水进行比对，主要采用期末余额（包括冻结、可用）=期初余额+变化金额（可能为负数），主要基于试算平衡的情况来计算，此项主要以及当日存在账号流水有变化的记录进行业务对账，若当日账号资金流水无变化，不会出现在对账单中；

每个月的支付手续费需要单独与支付公司的提供的账单核对，主要针对

以上是第一次做支付时做得方案，有些还是不是很完善（比如基于算法自动路由（代付）、风险控制还比较薄弱哈。

本文档来自支付产品技术交流群的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验（2年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。