收集金币的马里奥
演示 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
后续
- 优惠券
- 商品中心
- 订单中心
总结
- 区分变化很重要
- 前期很容易因为支付流程是复杂的，签名是复杂的，错误认为这是变化部分。支付流程梳理清楚后这部分反而是稳定的
- 支付流程、签名是固定的，不变的，而且是内部的
- 与业务端，终端以及支付网关后台的交互是设计重点
- 测试优先（线上也要易测试）
