支付路由通过分析支付请求的输入参数，返回为当前支付请求分配的支付通道（支付通道）。 支付路由的主要作用是降低公司支付费用，提高支付成功率。

我们以A公司为业务实体，举例说明支付路由是如何设计的。

一、业务介绍

公司拥有两项业务：P2P撮合业务和助贷业务。

1、P2P网贷信息匹配（网上银行存管）

存管银行提供取款服务（提现服务），银行存管系统负责与支付公司对接。 A公司不需要将系统与支付公司对接，但需要分别与各支付公司签订支付合同，并向支付公司支付手续费。

2、贷款援助（自有贷款、金融机构贷款（直接融资））

在贷款协助模式下，A公司需要将系统与支付公司对接，提供存取款服务。直接融资模式的业务流程如下

2 系统框图

3 支付流程介绍

下面介绍一下支付相关的流程。

【定金支付流程】

投资者/借款人充值：投资者/借款人在A公司前端充值，前端请求内部存管系统，存管后端系统请求支付路径。 支付路由返回支付公司代码，前端跳转至银行存管系统发起。 对于支付，银行存管系统向指定的支付公司发起支付请求。 支付公司支付成功后，异步通知银行存管系统。 银行存管系统异步通知A公司存管系统，由存管系统通知调用方。 代扣还款：业务系统调用存管系统发起代扣，存管系统请求支付路由，支付路由返回支付公司代码，存管系统请求银行存管系统，银行存管系统发起代扣代缴至指定支付公司，支付公司支付成功后，异步通知银行存管系统。 银行存管系统异步通知A公司存管系统。 存管系统异步通知业务系统代扣成功，业务系统开始记账等操作。

【贷款援助支付流程】

借款人充值还款：借款人通过A公司前端还款进行充值，前端请求后端系统，后端系统请求统一支付平台，统一支付平台请求支付路径，支付路由返回支付公司代码，统一支付平台向支付公司发起支付（认证前需要认证，认证通过后发起支付）。 支付公司支付成功后，异步通知统一支付平台，统一支付平台异步通知后台系统。 如果支付公司没有异步通知机制，则统一支付平台定期查询支付公司查询接口，内部封装异步接口，通知内部调用者。 代扣还款：业务系统调用统一支付平台发起代扣，统一支付平台请求支付路由，支付路由返回支付公司代码，统一支付平台向支付公司发起支付（未认证先认证，认证通过后发起）支付），支付公司支付成功后，异步通知统一支付平台，统一支付平台异步通知后台系统。 如果支付公司没有异步通知机制，统一支付平台定期查询支付公司查询接口，内部封装异步通知接口，通知内部调用者，并在业务系统中记录和记录操作。 支付服务：暂无路由接入。 支付公司由业务系统指定，支付平台负责与指定的支付公司对接。

统一支付平台简介：统一支付平台集中管理A公司所有资金相关业务，对外负责与支付公司交互，对内提供标准接口：代扣代缴接口、支付接口、认证接口、充值接口等。异步通知接口，业务主要包括代扣、支付和充值。

4 支付路由规则

还款等同一业务包括存托还款或助贷业务还款。 如何区分呢？ 我们用支付场景来区分。

场景包括：存款快充、存款网银充值、存款代扣代缴、非存款快充、非存款代扣、非存款网银。

支付路由规则包括：单笔交易、单日、支付费用、通道维护、单日余额不足数量、最优和次优通道切换。 根据支付路由，输入参数：用户、支付场景、金额、银行，返回调用方的支付渠道（支付公司）代码。

具体业务规则如下：

（1）在支持的场景和银行下，是否有可用的通道。 如果没有可用的支付通道，则返回“无可用的支付通道”。 否则，输入 (2)

（2）计算可用支付渠道下单笔交易的最高限额。 如果充值金额大于单笔交易最高限额，则会提示单笔交易超出限额。 否则，输入 (3)

(3)计算是否满足可用支付渠道的单日限制。 如果所有可用通道均未满足，则会提示已超出单日限制。 否则，输入 (4)

(4)计算可用支付通道的单日故障次数是否满足。 如果所有可用渠道均未满足，则会提示当日余额不足数量已超过限额。 否则，输入 (5)

（五）可用支付渠道不包括单日、单笔交易、单日失败数量不足的渠道。 如果剩余通道等于1，则返回支付通道码，否则输入(6)

(6)根据渠道费率和充值金额，计算(5)可用渠道下各支付渠道的费用，从低到高排序。 如果费用相同，则查询相同费用渠道的优先级，然后按照优先级从高到低排序。 至此，支付公司的支付优先级排序完成，然后进入（7）

