第三方支付，微信支付及支付寶的一些入門了解

B2C電商的支付，一般由于支付金額比較小，支付比較頻繁，是以一般采用第三方支付，常用的第三方支付有：支付寶、微信、易寶支付等。他們的原理都差不多。都是在點選支付時，直接調用第三方支付接口，傳入appid、appsecret、訂單編号、訂單金額、回調url，直接跳轉到第三方支付頁面，接下來的支付過程，我們都不需要管，支付成功以後，第三方支付平台會直接回調我們的url。給我們傳回：狀态碼、訂單編号、支付流水号三個參數。我們首先根據訂單編号，找到我們的訂單，把支付流水号和狀态碼更新到我們的訂單裡邊。回調url，一般有兩種，一種用同步get方法回調，一種用異步的類似ajax方法回調，同步方法回調，一般是成功以後才會回調，并且隻回調一次，回調成功以後我們可以直接跳轉到我們的支付成功頁面、異步方法回調，一般要求我們傳回一個success字元串，第三方平台如果沒有接受到success，就會認為沒有調用成功，他會重複多次調用。比如支付寶會在25小時之内，調用8次；一般情況下第三方支付都采用第二種方式，因為比較安全，但支付寶是同時采用了兩種。

我之前接觸過一個B2B的電商，他們由于交易金額比較大，第三方支付無法實作，是以是直接和銀行對接。大體上是，首先平台和銀行簽訂合同，銀行為平台開設一個總賬号，當企業在平台注冊以後，平台會為企業調用銀行接口，建立一個子賬号，這個子張号是挂在總賬号下邊的，也是一個在銀行實際存在的賬号，但是，隻能通過外部銀行卡給裡邊轉賬，而不能給外部銀行卡轉出。可以在子行号直接互相轉賬。

微信掃描支付

1、商戶系統根據使用者選擇的商品生成訂單（此步驟不分析）

2、使用者确認支付後根據微信【統一下單API】，向微信支付系統送出請求（我們通過httpclient方式請求的）

分析：商戶确認支付即點選“結算”按鈕跳轉到收銀台，然後在點選微信支付時，會調用商戶系統背景，背景做處理準備微信需要的參數，然後通過httpclient調用微信的【統一下單API：https://api.mch.weixin.qq.com/pay/unifiedorder】，其中需要準備的主要參數：

appid（公衆号ID），String（32），微信支付配置設定的公衆号ID

商戶号（mch_id），String（32），微信支付配置設定的商戶号

随機字元串（nonce_str），String（32），随機字元串，主要是為了保證簽名不可預測

簽名（sign），String（32），通過簽名算法得到的簽名值，簽名算法大緻為：需要參與的字段包含公衆号、商戶号、随機字元串、一些其他字段，最重要是key（在微信支付系統中配置的密鑰），然後這些字段格式為：key1=value1&key2=value2…，然後把這個字元串通過MD5加密并把加密結果轉成大寫。

商戶訂單号（out_trade_no），String（32），商戶系統内部訂單号，我們系統用的是交易流水号（訂單号-商戶号-時間戳）

标價金額（total_fee），int，訂單總金額，機關為分，不能帶小數點

通知位址（notify_url），String（256），異步接收微信支付結果通知的回調位址，必須為外網能通路的URL，不能帶參數

交易類型（trade_type），String（16），JSAPI–公衆号支付、NATIVE–原生掃碼支付、APP–app支付，我們用的是NATIVE

3、微信支付系統收到請求後，先生成預支付訂單，然後給商戶系統傳回二維碼連接配接

4、商戶系統拿到傳回值字元串，轉換成對象，然後取出二維碼連接配接生成二維碼

5、使用者通過微信“掃一掃”功能掃描二維碼，微信用戶端将掃碼内容發送到微信支付系統

6、微信支付系統接收到支付請求，驗證連結有效性後發起支付，請求客戶确認，然後我們的微 信端就會彈出需要确認支付的頁面

7、使用者輸入密碼，确認支付并送出授權

8、微信支付系統根據使用者授權完成交易

9、微信支付系統支付成功後向微信用戶端傳回交易結果，并将交易結果通過短信、微信提示使用者

10、微信支付系統通過發送異步消息通知商戶系統背景支付結果，商戶系統需回複接收情況，通 知微信支付系統不再發送該單的通知

接收到微信的支付完成回調請求，微信支付系統會傳過來一個字元串，格式是xlm的我們将其轉換成map格式，然後驗證一些主要參數，return_code和result_code均 為success；公衆号，商戶id不為空；對簽名進行驗證，防止資料洩漏，驗證方法是将傳回集解析出來，然後重新按照簽名規則生成簽名，将兩個新舊簽名比較，如果相同則驗證通過；以上驗證全部通過則認為威信支付系統支付成功，接下來處理商戶系統。

商戶系統也需要驗證一些支付異常情況，訂單已取消的支付成功了；訂單已經支付了，重複支付；訂單金額不一緻，支付金額與訂單金額不一緻；以上均為異常支付，需要退款。如果無異常支付，則更新本地資料。另外商戶系統在進行上述驗證及更新操作時，需将此段代碼加鎖，因為微信支付系統在與商戶系統互動時，如果微信收到的使用者應答不是成功或逾時，則認為微信通知失敗，則微信會重新發起通知，通知頻率為：通知頻率為：15/15/30/180/1800/1800/1800/1800/3600，機關：秒

11、未收到支付通知的情況，商戶系統可調用【查詢訂單APP】

12、商戶确認訂單已經支付後給使用者發貨

支付寶支付：

一、流程：

1、使用者請求支付，調用我方接口，我方根據訂單資訊和商品資訊構造符合支付寶要求的請求參數（請求參數中具有一個我方的回調位址，當支付成功的時候，支付寶會回調這個接口）去請求一個支付二維碼（可設定支付二維碼的過期時間）。我方将支付二維碼持久化到圖檔伺服器，然後圖檔位址給前端，讓前端展示給使用者。

2、剩下這一步就是使用者和支付寶的互動了。使用者支付成功後，支付寶回調我們的接口，我們的接口開始去更新訂單狀态，寫支付資訊到我們的資料庫中，如此一個完整的支付場景就完成了。支付寶會根據我們傳回的值，判斷這次交易是否成功，不成功則不扣錢。

二、難點

1、如何確定是支付寶回調的我們的接口？

如果是被惡意的第三方調用我們的接口，并且通過了将訂單狀态更新了，那麼就相當于我們形成了損失。

支付寶自身提供了一套校驗機制（這套校驗機制是怎麼做的，值得學習），我們可以通過調用支付寶的校驗接口去校驗回調是否來自支付寶。

2、如何保證幂等性？

如果是因為網絡原因、使用者多次點選。那麼要保證這些操作造成的結果是一緻的。

我的處理方案：先去資料庫中查詢狀态，如果狀态是訂單已支付，那麼傳回支付已完成的消息，否則去更新訂單資訊。

缺點：如果正在更新狀态，一個請求又過來了，那麼還是不能保證幂等性。

改進：使用一個全局分布式鎖，每次要進行這個操作（其中還是有查詢狀态這個操作），去持有這個分布式鎖，執行成功之後去釋放這個分布式鎖（這是為了避免高并發帶來的問題）。