微信和支付寶支付模式詳解及實現(.Net標準庫)
1. 微信和支付寶對比
2. 支付模式介紹
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. 支付結果及後續處理
上述介紹了支付主要流程,線上支付時由於是客戶端同步返回支付結果,且是在頁面直接跳轉完成,所以這個支付結果不能作為實際的支付結果,以防止前端的惡意攻擊或者支付平臺內部處理異常導致的支付失敗。 正確的支付結果需要以後臺的非同步通知為準。
如果當前訂單在一定時間內一直未支付,建議呼叫取消支付請求訂單介面,以防止後續出現錯誤支付或者訂單支付異常問題。
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下暫時不可以
相關推薦
微信和支付寶支付模式詳解及實現(.Net標準庫)
支付基本上是很多產品都必須的一個模組,大家最熟悉的應該就是微信和支付寶支付了,不過更多的可能還是停留在直接sdk的呼叫上,甚至和業務系統高度耦合,網上也存在各種解決方案,但大多形式各異,東拼西湊而成。所以這裡我介紹下OSS.PayCenter開源跨平臺支付元件 及
微信和支付寶支付模式詳解及實現二
配置 其余 logs https 朋友 一個 target 多租戶 對比 繼上篇《微信和支付寶支付模式詳解及實現》到現在已經有半年時間了,這期間不少朋友在公號留言支付相關的問題,最近正好也在處理公司支付相關的對接,打算寫這篇來做一個更進一步的介紹,同時根據主要的幾個支付
getClass()和getClassLoader()區別 以及ClassLoader詳解及用途(檔案載入,類載入)
1.1 幾個相關概念ClassLoader負責載入系統的所有Resources(Class,檔案,來自網路的位元組流等),通過ClassLoader從而將資源載入JVM 每個class都有一個reference,指向自己的ClassLoader。Class.getClassLoader() arra
【程式碼】K-means聚類詳解及實現 (Matlab聚類工具箱和自己實現)
一. 聚類 先說說聚類。顧名思義,就是有一團資料,根據某種準則把相似的資料分別聚在一起,形成不同的類別(每個類別稱為一簇)。聚類是一種無監督的演算法。所謂無監督就是說,雖然聚類把物體分類到了不同的簇,只能知道哪些資料是屬於同一類的,至於這一類資料到底是什麼,並不知道。
揹包問題——“完全揹包”詳解及實現(包含揹包具體物品的求解)
原文地址:http://blog.csdn.net/wumuzi520/article/details/7014830 完全揹包是在N種物品中選取若干件(同一種物品可多次選取)放在空間為V的揹包裡,每種物品的體積為C1,C2,…,Cn,與之相對應的價值為W1
次小生成樹詳解及模板(prim 以及 kruskal)
寫在前面我們大部分都對最小生成樹瞭解的多一些,一般求最小生成樹的演算法是prim、kurskal,那麼對於次小生成樹,我們也可以用上面兩種演算法來求解演算法解釋這兩種演算法的思路都是相同的,首先求出最小生成樹,我們列舉每條不在最小生成樹上的邊,並把這條邊放到最小生成樹上面,然
揹包問題——“01揹包”詳解及實現(包含揹包中具體物品的求解)
-----Edit by ZhuSenlin HDU 01揹包是在M件物品取出若干件放在空間為W的揹包裡,每件物品的體積為C1,C2,…,Cn,與之相對應的價值為W1,W2,…,Wn.求解將那些物品裝入揹包可使總價值最大。 動態規劃(DP)
支付寶整合過程詳解——執行DEMO
前言,夢想是需要堅持的,在路上,一路前行。加油。這兩天軟體需要整合支付寶了,第一次整合,過程還是挺簡單的,不過由於支付寶官方文件寫的不夠清晰,也是走了一些彎路,下面把過程寫出來分享給大家一、申請移動支付許可權首先登入【支付寶開放平臺】http://open.alipay.co
支付寶整合過程詳解Demo
前言,夢想是需要堅持的,在路上,一路前行。加油。 這兩天軟體需要整合支付寶了,第一次整合,過程還是挺簡單的,不過由於支付寶官方文件寫的不夠清晰,也是走了一些彎路,下面把過程寫出來分享給大家 一、申請移動支付許可權 首先登入【支付寶開放平臺】http://open.alipay.com/platform/
微信小程序頁面傳值詳解
comm glob ring div ear article tle 使用 dsm 我們知道,在微信小程序中,從一個頁面轉到另一個頁面,一般情況下可以通過navigate或redirect時候的url來攜帶參數,然後在目標頁面的onLoad函數參數中獲取這些ur
微信傳送永久圖片素材介面----詳解
本文采用倒敘模式. 我寫這個主要是因為微信開發文件的說明實在太坑了,為了更多.NET 開發人員能順利上傳微信圖片素材,分享一下: 先看看最後的呼叫成功的方法: /// <summary> ///
微信小程式setData()方法的詳解以及對陣列/json操作
一、setData()方法: 1、引數接受一個物件,以key,value的形式表示; 2、引數和變數名稱一致,可用一個值代替(es6新語法特性) 如上圖所示,在this.data中設定ceshi這條資料,在方法中,我們定義ceshi變數讓其等於that.data.ce
android高仿微信表情輸入與鍵盤輸入詳解-解決跳閃與表情切換問題
private void unlockContentHeightDelayed() { mEditText.postDelayed(new Runnable() { @Override public void run() { ((LinearLa
微信PC登入樣式個性化處理詳解
概述 近期做一個PC端微信掃碼登入的需求,微信掃碼有兩種方式,一種是新開一個二維碼頁面,另一種是內嵌入產品網頁。 第一種實現方式比較簡單了,不會使用的可以看這裡的開源專案 weixin_guide 兩種實現方案官方詳細介紹資料 戳這裡直達
微信小程式 資料訪問例項詳解
先簡單說一下,小程式的結構 如圖所示 1、每個檢視(.wxml)只需要新增對應名字的指令碼(.js)和樣式(.wxss)就可以了,不需要引用,page下面的指令碼以及樣式都是繼承至最外面的app.js , app.wxcss 2、指令碼也就是.js檔案,他有固定格式:p
微信小程式使用者登入前後臺詳解
一. 前端 wx.login({ success: function(res) { if (res.code) { //獲取使用
微信小程式畫布使用範例詳解
今天關於微信小程式的畫布,做了個簡單的範例,大家來看看吧 wxml的程式碼 <canvas style="width: 300px; height: 200px;" canvas-id="fourCanvas" bindtouchstart="star
一百行java程式碼實現自動玩微信跳一跳遊戲演算法詳解
前兩週用java實現了自動玩微信跳一跳遊戲,經過兩次優化,目前每次計算的準確率得到了大幅提升,跟大家分享一下實現演算法。 首先看一下自動玩微信跳一跳遊戲的實現原理: 手機開啟USB除錯
微信小程式上傳檔案詳解
做微信小程式難免會遇到上傳檔案的問題。今天就給大家說一個簡單的上傳檔案的例子吧 wxml程式碼 <button bindtap="upload">上傳檔案</button> js程式碼 Page({ data:{
微信公眾號80埠對映詳解(二)
接上篇全埠對映web網站到外網任意埠(包括80埠) ----—————————————————————————————————————————————————— 首先說下nat123的80埠對映和全埠對映的區別; 1.全埠對映必須啟動服務端新增對映,然後還要在客戶端啟動na