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、如何保證冪等性？
如果是因為網路原因、使用者多次點選。那麼要保證這些操作造成的結果是一致的。
我的處理方案：先去資料庫中查詢狀態，如果狀態是訂單已支付，那麼返回支付已完成的訊息，否則去更新訂單資訊。
缺點：如果正在更新狀態，一個請求又過來了，那麼還是不能保證冪等性。
改進：使用一個全域性分散式鎖，每次要進行這個操作（其中還是有查詢狀態這個操作），去持有這個分散式鎖，執行成功之後去釋放這個分散式鎖（這是為了避免高併發帶來的問題）。