收集金幣的馬里奧

演示 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

后續

• 優惠券

• 商品中心
• 訂單中心

總結

• 區分變化很重要
  • 前期很容易因為支付流程是復雜的，簽名是復雜的，錯誤認為這是變化部分。支付流程梳理清楚后這部分反而是穩定的
  • 支付流程、簽名是固定的，不變的，而且是內部的
  • 與業務端，終端以及支付網關后臺的交互是設計重點

• 測試優先（線上也要易測試）