很多产品在进行支付的时候，都有第三方支付的选项，这些年第三方支付的方式也在不断增加。这就要求产品在设计支付渠道时，要考虑到拓展性。本文作者对此进行了分析，希望对你有帮助。
产品：我们近期需要增加一个支付渠道，评估一下工期吧？
技术：这个很麻烦，要改订单，改流水，改前端支付接入……估计要两个月吧。
产品：要这么久吗？Boss 说半个月内要上线。
技术：当初设计的时候没有考虑接多个支付渠道，现在哪能想加就加，这可是涉及资金的环节，怎么可能这么快？
产品：……
涉及到线上交易环节的系统都会接入第三方支付。当前的第三方支付渠道越来越多，从一开始的支付宝支付、到微信支付、再到云闪付……现在还有各家银行的支付渠道。比如我们看美团，就支持了微信、支付宝、云闪付、美团支付和华为支付。
如此多的支付渠道，如果一开始的产品设计对支付这块没有考虑好，那么出现上面的对话很正常，而且确实不能说是技术的锅。
当然，做过多支付渠道接入的技术可能在一开始设计技术方案的时候就会考虑，但是大部分技术可能只是实现了支付的功能而已，并没有考虑扩展性。然后，要扩展支付渠道的时候就会很被动。
我们来看看在没有支付网关的情况下，支付这个过程是怎么样的。
上面这幅流程图是一个简化版本的正向支付流程图，发起支付的时候，用户端需要选择支付渠道，然后根据不同的支付渠道发起对应的支付。支付成功后，再处理订单的支付状态。
每一个支付渠道都有一套独立的支付流程，也就意味着每接入一个支付渠道，这些部分都需要单独开发，工作量和当初一开始做第一个支付的差不多，工期长就难免了。
这还是简化的正向的支付流程，如果考虑订单退款、资金流水管理，那么工作量会更多。
怎么化解这种情况？实际上还是需要产品从业务层面抽象支付过程。
我们梳理一下上面各个支付渠道的过程，发现其实发起支付、支付成功判断和通知订单支付成功这三个环节其实是类似的，因此可以将上面的流程图简化为下面的样子。
中间框起来的那部分就是支付网关要做的事情。这个时候也许会有人质疑，实际上每个支付渠道还是要单独处理一遍，并没有简化什么。从面上看确实是，所以这里就涉及到领域驱动设计的思想了。
回到我们的支付环节，我们可以拆分成三个模块，前台模块、后台的订单模块和支付模块。
这三个模块如果能够在前期通过一种形式进行分离和交互约定，那么当三个模块的某个模块发生变动时，其他两个模块的变动可以降低到极限，从而可以减轻变动带来的系统开发工作量。
我们先来看看如何分离，分离的目的是尽量保证数据的单向流动，比如支付环节的数据流向图如下。
从这幅图我们可以看到，实际上前台模块到支付模块的数据流是可以单向流动的，那么我们约定好不同模块的数据交互规则就可以减少某个模块变动带来的影响了。
下面是三个模块约定的信息：
由上面的数据流可以看到，实际上三个模块的边界和数据交互是很清晰的。
因此，我们在设计的时候，把三个模块之前的交互数据约定好，那么当支付渠道发生改变的时候，就只需要做少量改动就可以了。
整个工作经过梳理后会简单很多，但这里的前提是产品在设计之初就将支付模块和订单模块分离了，分离后的支付模块就可以扩展为支付网关。
退款的逆向操作也是类似的，步骤如下：
当接入新的支付渠道时，实际上退款过程只需要支付网关处理即可，订单模块不需要做任何改动。
很多产品都会和第三方系统做对接，而第三方支付是最常见的一种形式。
如果产品同一项功能可能和多个不同渠道的第三方对接，那么建议在不同渠道和具体业务功能之间增加一个适配功能，从而当接入新的第三方时，只需要更改适配功能，而不需要对业务功能进行大的改动，例如本篇介绍的支付网关。
这种设计方式，一方面需要产品经理能够提前预判业务发展趋势，另一方面还需要产品经理具备优秀的业务梳理和抽象能力。实际上，业务梳理和抽象能力是很多高级产品经理和初中级产品经理最为明显的区别。
作者：产品海豚湾；公众号：产品海豚湾（ID：pm-dophin-bay）
本文由@产品海豚湾 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。