很多产品在支付时都有第三方支付选项，而且近年来第三方支付方式的数量也在不断增加。 这就要求产品在设计支付渠道时要考虑到可扩展性。 本文作者对此进行了分析，希望对您有所帮助。

产品：我们需要在不久的将来添加支付渠道。 我们可以评估施工工期吗？

技术：这个很麻烦。 我们需要改订单、改流程、改前端支付接入……大概需要两个月的时间。

产品：需要这么长时间吗？ 老板说半个月内就会上线。

技术：我们最初设计时并没有考虑连接多种支付渠道。 我们现在如何添加它们？ 这就涉及到资金了。 怎么会这么快？

产品：……

一、简介

涉及在线交易的系统将连接第三方支付。 目前第三方支付渠道越来越多，从一开始的支付宝支付，到微信支付，再到云闪付……现在也有各个银行的支付渠道。 比如我们看美团，它支持微信、支付宝、银联、美团支付、华为支付。

支付渠道有很多。 如果最初的产品设计没有很好地考虑支付，那么上面的对话很正常，不能说是技术的错。

当然，在最初设计技术方案时可以考虑提供多种支付渠道接入的技术，但大多数技术可能只实现了支付功能，并没有考虑可扩展性。 那么，在拓展支付渠道的时候，就会非常被动。

2. 支付网关

让我们看看没有支付网关时的支付流程是什么样的。

上面的流程图是远期付款流程图的简化版本。 用户发起支付时，需要选择支付渠道，然后根据不同的支付渠道发起相应的支付。 支付成功后，会处理订单的支付状态。

每个支付通道都有独立的支付流程，这意味着对于每个连接的支付通道，这些部分都需要单独开发。 工作量与一开始的首付款差不多，工期必然较长。

这仍然是一个简化的远期付款流程。 如果考虑到订单退款和资金流管理，工作量就更大了。

这种情况该如何解决呢？ 事实上，还是需要产品从业务层面抽象出支付流程。

我们梳理了上面各个支付渠道的流程，发现发起支付、判断支付成功、通知订单支付成功这三个步骤其实是类似的，所以上面的流程图可以简化如下。

中间的部分是支付网关的作用。 这时有人可能会质疑，其实每个支付渠道还是需要单独处理，这并没有简化任何事情。 从表面上看确实如此，所以这里涉及到领域驱动设计的思想。

3. 领域抽象

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

如果前期能够将这三个模块以某种形式分离出来并交互，那么当这三个模块之一发生变化时，可以将另外两个模块的变化降到极限，从而减轻变化对系统造成的影响。 开发工作量。

我们先来看看如何分离。 分离的目的是尽量保证数据的单向流动。 例如支付链路的数据流图如下。

从这张图我们可以看出，实际上从前端模块到支付模块的数据流是可以单向流动的，所以我们可以通过约定不同模块的数据交互规则来减少某一模块变化的影响。

以下是三个模块商定的信息：

从上面的数据流可以看出，三个模块之间的界限和数据交互其实是非常清晰的。

因此，我们在设计的时候，就约定了三个模块之间的交互数据，这样当支付渠道发生变化时，我们只需要做一些改动即可。

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

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

前端用户发起退款申请，这里后端客服也可以为用户发起退款申请； 后端审核通过后，向支付网关提交退款申请（实际上是下单模块到支付网关）； 支付网关向第三方基金申请提交退款。 退款成功后，第三方支付会通知支付网关； 支付网关验证退款信息正确后，通知订单模块退款操作成功，订单模块标记订单的退款状态。

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

4. 总结

很多产品都会与第三方系统进行接口，第三方支付是最常见的形式。

如果产品的同一功能可能从不同渠道接入多个第三方，建议增加不同渠道和具体业务功能之间的适配功能，这样当接入新的第三方时，只需适配功能即可被改变。 业务功能不需要做大的改动，比如本文介绍的支付网关。

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