一、關於定位
、下單、支付渠道閘道器、訂單管理、虛擬資金賬戶、營銷優惠等重要業務，是電商平台不可或缺的系統。在不同的業務發展階段，支付交易系統需要的架構和投入的人力也不大一樣。
二、架構演進
1. 初期：單核階段
在平台發展初期，業務相對比較簡單，業務量也很小，乙個系統就囊括了所有功能，很可能連部署都和其他功能混布。
這個階段的特點是：
為了解決這些問題，決定將各個節點進行服務化，採用分布式系統架構，把支付交易的各個節點服務化到後端，用來支撐多個前端應用。
2. 中期：服務化
除了服務化，這個架構裡還加上了交易訂單，把訂單拆分為商品訂單和交易訂單，主要目的是讓支付和商品解藕，讓閘道器更加獨立，同時解決由於訂單資訊變更帶來的觸發第三方渠道風控策略，導致無法支付的情況 ( 比如點選過第三方支付，然後發生了訂單改價，那麼同乙個訂單號在第三方就不允許再次支付了 )
這個階段的特點是：
系統冪等以及常用實現方式
分布式事務演進
3. 後期：面向業務規則
3.0的支付交易系統應該是面向業務規則的系統，能夠滿足平台大多數的支付場景需要，業務規則可抽象，通過配置規則就能快速訂閱底層的支付基礎服務。
但這需要等業務發展到一定階段才可行。
三、支付閘道器
首先是主流然後是穩定,一般主流的支付渠道穩定性都沒有問題，但為了更好的容錯容災，多接入一些渠道進行備份也是好的選擇
最後是手續費,當交易量達到一定量級，你會發現每筆交易支付的手續費也是一筆不菲的支出，降低手續費就成了需要去解決的問題
如何降低手續費呢？
通過商務手段進行談判，同時接入一些中小渠道，一般這些渠道為了發展會有較高的談判空間；
在介面上可以降低高手續費渠道的展示位置，當然不能影響交易額
對於有交易額階梯價的渠道，通過渠道引擎自動調整交易渠道，對使用者無感知，但這需要交易有一定渠道特點才能達到效果
四、財務清算
財務清算包括對賬並產出會計報表，它的設計有一定會計知識門檻,在系統初期，一般團隊都會因為快速支撐業務發展，而遺漏了這方面的設計。
財務清算系統和支付交易系統在交易資料上是緊耦合的，為了讓兩個系統有比較清晰的系統邊界，盡可能的解藕，我們的思路可以是這樣的
建立會計科目體系，結合自身平台的特性，在這些主科目下建立分科目
資產 =負債+待清算+(收入-費用)
財務清算系統把交易流水錄入到科目體系
財務清算系統和第三方對賬單對賬
支付交易中遇到浮點數精度的問題
1,案例 支付平台的單位是分,而業務系統的單位是元,所以傳到支付系統時要乘以100 test public void test divide2 執行結果 1010.99994 執行結果不精確 但是預期結果是 1011 2,解決方法 使用bigdecimal test public void test...
電商支付流程的 返回 邏輯
注 標題有點繞口，先來做一番解釋 我們在電商平台進行交易的過程中，待到支付環節的時候，假如使用者這時強制選擇 返回 之後頁面如何該跳轉，以及訂單該如何處理？文 產品範 這個問題 於這段時間負責的電商專案，關於頁面跳轉邏輯日常的和開發進行了一番撕逼，開發堅持認為應該原路返回，堅決站在使用者的角度 允許...
支付交易如何自動靈活的選擇第三方支付通道
簽約路由 輔助簽約路由 支付路由 支付路由優先順序 商戶號，路由id,卡bin，卡型別確定支付路由的支付通道。支付金額所在的區間值來確定支付優先順序的支付通道。篩選出所有做過簽約的支付通道，按照支付路由，支付優先順序的順序降序排列。獲取篩選後的第一條支付通道，即為確認要走的支付通道。注 如果只簽約了...