本文档从“支付产品技术交流群”的2017年5月25日聊天记录整理出来，感谢@Fiona 同学的整理工作。
1. 专题分享: 渠道管理和渠道接入
1.1 支付渠道关键名词解释
- 支付渠道描述：支付渠道即资金转移的通道，也称为资金渠道、支付通道，与现实中“运输交通” 相似，先修建道路才能运输，先建设渠道才能支付。支付路由就类似交通导航，公路、航线一般有编号，渠道也会进行编号，支付收银台就类似于导航界面。交通导航与渠道路由影响因素也比较相似，但在算法实现上是有很大区别的。常见如下：
- 支付渠道性能：对于接入银行的渠道，很多都通过前置机与银行交互，一般银行都会限制请求并发数，如何控制并发是渠道路由系统需要重点关注的问题。另外专线接入周期长，且一般都使用硬证书。最好能以软证书+公网方式接入。同步返回结果的优于异步通知的。
- 支付渠道掉单：由于与银行交互，会存在超时、异步通知不及时的情况，造成支付结果一直处理中，这种情况下需要系统自动去查询结果，隔日掉单的在T1日需再补单一次。补单策略固定周期，固定周期+延迟，灵活控制各个渠道查询接口的起止时间范围，如有些银行退款要T+1处理的。
- 支付渠道降级：由于是与银行交互，会存在超时网络异常，或交易连续失败等异常情况，需要对渠道权重降级，交易正常后需恢复权重。例：动态权重初始0，且不大于0，超时或失败一笔交易权重-1，成功+1；动态权重低于-10发送邮件短信提醒。依据实际业务进行优化。
1.2 系统交互流程
- 渠道路由：主要包括渠道配置，渠道路由，任务调度子系统等；统一接收所有与银行有关的请求，通过路由选择合适的支付渠道，与下游渠道应用交互。任务调度子系统主要出款、补单及其它批量处理的任务调度。
- 渠道应用：按银行的支付业务划分，对应银行一个实际的支付通道，如同一个银行B2C、B2B、银企直连、快捷、代扣独立分开部署5个渠道应用。在渠道管理上多个虚拟的支付渠道对应一个渠道应用。
- 银行前置机：使用硬证书的通道一般都要部署银行的前置机软件，通过前置机与银行交互。
- 银行回调：公网统一接收所有银行回调的应用，主要基于网络安全考虑，渠道应用不能通过公网直接访问。实现同步请求，虚线异步通知
1.3 渠道模型设计
1.4 渠道分类
- 渠道：一个渠道对应一个虚拟的支付通道，银行的一个实际支付通道可以虚拟成多个渠道，如B2C网银虚拟成借记、贷记、综合3个通道。一个渠道包含多个接口共同提供完整的支付服务，渠道可以设置维护期、特性、优先级权重。
- 接口：一个渠道通常包含多个接口，组合起来才能提供完整的支付服务。不同的支付模式对应不同的接口，如快捷支付包括签约短信、签约确认、支付短信、支付确认、单笔退款、单笔查询、对账单下载、通用接口等。不同接口通常会有一些特殊扩展属性配置，如查询接口订单补单时间范围，退款接口转人工处理延迟时间，出款接口是否支持拆单等等。
- 目标机构：目标机构即支付渠道可以支持的银行（中行、工行等）、第三方（微信、支付宝等），对于接入银联、主备付金跨行出款、第三方支付的渠道会有多个目标机构，如主备付金银行跨行出款可以支持多个银行，接入第三方快捷渠道也是同时支持多个银行。
- 特性：渠道或接口都可以设置特性，特性来自交易中要素，特性标识渠道的特点，任何一个交易要素都可以配置成特性，有相等、大于、小于、包含、不包含等匹配规则，常见特性如终端类型、卡类型、商户ID、会员ID、对公对私、借贷、会员ID、交易订单号、当前时间、业务产品、支付产品、金额、目标机构等等。路由时特性可以达到绝对限制或放行的目的，如限制当前渠道不允许某个商户使用，限制该渠道必须发短信才能支付，限制只支持借记卡等一些临时性的限制。
- 维护期：渠道或接口都可以设置维护期，可以指定到具体的目标机构银行，维护期间渠道或接口通常是无法提供服务的，路由时入款、退款、出款对维护期处理逻辑通常会不一样，入款或实时出款直接返回失败，其它退款、出款正常路由，维护时间结束后通过任务调度提交银行处理。出款也可以渠道全部维护期的订单暂停，通过定时任务尝试路由。
- 限额限次：限额限次设置在接口上，可以指定到具体的目标机构银行，目标机构为空表示对该渠道所有目标机构银行设置相同限额。路由时过滤掉不满足限额的渠道，出款时也可用来拆单。
- 优先级权重：渠道和接口都可以配置优先级权重，可以使用固定值或动态脚本（velocity，groovy等）,脚本参数为交易中要素信息，可以分类，如成本、稳定性、服务时间等。渠道、接口可多个配置计算得分累加，单个可负分，累计不小于零。优先级优于权重，多个优先级一样时，按权重分配，路由时先渠道后接口。优先级通过表达式计算获得，权重一般直接配置数值。
- 优先级与权重计算示例
1.5 渠道路由流程
1.6 补单
关于补单，通常会入款、出款、退款分开，可以按支付模式分别创建不同定时任务调度，更细粒度可以按银行实际支付渠道创建。如对于网银支付可采用如下策略：
- 固定周期补单（5分钟）蓝点
- 固定周期+递进延迟补单（+次数*5分钟）红点
- 订单范围默认（-10至-60分钟）接口支持动态调整
1.7 结果码
对于不同支付渠道，每一个银行返回的结果码一般都不一样，银行结果码也可能增加或减少，为灵活判断结果吗对应订单的状态，以及给用户返回友好的提示信息，需要对银行结果码进行转义。对于在交易过程中出现的新结果码，先挂起交易为“处理中”状态，插入数据库一条未转义的结果码记录，并同时邮件通知响应技术人员进行配置。
1.8 余额预警
一般来说通过定时任务出款，都会先校验备付金余额是否足够，若余额不够提醒结算人员余额不够人工调拨资金，或触发系统自动调拨机制。同时系统缓存当前银行备付金余额，对于实时出款可进行一次判断过滤掉该银行的通道。
1.9 订单号规则
订单号是提交银行交易的唯一标识，为通过订单号就能快速识别交易从哪个支付渠道发起，从设计上不同银行接口采用不同的订单号生成策略。通常策略：前缀（渠道编号）+日期段+序号，个别银行特殊要求，如必须全数字，前缀用数字即可。
1.10 订单重发
由于网络超时原因通常通过查询结果，有时银行会返回交易不存在，依赖银行查询结果的准确性，以及交易幂等性，可考虑重发交易，重发的交易不能改变订单号。
2. 在线问答
Q：渠道降级这块是全自动化完成嘛？
A：渠道降级有做的，不过不是实时的
Q：上面提到的渠道成功权重+1,失败-1，这部分数据是放到什么地方的？通过什么机制通知渠道服务？
A：各个服务器内存计算，30秒同步一次远程缓存，看容忍度的。
Q：红色区域这部分能详细说下么？这个是消费类产品的路由设计么？
A：过滤超载实时的比较难弄，目前我们主要做了定时出款的，统计通道订单积压的情况；红框那部分主要也是针对出款的；一个通道订单太多了处理不过来，直接走其他通道。
Q：那余额不足的是用在哪里的？
A：出款备付金余额不足的情况。入款快捷、代扣余额不足次数过多的，直接在网关层就会拦截的。主要我们垫资的业务比较多，经常会余额不足要调拨资金。
Q：支付订单提交后，若是异步通知，一般依据什么机制，然后把失败结果返回给商户？
A：一般通过异步消息驱动，使用消息中间件
Q：有没有多渠道同时成功的，谁发起原路退回？
A：有没有多渠道同时成功的，能举具体例子么？
Q：比如一笔支付先用a渠道，超时了用b渠道，两个同时回调
A：你们是内部做了自动重路由吧，我们不这么做的，这种问题比较多。可以缓存下卡失败的通道，用户在发起从缓存过滤这个渠道。
Q：支付订单的有效期一般设置多长时间比较合理？
A：看交易量吧，交易越大就会设置越短，交易一直中间状态不合适。我们现在7天。
Q：对于某些渠道，当交易笔数或者交易总金额到达某一个阈值后，成本会有变化，对权重和优先级是有影响的，这部分你们怎样实时实现的？
A：渠道手续费 阶梯计算，其实没必要实时去计算的，差不多到了人工调整下优先级就行了。一定要做的话，建议也单独计算。毕竟成本只是一个影响因素。
Q：关于补单，如果商户收单状态不对，等着补单解决单据一致问题，但等五分钟或更多，是不是时间太长了。
A：补单交易多可以一个渠道一个任务调度，单独控制周期、延迟时间、起止时间等等
Q：最近遇到一个问题，由于通道通知延迟，补单无法进行，商户闹心
A：能详说下么。是补单查询一直没明确结果？还是补单时间太短，通道很晚才成功？而你们后面没有再查询了？
Q：补单的通知，通道过来延迟太长，有些单子延迟了五个小时，不过比例不大。您说的查询是商户主动，加平台自动？
A：掉单率太高换通道吧~
Q：对于银行回调地址你们是每接一个都有一个回调地址还是统一走同一个回调地址的？
A：走公网的一个， 专线的一般点对点不一样的
Q：走公网的，回调的时候对结果码转义那不是要一个个做判断，并且加一个银行改一次代码了？
A：后台统一地方配置的，渠道、接口、结果码、子结果码、统一结果码，订单状态。
Q：对不同接口的各个特殊属性是怎么存储的？
A：数据库中是一个属性一条记录，加载到缓存直接转换为对象，渠道缓存本地+远程结合。在数据上也会做多级缓存，支付模式+借贷+终端类型，支付模式+借贷，支付模式。
Q：特性的过滤是通过可配置化实现的吗？能讲点思路不？
A：基本偏向技术维护的，特性就是配置一些验证规则，交易是否满足这个渠道。如下图：
Q:对于商户订单处理，有没有用引擎方案或状态机方案的？
A:如下图
Q：这个状态机你们怎么做的？规则引擎+流程引擎做的么？我在考虑微引擎，实在不行自己写一个，代码写也比较简单，也就那有限的状态切换再加上行为调用，商户通知也是在这层消息驱动的吧？
A：{请关注5月26日的记录整理，这个问题在这个记录中有回应}
Q:优先级一般分类有哪些，会不会写死的，如何做成配置化?权重占比又如何确定，是要用模型去跑的？
A:可以脚本动态计算;
#if((($time>=2350 || $time<=0050) && $targetInst=='CMB') || (($time>=2030 || $time<=0300) && $targetInst=='PSBC')) 50
#elseif($partnerId == '200002394692'|| $partnerId == '200002394691') 200
#else 130
#end
权重主要用来分配流量的，多个通道都要分点量。。
Q：渠道路由流程这个图是用了责任链模式去实现的？在高并发下，渠道电如何去分流的？
A：{请关注5月26日的记录整理，这个问题在这个记录中有回应}
3. 话题整理
3.1 秒杀场景高并发下的商品库存处理
Q：请教个问题，一个商品库存只剩一个，怎么避免高并发的情况下同时有多个请求但只会有一个人买到这个商品？
A1：这个方案还是比较多的，放在数据库中就用锁机制，防止库存为负，放在内存中用FIFO也是可以的，队列空了，就秒杀结束了
A2：应对秒杀场景，业务逻辑上，在下单的是后锁单扣库存；不能以支付成功后扣库存
（数据库的话，带条件 库存数-1>0 ？）
（库存和账户原理上是类似的，保证余额不能为负就可以；带条件那个是乐观锁了）
A3：这个要有几层限流，预估库存，根据库存数放行，一层层拦截流量，光靠数据库锁保证，肯定挂啦，增加验证码，延迟用户请求，很多；利用redis 或者其他原子操作保证
A4：验证码防机器人 共享内存做01初步过滤数据库事务做最后保护；数据库可以当做最终一致性保证，秒杀服务要根据秒杀规则提前load 活动库存或者活动库存主动推送，做第一层保证，这样大部分流量都拦截住了，到了下单环节再用库存微服务自己的的原子操作卡，多重保证；
A5：合并事务操作可以大幅减轻数据库压力。只是个想法 还没经过实践考验 类似批量处理 合并以减少数据库的操作 比如只改内存 然后定期与数据库同步 或者写日志后台触发存储过程合并更新 还涉及到数据库的结构特性等条件约束 比如update比insert的成本要高的多 怎么规避或替代 都只是些想法
- 写内存 万一宕机了 数据会不会就都没了？
- 是啊 内存不可靠 但概率有多大 说到底还是看你容忍度；当然敏感数据肯定不能采用可靠性差的方式 数据和数据不一样 表与表也不一样
- 写内存不如直接写日志文件
- 付系统比较特殊 即使是电商这种 一个系统里真正敏感的数据有多少? 就那么一点点吧 像现在常见的开发习惯 比如java用的spring带的那种事务控制 程序员为了图方便 清一色的update* find* 这样会导致改昵称和改余额一样重 这样肯定不好吧?或者多种方式结合 看具体情况看数据看条件
最终看矛盾在哪 以及有多大 本来资源紧张 不同的需求针对性采用不同的方案 不是几个开源框架凑一起就完事了:) 这不是主流思路 当个参考吧
3.2 隔日退款场景的对账系统设计
Q：想请教一下使用支付产品的商户后台是如何设计对账系统的呢，因为现在一涉及到隔日退款，就会出现帐不平的现象
A2：你说的这个属于渠道对账，理论上说，渠道应给的不仅是交易对账单，也就是流水，还有结算对账单，也就是结算资金，有的是分开发的，有的是合并发的，对账的目的主要是为了最终的钱一致。 所以，支付公司对账都是按通道也就是金融机构进行分别对账，这里面要确认一是哪些交易参与对账，只有参与对账的交易对不上，才需要进入差错，隔日退款账不平的原因是因为如果当日的可以走撤销，隔日了交易已经清算了。所以对于退款的对账，要与渠道确认，此笔账应记在哪期中对。我这边的流程不是交易记录直接参与对账，而是会先走定时清分，与通道对账的交易都是已经清分完的。今日的叫撤销就分开了，隔日才叫退货
（当日的全额退款才能走撤销吧，部分退也能走撤销接口？）
（撤销一般都是全额；退款与撤销是交易名称层面的东西，你也可以换个叫法，叫清算前退货和清算后退货，清算前退了，结算时就不会有这笔交易了，清算后退的，当日结算款里还是会有这笔交易款的。）
3.3 银联收单的前置系统
Q：如图，这里买的银联前置系统和收单机构的前置系统分别指的是什么？
A：一个是银联的 一个是你的 是有这个区别吗 要不就是他的图画得不清楚
3.4 关于网贷整改
证券时报网：网贷整改大限倒计时：五大重点进度挨个数
第十一条 支付机构应根据客户身份对同一客户在本机构开立的所有支付账户进行关联管理，并按照下列要求对个人支付账户进行分类管理：[一]对于以非面对面方式通过至少一个合法安全的外部渠道进行身份基本信息验证，且为首次在本机构开立支付账户的个人客户，支付机构可以为其开立Ⅰ类支付账户，账户余额仅可用于消费和转账，余额付款交易自账户开立起累计不超过1000元[包括支付账户向客户本人同名银行账户转账]；[二]对于支付机构自主或委托合作机构以面对面方式核实身份的个人客户，或以非面对面方式通过至少三个合法安全的外部渠道进行身份基本信息多重交叉验证的个人客户，支付机构可以为其开立Ⅱ类支付账户，账户余额仅可用于消费和转账，其所有支付账户的余额付款交易年累计不超过10万元[不包括支付账户向客户本人同名银行账户转账]；[三]对于支付机构自主或委托合作机构以面对面方式核实身份的个人客户，或以非面对面方式通过至少五个合法安全的外部渠道进行身份基本信息多重交叉验证的个人客户，支付机构可以为其开立Ⅲ类支付账户，账户余额可以用于消费、转账以及购买投资理财等金融类产品，其所有支付账户的余额付款交易年累计不超过20万元[不包括支付账户向客户本人同名银行账户转账]。客户身份基本信息外部验证渠道包括但不限于政府部门数据库、商业银行信息系统、商业化数据库等。其中，通过商业银行验证个人客户身份基本信息的，应为Ⅰ类银行账户或信用卡。
Q：什么叫网贷？这个完全不明确，p2p一定是网贷 其他互金算不算？
A：{请关注5月26日的记录整理，这个问题在这个记录中有回应}
3.5 代付问题
Q：D0和T0这样资金结算的是不是属于代付？
A：{请关注5月26日的记录整理，这个问题在这个记录中有回应}
正常的资金清算模式是T1模式：客户消费后，收单机构(银行或第三方支付公司)将交易信息传输给清算机构(中国目前仅银联一家)，清算机构再将信息传输给持卡人的发卡机构，发卡机构根据交易信息将持卡人账户中的资金扣除，并将资金转到清算机构，资金便在清算机构沉淀一个晚上。等到第二个工作日的凌晨，清算机构将这笔资金转到收单机构所指定的账户，清算过程完成。因此，现在所有的T0、D0清算模式，均为机构垫付
- 上面这段话对吗？
- 资金不在清算机构沉淀
- 银联进行日结、清分、与各机构进行对账后，才发生资金转移吧
银联转接的标准交易及资金清算模式（T1模式）： 交易：客户消费，收单机构(如第三方支付公司)将交易信息传输给清算机构(中国目前仅银联一家)，清算机构再将信息传输给持卡人的发卡机构，发卡机构根据交易信息将持卡人账户中的资金扣除，支付成功信息从发卡行经由清算机构再传递给收单机构，交易达成。 结算：T+1日凌晨，清算机构通过央行二代清算系统，轧差结算，调拨发卡行和收单机构所在收单行在央行的备付金头寸，完成跨行结算；收单行再行内结算至收单机构备付金账户，收单机构最后与商户结算，结算达成。
- 以上如有谬误，请指正
- 解读很到位
- 这里有些特殊情况，如发卡行和收单行是同一家时，一般不经过银联；跨行才会走转接机构
- 详见下图
3.6 信用卡逾期罚息
Q：信用卡算逾期利息的时候，是当天一开始就将当天的罚息算好入账的嘛？
A1：只记不收；账单一般不是有一个宽限期的么~在宽限期内，只计算，放在账务系统的贷款利息计提
3.7 账户冻结资金
Q：你们账户冻结资金算不算入账户余额
A1：应该是算入资产，不算入余额
A2：按照常规P2P虚拟账户类型的应该是不算入余额的 不过 我现在是企业之间大额交易 这个冻结资金是怕账户出现异常添加的一个资金状态 这个也不加入账户余额吗
3.8 京东绑卡
Q：问京东的帅哥，浦发信用卡在绑卡支付的时候，短信是银行发的还是京东自己发的？
A：{请关注5月26日的记录整理，这个问题在这个记录中有回应}
3.9 卡bin/开户行&联行号
Q：这边谁有最新的卡bin 表，可以分享下吗/是否有支付公司 或银行 有没有可以查询一个银行卡的开户行 和 开户行联行号的接口？
因为我们有个场景是需要用户选 自己卡的 开户行。 但是我们的联行号表不全，很多银行选不出来。
A1：这个可以查
A2:卡号作为收款卡号，做代付的时候，一般代付接口都需要开户所在省市 或 联行号。但是查不出一张卡的开户行
A3：除了大小额，其他应该不需要吧。超网和银联代付都不需要联行号或者开户所在省市。对公的也看走什么渠道。而且一般对公的客户，自己知道自己的联行号的。（题主回复：我接的支付公司， 对私的都要联行号呢。）
A4：我也有联行号的表 但是也没那么全 逐步维护中 大概14万多家吧
（题主回复：我有13万条，都不全）
A5：换渠道吧；对私都需要联行号的 那估计是支付公司不太行
A6：联行号应该可以找银行要的；最好从银行拿，支付机构也是从银行拿的，我记得中信可以直接下载，建行也可以直接下载，网上也有开放的平台可以查询，搞个爬虫爬一下
A7：第三方机构应该都有联行号维护，我们也是从第三方拿到的，银联对公开户行名称，其实是变相的联行号，对公需要开户行名称
3.10 银行发卡量
Q：有没有查看银行发卡量的方法啊 不用实时的 滞后点的也行？
A: 目前无
3.11 二清/结算/分润
Q：大家怎么看央行说的大商户模式（二清）啊？ 这种B2B2C的模式会消失么？ 例如：京东非自营，美团
A1：这两家都持牌了，合规合法；只要不涉及二清，应该都是合规的
A2：我觉得不会啊。。。 京东有网银在线，但是微信支付如果直接结给京东，那京东再结给商户，就是大商户（二清） 如果微信支付结给网银在线，那又是支付机构备付金互转，违规。
A3：二清特指没有支付结算资质的机构，进行资金支付结算；2号令规定支付机构间不能直连；but 间连就好了呀，改下交易结构而已
A4：间连现在看起来是唯一的路，通过银行走微信渠道商模式；现在辣么多第三方支付机构做聚合，都是这么玩的；如果通过银行间连的话，如果平台没有支付牌照，那就是把二清被罚风险转移给了银行，但本质上二清确实避免不了
A5：但这样也只是京东和美团这样有钱的主能这么干（威富通和科蓝不就是干这个的么，然后上市了）（威富通是被上市公司收购，不是自己上市）；京东现在业务跑起来，我猜应该是合规的吧？（现在业务能跑，并不一定意味着合规）如果京东愿意的话，他也就不需要给银行了，还不如直接给微信支付，至少还是同盟（京东有牌照）
A6：一种是通过银行，再一种就是通过用集团去签；银行可以给二级商户结算
A7：多级商户分润系统，关键是系统支持，或者叫多级商户分账系统；蘑菇街、二维火、有赞都因为涉嫌二清被央妈点名了，然后，有赞买了块牌照。。。
- 你们多级分润，会拆成多比收单吗？ 还是在结算的时候做分润的？
- 一笔支付，多笔收单用户受不了，商户账户实时的只是信息流，总额对了就行
- 这个不一定，清算有实时有非实时，有的结算单信息在业务 有的在支付；就是业务方自己算需要给商户结算多少钱，然后告诉支付，有的是支付做这个，然后通过账户划分
- 商户可以做分账系统，清算也可以支持商户多方分账 或者 多方分润；Ｔ０结算需要机构垫资的，目前是Ｔ＋１
- 我还有个疑问，分润信息需要给商户展示吗？ 是在交易明细的唯独还是账务明细的纬度？
- 一般不用展示，商户自己知道的，分润的明细和汇总都可以体现
- 那你们是在账务纬度去展示分润的信息的？
- 给商户有手续费就行了，分润是给分润方看的
A8：蘑菇街不知道改了没有，以前也是直接进蘑菇街的。
本文档来自支付产品技术交流群的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验（2年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。
- 长按或者扫描二维码来打赏，感谢支持群管理工作！
- 请扫码关注“凤凰牌老熊”的微信公众号。
