探討一下常見支付系統的對外接口

做爲一個具有用戶交易能力的網站，豐富它的支付渠道對於獲客和提升日活都有不可估量的積極做用。算起來，我接觸過的支付系統也有幾十個了，在這裏總結一下我所接觸過的支付系統對外接口的設計方案。

1. 支付寶

做爲國內最大的支付平臺，絕大多數網站都會與其對接，當之無愧是最多見的支付渠道，而不少其它小的支付渠道也是參考支付寶來設計其對外接口的，很具備表明性，其支付流程以下圖：

上圖的流程中其實還隱藏了不少安全校驗的細節，例如與支付寶接口之間的數據加密規則和驗籤規則，異步回調接口的調用者IP白名單，支付寶訂單信息反查及與A站點訂單信息比對校驗（金額、用戶、狀態等）。另外，還有一些流程是可選的，例如，同步回調這一步，若是將訂單確認的流程加在裏面，則有可能影響用戶體驗，因此在這裏訂單的確認流程能夠本身觸發另開線程去跑，或者去除同步回調的確認訂單功能，徹底依賴異步回調來完成訂單。而異步回調裏的訂單反查也不是必須的，若是你認爲白名單和驗籤規則足夠可信的話，不反查也能夠。

2. 微信支付

成交量也很是可觀的支付渠道，其支付流程也具備必定的表明性，流程以下圖：

相比支付寶，其在初始的下單階段有一些差別，主要表如今，下單動做是由A站點的服務端調用的，而支付寶則是由前端發起調用的。相比起來，支付寶的下單動做因爲是在前端調用的，所以，A站點須要將本身的訂單信息返回到客戶端，而後又客戶端發起調用支付寶的下單接口，這樣一來，若是安全、加密等作的不到位，很容易被惡意用戶篡改信息。而微信的下單接口是服務端調用的，A站服務器只將得到的微信預付訂單號返回給客戶端，用來發起調用微信客戶端支付接口，這樣一來，訂單信息詳情沒有暴露在外，相對更安全一些。

3. 深度合做的積分抵扣模式

有時，一些站點或遊戲會與某些第三方深度合做，將第三方的積分接入其中，以必定的比例來抵扣和兌換其中的商品或道具。所謂深度合做，則是第三方會直接給出受權互信接口，容許A站點直接調用扣減某用戶的積分，用戶只需將其第三方站點的帳號與A站點的帳號綁定便可。這種模式，大多數狀況下只有接口級的調用，沒有前端收銀臺界面，流程圖以下：

從上圖能夠看出，這種方式在流程上相對比較簡單，只要A站點與第三方作好接口加密、簽名等安全措施，商定好結算規則，對接起來相對比較容易。另外，這種對接形式須要第三方支持按照A站點的訂單號來反查訂單信息，方便對帳結算和訂單異常的自動化處理。

4. 總結：支付系統對外接口的必備要素

4.1 接口部分

• 下單接口

• 同步回調通知：通知的信息須要包含雙方訂單號，訂單金額，用戶身份信息，訂單狀態等

• 異步回調通知：同「同步回調通知」

• 交易訂單查詢接口：支持使用雙方任一方的訂單號來查詢訂單信息，由於有時A站點不必定能拿到支付渠道產生的訂單號，此時則只能拿A站點本身的訂單號來查詢支付渠道的支付信息。之因此須要查詢，一個是在回調時確保訂單信息的有效性和準確性，另外一個目的則是防止異常狀況下，A站點沒有收到支付渠道的回調信息，而用戶的確在支付渠道成功支付，爲確保A站點用戶支付都能及時到帳發貨，須要增長異步的訂單查詢跑批。

4.2 安所有分

• 信息加密：https、AES、非對稱加密（公鑰私鑰）等；

• 簽名規則：對傳輸的信息總體應用簽名規則（sha256等），生成簽名字符串，用於防止傳輸信息被篡改；

• IP白名單：對於服務器間調用的接口，能夠將對方服務器IP加入白名單，防止非法IP調用；

• 訂單信息反查：A站點主動向支付渠道查詢訂單信息，保證訂單信息的有效性和準確性。

以上只是我對以前接觸過的支付系統對外接口的總結，可能有一些說的不對或有待完善的地方，若是你有任何問題或建議，能夠掃描下方二維碼或者微信搜索[phpjiagoushier]，關注個人微信公衆號[PHP架構]，參與互動交流。