接一个第三方支付，开发说要2个月？

很多产品在进行支付的时候，都有第三方支付的选项，这些年第三方支付的方式也在不断增加。这就要求产品在设计支付渠道时，要考虑到拓展性。本文作者对此进行了分析，希望对你有帮助。

———— / BEGIN / ————

产品：我们近期需要增加一个支付渠道，评估一下工期吧？ 技术：这个很麻烦，要改订单，改流水，改前端支付接入……估计要两个月吧。 产品：要这么久吗？Boss 说半个月内要上线。 技术：当初设计的时候没有考虑接多个支付渠道，现在哪能想加就加，这可是涉及资金的环节，怎么可能这么快？ 产品：……

涉及到线上交易环节的系统都会接入第三方支付。

当前的第三方支付渠道越来越多，从一开始的支付宝支付、到微信支付、再到云闪付……现在还有各家银行的支付渠道。比如我们看美团，就支持了微信、支付宝、云闪付、美团支付和华为支付。

如此多的支付渠道，如果一开始的产品设计对支付这块没有考虑好，那么出现上面的对话很正常，而且确实不能说是技术的锅。

当然，做过多支付渠道接入的技术可能在一开始设计技术方案的时候就会考虑，但是大部分技术可能只是实现了支付的功能而已，并没有考虑扩展性。然后，要扩展支付渠道的时候就会很被动。

支付网关

我们来看看在没有支付网关的情况下，支付这个过程是怎么样的。

上面这幅流程图是一个简化版本的正向支付流程图，发起支付的时候，用户端需要选择支付渠道，然后根据不同的支付渠道发起对应的支付。支付成功后，再处理订单的支付状态。

每一个支付渠道都有一套独立的支付流程，也就意味着每接入一个支付渠道，这些部分都需要单独开发，工作量和当初一开始做第一个支付的差不多，工期长就难免了。

这还是简化的正向的支付流程，如果考虑订单退款、资金流水管理，那么工作量会更多。

怎么化解这种情况？实际上还是需要产品从业务层面抽象支付过程。

我们梳理一下上面各个支付渠道的过程，发现其实发起支付、支付成功判断和通知订单支付成功这三个环节其实是类似的，因此可以将上面的流程图简化为下面的样子。

中间框起来的那部分就是支付网关要做的事情。这个时候也许会有人质疑，实际上每个支付渠道还是要单独处理一遍，并没有简化什么。从面上看确实是，所以这里就涉及到领域驱动设计的思想了。

领域抽象

回到我们的支付环节，我们可以拆分成三个模块，前台模块、后台的订单模块和支付模块。

这三个模块如果能够在前期通过一种形式进行分离和交互约定，那么当三个模块的某个模块发生变动时，其他两个模块的变动可以降低到极限，从而可以减轻变动带来的系统开发工作量。

我们先来看看如何分离，分离的目的是尽量保证数据的单向流动，比如支付环节的数据流向图如下。

从这幅图我们可以看到，实际上前台模块到支付模块的数据流是可以单向流动的，那么我们约定好不同模块的数据交互规则就可以减少某个模块变动带来的影响了。

下面是三个模块约定的信息：

• 前台到订单：提交订单时提供商品信息，包括 SKU 的 id，数量，若考虑优惠的话把优惠信息也一并提交；

• 订单到前台：订单信息，例如订单详情。

• 前台到支付：提供支付渠道（由用户选择）和订单号；支付模块会根据订单号获取实际要支付的金额创建支付流水，此时支付流水处于待支付状态。这里要注意，不能由前台提交支付金额，因为前台数据不是绝对可信的，实际金额要以后台订单模块的为准。

• 支付到第三方：一般接入第三方支付都需要后台向第三方申请支付参数（通常会需要提供商户号、金额、商家订单号、商品信息）。

• 支付到前台：将获取到的第三方支付参数按约定格式组装给到前台，让前台能够按对应渠道的要求将支付参数提交到支付渠道（通常是第三方提供的 SDK）发起支付。

• 第三方支付到支付模块：支付后，第三方支付会推送支付成功的对账信息通知给到后台，后台核对无误后，确认支付成功。支付模块会将之前创建的流水标记为支付成功。

• 支付模块到订单模块：支付模块会告知订单模块哪个订单号支付成功了，然后订单模块标记订单为付款成功。

• 订单模块到前台：将支付成功信息给到前台，前台会告知用户已经支付成功。

由上面的数据流可以看到，实际上三个模块的边界和数据交互是很清晰的。

因此，我们在设计的时候，把三个模块之前的交互数据约定好，那么当支付渠道发生改变的时候，就只需要做少量改动就可以了。

• 在正向支付过程中订单模块是不需要改动的，订单模块和第三方支付并没有直接的关联。

• 增加支付渠道时，前台一方面下单支付时提交对应的支付渠道即可。发起支付时按照第三方渠道的要求，将支付模块的渠道支付参数提交到第三方即可，实际上只是增加了第三方渠道支付的适配工作；

• 支付模块只需要适配新增渠道的申请支付和处理第三方支付成功的对账通知即可。

整个工作经过梳理后会简单很多，但这里的前提是产品在设计之初就将支付模块和订单模块分离了，分离后的支付模块就可以扩展为支付网关。

退款的逆向操作也是类似的，步骤如下：

• 前台用户发起退款申请，这里也可以是后台客服替用户发起退款申请；

• 后台审核通过后，提交退款申请到支付网关（实际上是订单模块到支付网关）；

• 支付网关向第三方提交退款申请。退款成功后，第三方支付会通知支付网关；

• 支付网关核对退款信息无误后，通知订单模块退款操作成功，订单模块会标记订单的退款状态。

当接入新的支付渠道时，实际上退款过程只需要支付网关处理即可，订单模块不需要做任何改动。

总结

很多产品都会和第三方系统做对接，而第三方支付是最常见的一种形式。

如果产品同一项功能可能和多个不同渠道的第三方对接，那么建议在不同渠道和具体业务功能之间增加一个适配功能，从而当接入新的第三方时，只需要更改适配功能，而不需要对业务功能进行大的改动，例如本篇介绍的支付网关。

这种设计方式，一方面需要产品经理能够提前预判业务发展趋势，另一方面还需要产品经理具备优秀的业务梳理和抽象能力。实际上，业务梳理和抽象能力是很多高级产品经理和初中级产品经理最为明显的区别。

本文来自微信公众号：产品海豚湾，作者：产品海豚湾

一群人比一个人走得更远，扫码加入AI共学交流群，资源、方法、工具全都有。