常见分布式应用系统设计图解（十五）：支付系统

支付（Payment）系统可以很复杂，比如可以和银行打交道，和信用卡系统打交道。如果我们考虑用户在一家电商买东西，在结账的时候，借助电商支持的支付系统（Payment Service Provider）来完成支付行为。

支付系统需要结合商家（包含卖家和买家）一起来看。最典型的一种需求是，卖家在电商网站挂了东西卖，买家挑选了货物，结账并支付，电商依赖于支付系统来完成支付，并通知买家支付成功。

• 图中用两条虚线分隔出了 3 列，最左边是用户，中间是电商系统（比如 Amazon），右边是 Payment Service Provider（PSP，比如 PayPal）。支付操作需要保证幂等性，从而在重试的过程中保证不会被重复扣钱。
• 有的电商自己会存储用户具体的支付信息，比如信用卡信息和银行账号信息，但是这样的数据管理成本由于安全需求的原因非常高，因此也有很多电商省掉这个麻烦，选择让 PSP 来管理。图中就是对于这种情况的示意。
• 图中用户在 checkout page 结账页面，store 向 PSP 发送一个 registration 请求，得到一个 token，这个 token 就可以后续用来查询支付信息。再根据这个 token 生成一个跳转到 PSP 网页的 URL，于是这个 URL 重定向用户的请求到了 PSP 的支付页面。一并带过去的，除了 token，还可能会有一个回调 URL，用以支付成功以后跳转回 store 的成功页。
• 用户填上信用卡信息并提交，PSP 会生成一个待支付的事件放到 Payment Queue 中。
• Payment Worker 会异步地和信用卡公司通信并完成支付行为，更新账本 Ledger 系统，并放入一个通知事件到 Notification Queue 中。对于反复投递不成功的消息，放入 Dead Letter Queue 作备案处理。
• 这个 queue 会有不同的消费者，其中一个是 Webhook Worker，将成功的消息告知 store（或者是通知支付页处理完成的消息，用户就被重定向到 store 的订单支付完成页面）。这之后如果 store 需要知道具体的支付信息，可以使用之前的 token，发起主动查询。
• 定期还可能会有对账（Reconciliation）和生成 statement 等异步任务，图中没有列出。例如，store 往往需要定期执行对账任务，调用 PSP API 来检查支付和账户数据的一致性。

这是《常见分布式系统设计图解》系列文章中的一篇，如果你感兴趣，请参阅汇总（目录）寻找你其它感兴趣的内容。

文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》