微信和支付寶支付模式詳解及實現（.Net標準庫）- OSS開源系列

　　支付基本上是不少產品都必須的一個模塊，你們最熟悉的應該就是微信和支付寶支付了，不過更多的可能仍是停留在直接sdk的調用上，甚至和業務系統高度耦合，網上也存在各類解決方案，但大多形式各異，東拼西湊而成。因此這裏我介紹下OSS.PayCenter開源跨平臺支付組件 及其框架設計。並對經常使用支付模式進行一個全面介紹，方便你們開發以及跨平臺使用。這篇文章主要圍繞如下幾個模塊：

1. 微信和支付寶對比

2. 支付模式介紹

3. OSS.PayCenter框架設計

4. 調用示例

5. 注意事項

一. 微信和支付寶對比

　　這二者如今已經佔領了移動支付的90%市場，支付形式也都大抵相同，只是在實現細節上略微不一樣。這裏之因此要專門對比，是由於有些接口的不一樣在後邊的框架的設計中也會有所影響。主要集中在如下幾個方面：

　　1. 支付方式上：

　　　　a. 支付寶多了一個聲波支付

　　　　b. 手機端H5支付方式中， 微信只支持微信內部瀏覽器

　　　　c. 微信用戶掃碼方式中除了正常下單返回支付二維碼，還提提供了回調下單模式（即掃描的二維碼並非支付二維碼，而是商品二維碼，微信會回調商戶指定地址才真實下單）

　　2. 接口安全

　　　　a.  微信不一樣接口安全等級不同，涉及付款等接口加密相對簡單（MD5，SHA1），涉及到退款，發送紅包等接口須要使用雙向證書驗證

　　　　b.  支付寶全部接口統一使用RSA加密驗證，須要公私鑰驗證。

　　3. 接口協議

　　　　a. 微信使用的xml協議，全部參數基本都在同一層級。

　　　　b. 支付寶使用json協議，核心參數放在biz_content字段中。

 

 

二. 支付模式介紹

　　1. 完整支付的流程

　　 隨着時間的發展，線上線下的支付場景都已經比較完善，各支付平臺雖然接口不一樣，可是二者在業務流程都有着類似之處。這裏我用一個流程圖來展現核心的業務流程（線上線下主要是指在用戶在線下單仍是線下商戶輔助下單）：

以上流程圖將線上和線下集中支付形式作了一個概要的說明，兩個支付平臺在具體的細節上可能或有略微不一樣，不過基本上都在這個流程範圍以內。

注：其中微信的掃碼支付中，除了正常的返回支付二維碼支付，還能夠直接掃描商品二維碼，經過微信後臺回調商家接口，在回調中完成支付請求，喚起客戶端支付。

　　2.  支付方式介紹

　   首先：線上支付

　　1）. 用戶掃碼支付  

　　　　這個通常應用在在線PC網站支付中，用戶在商戶系統下單後，選擇本身方便的支付平臺，由商戶系統向支付平臺發起支付請求，返回對應的支付二維碼，完成支付。（微信提供兩種形式，其中能夠直接掃描商品二維碼，回調處理，這個能夠方便應用在線下活動推廣中，由微信後臺間接幫助完成下單。

　　2）. 手機端支付

　　　　這個通常應用在H5站點或者app中，商戶系統下單後後臺直接發起下單請求，喚起手機支付平臺客戶端，完成支付。（微信的H5支付只能在微信內部瀏覽器中喚起。

 

　 其次：線下支付，這個主要集中在超市，商場等。常見的如：

　　1）. 商戶發起掃碼支付

　　　　這個基本在餐飲，超市，商場等。客流量較大，服務員須要快速完成收付操做，商戶後臺下單後直接掃碼。若是用戶掃碼在多人同時操做時容易出現錯單錯誤等問題

　　2）. 聲波支付（支付寶）

　　　　這個通常出現自動販售機，或者聚會相互付款等，不須要用戶掃來掃去，按住開關就可發現周邊設備。暫時只有支付提供

 

 

　　3. 支付結果及後續處理

　　上述介紹了支付主要流程，線上支付時因爲是客戶端同步返回支付結果，且是在頁面直接跳轉完成，因此這個支付結果不能做爲實際的支付結果，以防止前端的惡意攻擊或者支付平臺內部處理異常致使的支付失敗。 正確的支付結果須要之後臺的異步通知爲準。