(7)查询(6)最优排序的支付通道最新支付是否成功或无交易。 若支付成功或无交易则返回支付通道码，否则输入(8)

（8）查询最优支付通道支付失败的原因。 如果是用户的过错，则返回最优支付渠道，否则进入(9)

(9)查询(6)次优支付通道的最新支付状态。 若支付失败且非用户原因导致支付失败，则返回最优支付渠道。 否则，次优支付通道将被退回。

问答

1 问：您的限额是针对个人用户的每张卡还是针对某个支付渠道，还是两者都适用？ 因为作为用户，有些渠道对交易总额是有限制的。

A：没有办法用卡做支付通道，因为我们不知道支付公司背后的借记通道。 也许支付公司共享信用额度，也许不是。 我们都依赖第三方支付。

问：哦，一般扣款限额是针对某张个人卡的，比如单笔交易5万，或者单日20万。 如果能单独积累的话，其实更有用。 虽然现在扣缴渠道越来越少。 。 。

答：这个是根据用户的情况而定的。 如果用户在支付通道1中支付失败，则可能在支付通道2中成功支付。因此，当用户第二次支付时，如果满足一个条件，我们的系统将自动切换到辅助通道。 你说的是渠道成功率监控，我们会整体监控。 极限问题让我们很头疼。 支付公司给出的限额实际上是不准确的。 比如单笔交易10万元，单日10万元。 如果用户曾在其他商户使用同一支付公司支付过，则有可能同时向我们支付。 即使是笔也无法成功。 目前没有解决办法，所以我们会根据前端的一些错误码提示用户重新尝试支付。

问：您能否给我们简单介绍一下监控指标对渠道可用性的影响？

A：现在根据场景+银行+交易笔数+支付通道，如果交易笔数达到N，成功率低于阈值就会发出警报。

2问：我有三个问题想问你：

（1）如何保证批量扣款的及时性？

（2）如果认证失败，是直接设置失败，还是重新选择路由？

（3）如果多个支付渠道都需要先认证，如何处理？

答：答案如下：

(1)我们需要进行实时扣除。 现在是单一接口，没有批量接口连接支付公司。

(2) 认证失败则设置为失败，不会重试路由。 为什么不重试？ 因为借款人/财务经理在我们公司有预绑定卡（四因素认证）。 这个路由通道和授权通道认证结果不一致的地方比较少，后期可能会优化。

（3）考虑到成本问题，没有提前进行认证。 使用特定支付渠道时，判断是否有认证。 如果没有认证，则会调用认证。 如果有认证的话，支付接口就直接了。 基于这样的考虑，如(2)中提到的，会有预卡绑定操作。 目前针对不同渠道四因素认证不一致的数据监控相对较少。 肯定会有认证失败的情况。 这种情况下，我们的机制是在用户第二次支付的时候切断通道。 之前已经有相关报道了。 首先进行认证，并从认证成功的渠道中进行选择。 但价格昂贵，每笔交易需要1元钱。 就放弃了。

A1：一般银行不是同一部门负责收款和认证，认证比较宽松。 有可能您绑定的短信通知服务的手机号码与银行卡预留的手机号码不相同，但认证时两个手机号码发送时可以通过，但代收时无法通过别人的。 我们与中信银行测试过类似问题，我们的认证渠道是银联。 不过现在中信应该已经改正了，两款手机应该都能用了。 有时间的时候可以尝试一下。

A2：这与银联无关。 这是银行自身的问题。

3 Q：用户发起快速签约（第一次）时，是否需要到各个支付公司去签约？ 这件作品是如何设计的呢？

A：现在我们在付款时会先请求付款路径。 如果路由返回的通道没有经过认证，支付平台会进行认证。 两种模式：（1）P2P业务依托存管体系。 银行存管系统的逻辑是卡认证与支付公司无关。 他们已连接到许多身份验证通道并为我们配置了 3 个。 如果3个通道都没有通过，则认证失败。 如果有一个通道通过，则绑定卡成功。 这意味着用户虽然绑定卡成功，但支付失败。 身份验证可能仍会失败。 存管模式下的认证是静默的； （2）贷款援助模式中，我们自行接受支付公司，并选择主要渠道发放验证码。 静默身份验证用于其他付款。 目前的设计是用户只能接收一次认证短信。

A1：那么用户体验就不好。 用户可能会收到多条合同短信。

A2：这种情况是不可避免的。

A3：好吧，杨妈妈让你这么做，没有任何反抗的余地。 。 。

A4: 您可以先找到稳定的渠道签订合同。 后来付款的时候，如果签约的没有，就选择其他渠道，让他重新签约。 。 。

A5：如果一个支付公司有多个打包渠道，多个支付公司，这个不好解决。