[分享摘要]支付中心设计与实践

收集金币的马里奥

演示 DEMO：扫码支付

支付“不难做”：App 支付，一名 iOS 工程师唰唰唰搞定；微信 JS 支付，一名前端工程师唰唰唰搞定。而如果想做一个通用可扩展的支付系统，90% 的工作在后端，做起来也并不是很容易。

背景

• 早期业务A已引入支付宝支付
  • 发起支付逻辑在客户端，支付单号业务关联性强不通用（客户端写死逻辑影响后端重构一坑此处不表）
  • 支付网关回调接口在 API 项目中，API 项目异常会引起支付问题（客户端一脸萌比）
  • 测试支付？先把业务逻辑走一遍

• 业务 B 有单独的网页端扫码支付，跟客户端没什么关系……
• 后来业务C需要引入支付宝
  • 原有逻辑无法重用，依旧是写一套新的，对应业务逻辑依旧耦合
  • 对客户端来说，API 也是两套
  • 后端支付网关回调也是两套
• 产品说要加微信支付……😢
• 后来说要有更多业务、商品需要支付……😢😢😢

一次支付背后发生的故事

支付宝支付简化模型：

最简支付模型.png

• 最简，如果是微信支付需要预下单

• 最简单支付除了必备价格，其它并不重要
• 支付发起在客户端，看似没问题，但是没扩展性
• 客户端发起最大的问题是成单逻辑在客户端，不可控：难以追踪统计，不可变更

Review 需求：

• 工程师角度：扩展？（我只是不想写重复代码，改来改去）
  • 新增业务支付、商品支付，支付中心、客户端及前端不需要动代码
  • 新增支付渠道，业务不需要动代码，支付相关不需要动老代码
  • 支付中心自洽，模块职能清晰，有日志，可追溯分析
  • 易测试

• 产品运营角度：
  • 上新商品支付，快
  • 支持优惠券
  • 灵活，多端支付，自定义价格支付，发个消息支付……
  • 数据完善
  • 有没有更多可能？

• 公司角度：安全

• 注：以上皆为完成后臆测 ；）

一次“复杂的”支付背后发生的故事

支付中心业务时序图.png

划重点

• 定义支付中心（PayCenterServer & 客户端 & 前端）：
  • 封装支付逻辑，与终端&支付网关直接对接，对业务方透明
  • 对外方便对接多个业务方
  • 对内方便扩展终端，扩展支付网关

• 业务方拿到 PayOrderId，其它的支付过程都交给终端，坐等 PayCenterServer 的 bizNotifyUrl 通知（有模仿的重复通知逻辑）
• 支付中心需要理解的外部概念： bizOrderId, bizNotifyUrl, (couponId, goodsId, unionOrderId)
• 内部数据只有两类：PayOrder, GatewayOrder
• 易测试

聊聊一些坑

• 微信开放平台（open）和公众号平台（mp）是不同的 appId，支付字段也略有区别

• 多钟支付类型的字段解析归纳，是局部实现的难点：
  • 每种支付渠道都不同，同种支付渠道扫码、H5、App 也不完全相同
  • 签名阶段、终端展示、验签阶段
  • DEMO：各终端需要的不同字段
    • 微信为例：JS，扫码，APP
• 签名、验签逻辑理解
  • 银联证书的坑
• TRADE_FINISHED，迟来三个月的 bug

后续

• 优惠券

• 商品中心
• 订单中心

总结

• 区分变化很重要
  • 前期很容易因为支付流程是复杂的，签名是复杂的，错误认为这是变化部分。支付流程梳理清楚后这部分反而是稳定的
  • 支付流程、签名是固定的，不变的，而且是内部的
  • 与业务端，终端以及支付网关后台的交互是设计重点

• 测试优先（线上也要易测试）