　　若是當前訂單在必定時間內一直未支付，建議調用取消支付請求訂單接口，以防止後續出現錯誤支付或者訂單支付異常問題。

 

三. OSS.PayCenter框架設計

　　1. 框架流程

　瞭解了以上的幾種支付方式以後，那麼具體的調用什麼接口其實已經比較清晰了，那麼咱們縱向的來看一下接口調用的流程。若是把一個請求當作一個生命週期，以發起一個POST請求爲例，在OSS.PayCenter中主要流程以下：

 

 在這個框架中，分爲兩個部分：

　　下層爲基類，完成  簽名=》內容協議格式化=》請求=》響應內容協議格式化=》全局錯誤處理。其中提供了兩個基本請求方法，PostApiAsync-爲當前請求籤名，封裝xml內容調用網絡請求。 RestCommonAsync-執行當前請求，並對結果格式化和全局錯誤處理。

　　上層爲子類，具體各個接口名稱和對應的請求內容參數。（注：退款，付款在單獨的子類中，和其餘接口作了物理隔離）

 

　　2. 框架介紹

　　當前項目都基於.Net標準庫項目，也就是說同步支持.Net Framework和.Net Core，每一個項目中都會有SysTools文件夾，主要存放當前類庫的輔助類。

　　1）. 基礎配置

　　　　兩個類庫中最底層基類中，都提供了DefaultConfig 靜態屬性，能夠方便在程序全局入口中就設置好對應的支付平臺配置信息。

　　　　同時若是你存在多租戶狀況，能夠在具體的接口類構造函數中傳入不一樣租戶支付平臺配置信息。

　　2）. 命名規則

　　　　當前項目中主要接口都已經實現完畢，可是若是你須要本身從新實現，或者個別特殊未實現的接口，能夠參照各個子類的實現

　　　　實體的命名規則： 平臺名稱+動做名稱 + 接口名稱 +Req/Resp （如微信下單接口：WxAddPayUniOrderReq），實體都會繼承至對應的BaseReq/BaseResp，具體可參見源碼。

　　在當前的框架中，分爲OSS.PayCenter.WX（微信）和OSS.PayCenter.ZFB（支付寶）兩個項目，二者在接口協議，和參數格式上都徹底不一樣，因此對應底層基類細節也會有所不一樣，詳情請閱讀具體代碼。

 

四. 調用示例

　　這裏以支付寶回調結果解析爲例：

這個示例展現了主要個三個步驟，當前僅僅是解析回調結果，沒有發起網絡請求，下邊再給出一個發起支付請求的示例：

凡是涉及到網絡請求的接口都會返回一個異步Task對象，若是須要同步使用，使用.WaitResult()擴展方法便可，這個我在OSS.Http文章中已經介紹。

 

五. 注意事項

     1. 在微信項目中同時提供有發送紅包，企業付款，代金券等接口，詳情可參見具體類。

　　2. 因爲.net standard類庫當前還並非十分完整，有兩個地方須要注意一下。（下個月.net standard 2.0版本發佈後估計應該會完善了）

　　　　a。在wx項目中使用到了請求的雙向證書綁定，.net core 和.net frameword中已經實現，標準庫中暫時尚未，因此在微信配置實體中我公開了一個SetCertificata屬性，調用時只須要以下賦值便可：　　　　

config.SetCertificata = (handler, cert) =>
 {
    handler.ServerCertificateCustomValidationCallback = 
　　　　(msg, c, chain, sslErrors) => true;
    handler.ClientCertificates.Add(cert);
 };

　　　　b. 支付寶的加解密使用的RSA，自己提供的方法依賴於Windows系統的「crypt32.dll」和「advapi32.dll」兩個組件，因此我重寫了整個簽名加密模塊，隔離系統的依賴。可是在當前標準庫版本下RSACryptoServiceProvider類內部的linux平臺版本依然沒有具體實現，也就是說支付寶當前項目能夠運行windows系統中.net core下，linux下暫時不能夠，看2.0版本更新狀況如何吧。

 

若是你還有其餘問題，歡迎關注公衆號（OSSCoder）