多个可插拔支付系统的架构理念在一个应用程序中？

Question

我们已经开发了一年的电子商务应用程序，我们开始在不同的国家开展业务。这意味着必须在单个应用程序中实现许多非常不同的支付系统。例如，我们为每个国家/地区提供不同类型的信用卡处理器网关，某些国家/地区的移动支付网关，支付方式，每个国家/地区的直接银行等等......每个系统都以自己的方式设计自己的数据模型，有时是自己的工作流程，我们在不同的国家使用这些支付系统的不同子组。非常需要使这个可插入。但是我们没有这种架构的经验。由于我们在需要时逐一添加，我们目前没有真正的架构，因为我们在数据库中只有一个表，而这个表包含我们支持的所有支付系统的所有字段，这些字段变得非常容易出错和混乱。

您认为为所有这些不同的付款方式创建真正可插拔的系统的最佳解决方案是什么？每种付款方式都有自己的数据模型但完全可插拔？

Answer 1

一种常见的方法是将支付功能捆绑到单独的模块中。模块公开了两种面向业务逻辑的主要方法：

• reserve()在有限时间内保留信用，即调查支付交易是否成功。
• commit()触发之前保留的实际资金流量。

业务逻辑

1. reserve()在执行付费活动之前付款
2. 执行活动（例如投放内容，......）
3. commit()付款

大多数支付系统都应该适合这个方案。

除此之外，还需要一个插件机制，以便根据用户信息发送到正确的支付模块。