良多产物在停止付出的时候，都有第三方付出的选项，那些年第三方付出的体例也在不竭增加。那就要求产物在设想付出渠道时，要考虑到拓展性。本文做者对此停止了阐发，希望对你有帮忙。
产物：我们近期需要增加一个付出渠道，评估一下工期吧？
手艺：那个很费事，要改订单，改流水，改前端付出接入……估量要两个月吧。
产物：要那么久吗？Boss 说半个月内要上线。
手艺：当初设想的时候没有考虑接多个付出渠道，如今哪能想加就加，那可是涉及资金的环节，怎么可能那么快？
产物：……
一、媒介涉及到线上交易环节的系统城市接入第三方付出。当前的第三方付出渠道越来越多，从一起头的付出宝付出、到微信付出、再到云闪付……如今还有各家银行的付出渠道。好比我们看美团，就撑持了微信、付出宝、云闪付、美团付出和华为付出。
如斯多的付出渠道，若是一起头的产物设想对付出那块没有考虑好，那么呈现上面的对话很一般，并且确实不克不及说是手艺的锅。
当然，做过多付出渠道接入的手艺可能在一起头设想手艺计划的时候就会考虑，但是大部门手艺可能只是实现了付出的功用罢了，并没有考虑扩展性。然后，要扩展付出渠道的时候就会很被动。
二、付出网关我们来看看在没有付出网关的情况下，付出那个过程是怎么样的。
上面那幅流程图是一个简化版本的正向付出流程图，倡议付出的时候，用户端需要选择付出渠道，然后按照差别的付出渠道倡议对应的付出。付出胜利后，再处置订单的付出形态。
每一个付出渠道都有一套独立的付出流程，也就意味着每接入一个付出渠道，那些部门都需要零丁开发，工做量和当初一起头做第一个付出的差不多，工期长就不免了。
那仍是简化的正向的付出流程，若是考虑订单退款、资金流水办理，那么工做量会更多。
怎么化解那种情况？现实上仍是需要产物从营业层面笼统付出过程。
我们梳理一下上面各个付出渠道的过程，发现其实倡议付出、付出胜利判断和通知订单付出胜利那三个环节其实是类似的，因而能够将上面的流程图简化为下面的样子。
中间框起来的那部门就是付出网关要做的工作。那个时候也许会有人量疑，现实上每个付出渠道仍是要零丁处置一遍，并没有简化什么。从面上看确实是，所以那里就涉及到范畴驱动设想的思惟了。
三、范畴笼统回到我们的付出环节，我们能够拆分红三个模块，前台模块、后台的订单模块和付出模块。
那三个模块若是可以在前期通过一种形式停止别离和交互约定，那么当三个模块的某个模块发作变更时，其他两个模块的变更能够降低到极限，从而能够减轻变更带来的系统开发工做量。
我们先来看看若何别离，别离的目标是尽量包管数据的单向活动，好比付出环节的数据流向图如下。
从那幅图我们能够看到，现实上前台模块到付出模块的数据流是能够单向活动的，那么我们约定好差别模块的数据交互规则就能够削减某个模块变更带来的影响了。
下面是三个模块约定的信息：
前台到订单：提交订单时供给商品信息，包罗 SKU 的 id，数量，若考虑优惠的话把优惠信息也一并提交；订单到前台：订单信息，例如订单详情。前台到付出：供给付出渠道（由用户选择）和订单号；付出模块会按照订单号获取现实要付出的金额创建付出流水，此时付出流水处于待付出形态。那里要留意，不克不及由前台提交付出金额，因为前台数据不是绝对可信的，现实金额要以后台订单模块的为准。付出到第三方：一般接入第三方付出都需要后台向第三方申请付出参数（凡是会需要供给商户号、金额、商家订单号、商品信息）。付出到前台：将获取到的第三方付出参数按约定格局组拆给到前台，让前台可以按对应渠道的要求将付出参数提交到付出渠道（凡是是第三方供给的 SDK）倡议付出。第三方付出到付出模块：付出后，第三方付出会推送付出胜利的对账信息通知给到后台，后台查对无误后，确认付出胜利。付出模块会将之前创建的流水标识表记标帜为付出胜利。付出模块到订单模块：付出模块会告知订单模块哪个订单号付出胜利了，然后订单模块标识表记标帜订单为付款胜利。订单模块到前台：将付出胜利信息给到前台，前台会告知用户已经付出胜利。由上面的数据流能够看到，现实上三个模块的鸿沟和数据交互是很明晰的。
因而，我们在设想的时候，把三个模块之前的交互数据约定好，那么当付出渠道发作改动的时候，就只需要做少量改动就能够了。
在正向付出过程中订单模块是不需要改动的，订单模块和第三方付出并没有间接的联系关系。增加付出渠道时，前台一方面下单付出时提交对应的付出渠道即可。倡议付出时根据第三方渠道的要求，将付出模块的渠道付出参数提交到第三方即可，现实上只是增加了第三方渠道付出的适配工做；付出模块只需要适配新增渠道的申请付出和处置第三方付出胜利的对账通知即可。整个工做颠末梳理后会简单良多，但那里的前提是产物在设想之初就将付出模块和订单模块别离了，别离后的付出模块就能够扩展为付出网关。
退款的逆向操做也是类似的，步调如下：
前台用户倡议退款申请，那里也能够是后台客服替用户倡议退款申请；后台审核通事后，提交退款申请到付出网关（现实上是订单模块到付出网关）；付出网关向第三方提交退款申请。退款胜利后，第三方付出会通知付出网关；付出网关查对退款信息无误后，通知订单模块退款操做胜利，订单模块会标识表记标帜订单的退款形态。当接入新的付出渠道时，现实上退款过程只需要付出网关处置即可，订单模块不需要做任何改动。
四、总结良多产物城市和第三方系统做对接，而第三方付出是最常见的一种形式。
若是产物统一项功用可能和多个差别渠道的第三方对接，那么建议在差别渠道和详细营业功用之间增加一个适配功用，从而当接入新的第三方时，只需要更改适配功用，而不需要对营业功用停止大的改动，例如本篇介绍的付出网关。
那种设想体例，一方面需要产物司理可以提早预判营业开展趋向，另一方面还需要产物司理具备优良的营业梳理和笼统才能。现实上，营业梳理和笼统才能是良多高级产物司理和初中级产物司理最为明显的区别。
做者：产物海豚湾；公家号：产物海豚湾（ID：pm-dophin-bay）
本文由@产物海豚湾 原创发布于人人都是产物司理，未经答应，制止转载。
题图来自Unsplash，基于CC0协议。
该文概念仅代表做者本人，人人都是产物司理平台仅供给信息存储空间办事。
发表评论