支付渠道参数如何设计成路由化配置

转载自  支付渠道参数如何设计成路由化配置

今天我们来探讨在搭建支付系统时一个比较关键的问题：渠道参数路由化配置如何设计？

在开发支付系统的时候，我们经常会涉及到对接多个支付渠道，除常见的支付宝、微信外可能还会根据不同的业务场景对接很多其他的支付渠道，如apple pay、银联甚至一些海外支付渠道如Adyen、Stripe等。

此外，根据公司业务类型的扩展，以及业务范围不断向不同国家、区域的延伸，面临法律、税收、区域产业政策等不同因素的影响，同一个支付渠道也会根据业务类型、国家、区域等因素的不同而申请不同的支付商户号以关联不同的法律主体。

这些问题在公司发展的早期，业务比较简单的情况下一般是不会遇见，但是一旦随着公司业务的快速发展这些问题就会逐步显现出来，而大多数创业公司在早期开发支付系统的时候是很少考虑这些问题的，一方面是时间成本问题，另外一方面也是初创公司真正拥有支付系统研发经验的工程师比较稀缺，而前期的考虑不足往往也会造成后期支付系统在支撑业务快速发展的过程中显得举步维艰，维护成本及业务适配复杂度变得十分高昂。

 

那么上述情况会究竟造成什么样的问题呢？

从上图杂乱的关系图中可以看到，不同的业务线拥有不同的业务，不同的业务及业务线在又拥有不同的支付方式以及不同的支付渠道商户号，如果业务涉及海外，还会根据不同的国家在具体支付方式选择上有不同的要求及规则。

而这样的场景也并不是从公司初创开始就这么复杂，而是随着业务发展日积月累产生的，在早期构建支付系统的时候如果不加以考虑，随着业务的快速发展系统就会始终处于一个被动改造的境地，最终代码中充斥着各种个性化逻辑场景，导致维护成本高昂且极容易出错导致线上Bug，并且也会导致支付数据纬度混乱，影响对账、清结算等其他系统逻辑。

那么怎么设计才能让渠道管理更加具有扩展性呢？

 

业务模型的定义

根据上述因素，我们可以进行下抽象，具体来说各业务线对于支付平台来说可以理解为商户（Merchant），在对接支付系统的时候可以为不同的Merchant开通不同的支付商户ID及接口对接参数；同一个业务线也会有不同的业务，而业务可能比较独立也可能会与其其他业务存在交叉关系，为了更好的厘清关系，我们对同一个商户下的不同业务设计成两个维度：应用（App）、业务类型（BusiType）。

另外比较关键的概念就是渠道（Channel）了，可以为对接的不同支付渠道定义Channel编码进行区分，根据渠道合作方式的不同，有些海外渠道也会存在子渠道（SubChannel）的情况,这种情况一般是主渠道提供技术接口，而具体不同的子渠道直接对Merchant进行资金清结算。

不同的渠道也会根据收单场景及不同的交易类型（TradeType），如支付、退款、转账、红包等，提供不同的支付方式（PayMethod）,这些支付方式在国内的情况主要是支付公司根据市场情况的不同而定义的特定支付产品，例如“支付宝App支付”针对移动端App应用的支付场景，“微信小程序支付”针对微信小程序应用的支付场景。

而海外支付渠道则可能会根据不同国家的业务发展情况而定，例如Adyen在香港具备本地收单资质，那么如果希望通过Adyen在香港开展业务，除了可以通过Visa/Master收单外，也可以对接Adyen的ideal（本地化收单）方式。

这里的情况不同渠道表现方式会有所不同，但从我们搭建支付系统的角度看，都可以统一定义为支付方式（PayMethod）。

采用上述几个概念设计渠道参数配置规则，基本上就能确保支付系统在后续的发展过程中向上能够优雅地适配业务发展的不同要求，向下可以从容扩展不同的渠道了。并且通过这些定义可以有效地区分支付数据的维度，使得后续的对账清结算处理更加便捷。

考虑到海外情况及渠道接口版本升级问题，可以再加上国家（Country）、接口版本（Version）两个要素。

 

配置模型设计

通过上述业务模型的定义，在系统实现时我们需要设计一套配置表，并在渠道对接编码时按照配置逻辑进行接口参数路由动作，从而让系统具备渠道管理的配置能力。

基于上述配置模型，我们就可以在业务与渠道参数配置上实现相对灵活的配置与路由了。假设，如果我们在完成微信渠道支付接口的对接并满足了业务A的支付需求，如果业务B也需要采用微信进行支付，并且申请的是独立于业务线A的支付商户信息，那么此时我们只需要完成渠道参数配置表的配置，并且在开通业务线B商户ID及应用ID后进行路由规则设置，系统即可完成支持，而不需要进行硬编码的改造。

 

安全风险及其他

采用配置化方案设计，可以让支付系统更好地适配后期业务发展带来的复杂性，但是我们也需要考虑到操作风险，根据以往经验，不受控的便捷往往会带来危险，试想下如果因为配置错误，原本应该收到B账户的钱，被收到了A账户，而这两个账户主体完全不同，这种情况不仅会导致资金问题、也会影响支付系统后面的逻辑，例如退款问题等。所以，我们在采用这样方案的同时，也需要制定严格的操作规程，在配置系统上设计更为严格的审查流程。

此外，渠道参数属于敏感信息，在配置上也需要采取必要数据安全措施（如加密），另外，因为这类参数是属于低频变更、高频使用的配置数据，为了系统效率我们往往也采用缓存机制，做好缓存与持久层数据的一致性及缓存数据的安全性也至关重要。

 

后记

在支付系统设计的早期，如果我们能适度的对配置化模型加以考虑，虽然，会在一定程度上增加研发成本，但随着业务发展，这种成本相较于后期对业务适配改造的成本来说，则是可以忽略的。因为，支付系统对于任何互联网公司来说，都是很关键的业务系统，并且一旦上线就处在了高速运转的模式之下，开着车更换轮子的成本往往比造一辆车的成本更高。

并且，从一些公司的实际情况来看，很多都是在处于无法维护或维护成本异常高昂的情况下，重新花费了很大的精力及成本重建了支付系统。做好支付系统涉及很多细节，这里只是介绍了其中一个比较关键的细节内容，希望能对大家有用～