說到支付網關，首先看一下網關的定義，網關的作用是實現網絡之間的通訊鏈接，包含兩個基本功能：網間連接和協議轉換。同理，商戶業務系統中的支付板塊實現的就是商戶業務系統與銀行支付系統之間的鏈接，所起到的作用是類似的，可以被看作爲一個網關。因此，我們今天要講的支付網關設計，其實就是商戶業務系統的支付板塊設計。
1.支付網關的由來
在電子支付還沒有普及的時候，商戶支持一家銀行是通過對接這家銀行提供的一個系統接口來完成的。然後隨着支付行業的不斷髮展，商戶已經不滿足於支付環節只支持一個銀行或者兩個銀行了。此時商戶的支付系統需要同時對接多個銀行，並處理好由此導致的很多衍生問題，例如對賬、清算等。而且開發一套這樣的系統所需的人力成本和時間成本也是商戶所不願意接受的。
此時，第三方支付機構誕生了，他們來開發運營一套系統，代替商戶實現同時對接多個銀行系統的功能，然後通過統一的接口提供給商戶使用。所以這一個階段第三方支付機構的系統就是支付網關。它所具備的基礎功能除了實現商戶業務系統與銀行系統之間的鏈接，還包括很多其它的支付業務相關基礎功能，包括：訂單管理、渠道管理、風控管理、路由配置、帳務管理、清算管理、商戶管理和用戶管理等。
隨着線上支付的進一步發展，第三方支付機構越來越多，這時候商戶需要解決的問題已經不再是如何接入多家銀行，而是如何接入多家支付機構。此時商戶對支付系統的需求也發生了變化，網關的位置也進一步前移，對商戶的支付系統提出了更高的要求。現在也有一個角色願意爲商戶來實現類似功能，那就是類似Ping++ 這樣的聚合支付服務提供商。
從商戶的角度講，此時的支付網關和傳統支付網關區別在於，關注點會更少，商戶只需要關注訂單、渠道、風控、賬務管理和路由配置即可。爲了更清楚的解釋說明，我用一趟出境自由行之旅來演示一筆訂單在上述各個模塊之間的流轉過程。通常一筆訂單的處理涉及到四個環節，有創建訂單、報文簽字、支付路由、結果確認。爲了更好的配套，我們還加入了商戶入網。
2.護照-渠道入網申請
渠道入網申請是訂單和渠道管理的首要環節，就好比出境遊首先要有護照。當然並不是說有了護照就可以去任意國家和地區。不同的地區需要不同的護照類型（護照，港澳通行證等）。同樣，使用不同的支付渠道，也需要分別進行入網申請。這裏，尤其需要了解的一點是，支付渠道不等於支付產品。無論支付寶或者微信支付，在不同的前端場景下，比如 App 支付、網頁支付，都有相應的支付產品。所以，並不是說商戶要用微信支付就只需要接入微信支付的一個接口。微信的開放平臺和微信的公衆平臺就需要申請兩個獨立的支付權限，經常有客戶誤把開放平臺的 ID 配到公衆平臺，導致報錯。
3.簽證 - 創建支付訂單
有了護照以後，我們還需要辦理簽證才能出國。此時是需要提供一些必要信息的，例如往返機票信息，目的地酒店信息等。這也與創建支付訂單同理，我們需要提供一筆訂單所需的必要要素。在這個環節，我們需要注意一下幾點：
訂單號
如果自己做支付系統，訂單號是第一個要考慮到的問題。當我們同時做多個支付產品對接的時候，首先需要注意訂單號的格式，不同支付產品渠道對訂單的格式要求不一樣，特別是銀行端的格式更特殊一些。其次是訂單號的唯一性。在實際操作的時候，訂單號的唯一性不僅和技術實現有關，還和業務流程有關，例如同一訂單是否支持多次支付等。這裏我們建議區分業務訂單和支付訂單兩個維度。通過業務訂單和支付訂單的一對多映射來解決唯一性問題。
訂單有效期
訂單有效期可以分爲兩個部分：支付有效期和退款有效期。
支付有效期是可以商戶自定義的，需要注意的是不同渠道的參數使用方法不一樣，有的是相對時間，有的是絕對時間。
而退款有效期是由渠道規定的，不同機構的退款有效期不一樣。這樣我們在業務設計的時候需要取一個最小值。對於超出渠道退款有效期的訂單而業務上又要允許退款，那麼爲了保證訂單信息的正確性，必要的時候必須使用專門的邏輯來處理。
4.接口適配
支付寶手機支付和微信支付/銀聯移動支付的接口區別可以用簽證類型很好的類比。
支付寶手機支付發起是由商戶在後臺將所有東西按照渠道的要求進行處理、準備，然後直接前端通過控件調起支付寶的App發起支付。這非常像我們的落地籤，自己準備好必要材料，飛機落地以後對方海關才進行查驗。
而微信支付和銀聯移動支付等渠道則必須先進行後臺請求，請求通過後，再由前端發起支付動作。這就和標準的簽證非常類似了,資料不符合要求前，是拿不到簽證的，也就無法進行後續操作。這就是不同支付渠道在業務邏輯上有差異的地方，不同渠道的訂單落地順序、落地內容，以及後續的狀態更新等在支付網關設計時都需要相應考慮。
5.出境查驗 - 報文簽名
出境查驗相當於報文簽名。出境查驗的時候，我們需要檢查護照和簽證的合法性。簽名的作用類似，一是防篡改，二是防抵賴。這個環節，需要弄清楚兩個概念：對稱加密AES和非對稱加密RSA。可以區分公私鑰就基本上沒有問題了。
6.風控管理
出行要注意安全，同理，支付系統也要考慮到風控管理。通常我們把風控管理分爲兩個層面，一個是賬戶資金風險控制，另外一個是業務風險控制。
賬戶資金風險控制這環是由支付機構來負責的，因爲如果支付機構的支付安全層面出現問題，將導致用戶信息泄露、資金損失以及非法交易等一系列問題。所以這些機構都花了足夠的精力去做賬戶風險控制，這樣的後果就是，商戶首先是無法接觸到消費者的個人支付敏感要素的。當然，我們就可以投入更多的精力在業務風險的領域。
業務領域的風險控制更多需要考慮業務漏洞導致的風險。互聯網產品常見業務風險包括惡意刷單、套現、薅羊毛。我們防止這幾類風險的常見方式是通過對一些關鍵要素的採集，比如交易帳戶、支付帳戶、交易頻次、交易金額、交易時間、交易地點等，然後基於相應的風控規則進行判斷，最後根據判斷結果來做相應處理。
7.入境查驗 - 結果通知，驗籤，狀態更新
這是支付最後的環節。很多商戶經常困惑是通過異步通知，還是通過主動查詢來確定最終支付結果？這兩個方案我們認爲是並存的，一個是保證效率，一個是保證可用性。我們建議客戶根據自己的業務特點對兩個機制進行有效的配合使用。
同時，我們需要注意的是並不是所有的支付機構都具備異步通知邏輯；也並不是所有的退款都有異步通知，比如微信退款。所以，支付網關要在這個環節來進行同一化處理，確保後端業務系統對接的規則一致性。
8.旅遊賬單 -對賬
最後講一下對賬，對賬管理一般分爲渠道對賬和內部對賬。渠道對賬要保證清算資金、支付訂單狀態的一致性，內部對帳必須保證交易單、支付單、財務明細的一致性。
如何對賬
通常來說，對賬主要包含以下幾步：獲取對帳單，對賬單數據格式化，交易金額和訂單狀態一致性覈查，以及差錯處理。
差錯有兩種常規類型：長款和短款。站在商戶維度來說，長款就是商戶多收到錢。一般來說，訂單狀態不正確和重複支付都會導致長款。短款就是商戶少收到錢，這種情況一般概率較低，大多出現在第三方機構與銀行系統之間的業務對接環節。
訂單的差錯處理，我們強烈建議人工介入，不要自動處理。因爲這個涉及到資金的進出，必須要謹慎處理。
9.支付路由
經常會有商戶問，我們需不需要做支付路由。實際上，在目前支付網關需要對接的是不同支付產品，當該支付產品的入口是唯一的時候，是無法進行支付路由設計的，最直接的例子就是微信和支付寶。但現在不少銀行都成了微信和支付寶的代理商，支持他們的線下或者線上支付產品。在這個前提下，是可以做一定的支付路由處理的。通常來說，支付路由主要是基於：成本，穩定性和流量均衡這幾點來考慮進行設計的。而且，支付路由不單單是一個支付請求的路由設計，對於後續支付結果的處理，資金的對賬等都需要仔細分析處理。
最後總結一下，我們通過一個訂單的處理過程，基本介紹了一個支付網關涉及到幾個板塊，包括：財務管理、業務管理、路由管理、渠道管理和風控管理。但僅有這些還是不夠的，作爲支付網關來講，我們還要做接入管理，進行流量控制和准入控制。需要做基礎平臺支撐，進行系統狀態監控，提供內部運維管理。只有這樣，纔可以算是一個相對完備的支付路由，如下圖所示。
作者 | Ping++ 趙宇
來源 | Ping++ 支付設計大會現場分享