聊聊電商平臺的支付交易系統

1、關於定位

今天和你們分享支付交易相關的系統，這是一個和資金打交道的系統，承載着電商平臺的購物車、下單、支付渠道網關、訂單管理、虛擬資金帳戶、營銷優惠等重要業務，是電商平臺不可或缺的系統。在不一樣的業務發展階段，支付交易系統須要的架構和投入的人力也不大同樣。

2、架構演進

1. 初期：單核階段

在平臺發展初期，業務相對比較簡單，業務量也很小，一個系統就囊括了全部功能，極可能連部署都和其餘功能混布。

這個階段的特色是：

• 系統簡單開發快，
• 可擴展性差，沒法快速知足新商品支付的接入
• 各個節點耦合度高，節點間多爲事務性依賴，致使交易鏈路很長
• 代碼愈來愈多，各個節點並行開發愈來愈困難

爲了解決這些問題，決定將各個節點進行服務化，採用分佈式系統架構，把支付交易的各個節點服務化到後端，用來支撐多個前端應用。

2. 中期：服務化

除了服務化，這個架構裏還加上了交易訂單，把訂單拆分爲商品訂單和交易訂單，主要目的是讓支付和商品解藕，讓網關更加獨立，同時解決因爲訂單信息變動帶來的觸發第三方渠道風控策略，致使沒法支付的狀況 ( 好比點擊過第三方支付，而後發生了訂單改價，那麼同一個訂單號在第三方就不容許再次支付了 )

這個階段的特色是：

• 緩解了1.0的問題
• 分佈式系統，保障分佈式事務的數據一致性是難點，這裏不作深刻介紹，可參考

系統冪等以及經常使用實現方式

分佈式事務演進

• 跟着業務走

3. 後期：面向業務規則

3.0的支付交易系統應該是面向業務規則的系統，可以知足平臺大多數的支付場景須要，業務規則可抽象，經過配置規則就能快速訂閱底層的支付基礎服務。

但這須要等業務發展到必定階段纔可行。

3、支付網關

市面上有不少的渠道網關，那麼渠道網關如何作選擇呢？我歸結爲3個關鍵詞：主流、穩定、手續費

 

首先是主流,就是知足大多數用戶的支付需求，市面上的網關巨頭如支付寶、微信基本就是標配

而後是穩定,通常主流的支付渠道穩定性都沒有問題，但爲了更好的容錯容災，多接入一些渠道進行備份也是好的選擇

最後是手續費,當交易量達到必定量級，你會發現每筆交易支付的手續費也是一筆不菲的支出，下降手續費就成了須要去解決的問題

如何下降手續費呢？

1. 經過商務手段進行談判，同時接入一些中小渠道，通常這些渠道爲了發展會有較高的談判空間；
2. 在界面上能夠下降高手續費渠道的展現位置，固然不能影響交易額
3. 對於有交易額階梯價的渠道，經過渠道引擎自動調整交易渠道，對用戶無感知，但這須要交易有必定渠道特色才能達到效果

4、財務清算

財務清算包括對帳併產出會計報表，它的設計有必定會計知識門檻,在系統初期，通常團隊都會由於快速支撐業務發展，而遺漏了這方面的設計。

財務清算系統和支付交易系統在交易數據上是緊耦合的，爲了讓兩個系統有比較清晰的系統邊界，儘量的解藕，咱們的思路能夠是這樣的

1. 創建會計科目體系，結合自身平臺的特性，在這些主科目下創建分科目

    資產 = 負債+待清算+(收入-費用)

2. 支付交易系統產生交易流水

3. 財務清算系統把交易流水錄入到科目體系

4. 財務清算系統和第三方對帳單對帳