這幾年的工作中一直與支付打交到，藉著 skr-shop 這個專案來與大家一起分享探索一下支付系統該怎麼設計、怎麼做。我們先從支付的一些常見流程出發分析，找出這些支付的共性，抽象後再去探討具體的資料庫設計、程式碼結構設計。
相關專案：
支付整體而言的一個流程是：給第三方發起了一筆交易，使用者通過第三方完成支付，第三方告訴我支付成功，我把使用者購買的產品給使用者。
看似簡單的流程，這裡邊不同的支付機構卻有不同的處理。下面以我接觸過的一些支付來總結一下
國內支付
國內的典型支付代表是：支付寶、微信、銀行(以招商銀行為例)，由於國內的支付都支援多種渠道的支付方式，為了描述簡單，我們均以pc上的支付為例進行講解。
支付寶
支付寶的接入是我覺得最簡單的一種支付。對於在PC上的支付能力，支付寶提供了【電腦支付】。當使用者下單後，商戶系統根據支付寶的規則構建好一個url，使用者跳轉到這個url後進入到支付寶的支付頁面，然後完成支付流程。
在支付成功後，支付寶會通過 同步通知、非同步通知 兩種方式告訴商戶系統支付成功，並且兩種通知方式的結果都是可信的，而且非同步通知的訊息延遲也非常短暫。
對於退款流程，支付寶支援全額、部分退款。並且能夠根據商戶的退款單號區分是否是同一筆退款進而避免了重複退款的可能。支付的退款是呼叫後同步返回結果，不會非同步通知。
微信支付
微信並沒有提供真的PC支付能力，但是我們可以利用【掃碼支付】來達成電腦支付的目的。掃碼支付有兩種模式，這裡以模式二為例。
微信呼叫下單介面獲取到這個二維碼連結，然後使用者掃碼後，進入支付流程。完成支付後微信會 非同步通知，但是這裡並沒有 同步通知，因此前端頁面只能通過定時輪訓的方式檢查這筆交易是否支付，直到查詢到成功、或者使用者主動關閉頁面。
退款流程與支付寶最大的不同是，有一個 非同步通知 需要商戶系統進行處理。
第一個不同點：
- 非同步通知的介面需要處理多種不同型別的非同步訊息
招商銀行
隨著線上支付在國內的蓬勃發展，各家銀行也是不斷推出自己的線上支付能力。其中的佼佼者當屬 招商銀行。大家經常用的滴滴上面就有該支付方式，可以體驗一下。
招商支付使用的是銀行卡，因此首次使用者必須進行綁卡。因此這裡可能就多了一個流程，首先得記錄使用者是否綁過卡，然後用於簽名的公鑰會發生變化，需要定期更新。
招商所有平臺的支付體驗都是一致的，會跳轉到招行的H5頁面完成邏輯，支付成功後並不會自動跳回商戶，也就是沒有 同步通知，它的支付結果只會走非同步通知流程，延遲非常短暫。
退款流程與支付寶一樣，也是同步返回退款結果，沒有非同步通知。
第二個不同點：
- 支付前需要檢查使用者是否簽約過，有簽約流程
小結
國內線上支付流程相對都比較完善，接入起來也非常容易。需要注意的一點是：退款後之前支付的單子依然是支付成功狀態，並不會變成退款狀態。因為退款與支付屬於不同的交易。
這一點基本上是國內線上支付的通用做法。
國際支付
國際支付的平臺非常多，包括像支付寶、微信也在擴充套件這一塊市場。我以我接觸的幾家支付做一個簡單的總結。
WorldPay
這是比較出名的一家國際支付公司，它主要做的是銀行卡支付，公司在英國
支付流程上，也是根據規則構建好請求的url後，直接跳轉到 WorldPay 的頁面，通過信用卡完成支付。這裡比較麻煩的處理機制是：支付成功後，他首次給你的非同步/同步訊息通知並不能作為支付成功的依據。真的從銀行確認劃款成功後，才會給出真的支付成功通知。這中間還可能會非同步通知告訴你支付請求被拒絕。最頭痛的是不同狀態的非同步訊息時間間隔都是按照分鐘以上級別的延遲來計算
退款流程上，狀態跟微信一樣，需要通過非同步訊息來確認退款狀態。其次它的不同點在於無法根據商戶退款單號來確認是否已經發起過退款，因此對於它來說只要請求一次退款介面，那它就預設發起了一次退款。
第三、四不同點：
- 支付成功後的通知狀態有多種，涉及到商戶系統業務流程的特殊處理
- 退款不支援商戶退款單號，無法支援防重複退款需要商戶自己處理
Assist
這是俄羅斯的一家支付公司，這也是一家搞死人不償命的公司，看下面介紹
它的支付發起是需要構建一個form表單，向它post支付相關的資料。成功後會跳轉到它的支付頁，使用者完成支付即可。對於 同步通知，它需要使用者手動觸發跳回商戶，與招商的邏輯很像，同步也僅僅是做返回並不會真的告知支付結果。非同步通知 才是真的告知支付狀態。比較噁心的是，支付時必須傳入指定格式的商品資訊，這會在部分退款時用到。
現在來說退款，退款也是與 WorldPay 一樣，不支援商戶的退款單號，因此防重方面也許自己的系統進行設計。並且如果是部分退款，需要傳入指定的退款商品，這就會出現一個非常尷尬的局面：部分退款的金額與任何一個商品金額都對應不上，退款則會失敗。
第五個不同點：
- 部分退款時需要傳入部分退款的商品資訊，並且金額要一致
Doku
接下來再來聊聊印尼的這家支付機構 doku。由於印尼這個國家信用卡的普及程度並不高，它的線上支付提供一種超商支付方式。
什麼是超商支付呢？也就是使用者在網路上完成下單後，會獲取到一個二維碼或者條形碼。使用者拿著這個條形碼到超商（711、全家這種）通過收銀員掃碼，付現金給超商，完成支付流程。
這種方式帶來的問題是，使用者長時間不去支付，導致訂單超時關單後才去付款。對整個業務流程以及使用者體驗帶來很多傷害。
再來說退款，由於存在超商這種支付方式，導致這種支付無法支援線上自動退款，需要人工收集使用者銀行卡資訊，然後完成轉賬操作。非常痛苦不堪。
第六個不同點：
- 線上沒有付款，只有獲取付款碼，退款需要通過人工操作
AmazonPay
亞馬遜出品，與支付寶非常類似。提供的是整合式的錢包流程。
支付時直接構建一個url，然後跳轉到亞馬遜即可完成支付。它還提供一種授權模式，能夠不用跳轉amazon，再商戶端即完成支付。
支付成功後也會同步跳轉，同步通知 的內容可以作為支付是否成功的判斷依據。經過實際檢查 非同步通知 的到達會稍有延遲，大概10s以內。
退款方面也支援商戶退款單號可以依賴此進行防重。但是退款的狀態也是基於非同步來的。
總結
這其中還有一些國際支付，如：PayPal、GooglePay、PayTM 等知名支付機構沒有進行介紹，是因為基本它們的流程也都在上面的模式之中。我們後續的程式碼結構設計、資料庫設計都基於滿足上面的各種支付模型來完成設計。
最後，贈送大家一副腦圖，這是接入一家支付時必須弄清楚的問題清單
下篇預告：《支付資料庫與程式碼結構設計》
這是我們幾個小夥伴利用業餘時間思考的一些業務設計，如果有寫的不對或者不完善的地方，希望大家多多評論，互相學習互相進步～
專案地址: github.com/skr-shop/ma…
skr-shop專案成員簡介
排名不分先後，字典序
| 暱稱 | 簡介 | 個人部落格 |
|---|---|---|
| AStraw | 研究生創業者, 現於小米科技海外商城組從事商城後端研發工作 | ——– |
| Dayu | Payment開源作者，服務端開發者 | dayutalk.cn |
| lwhcv | 曾就職於百度/融360, 現於小米科技海外商城組從事商城後端研發工作 | ——– |
| TIGERB | PHP框架EasyPHP作者，擁有A/B/C輪電商創業公司工作經驗，現於小米科技海外商城組從事商城後端研發工作 | TIGERB.cn |