繼上篇《微信和支付寶支付模式詳解及實現(xiàn)》到現(xiàn)在已經(jīng)有半年時間了，這期間不少朋友在公號留言支付相關(guān)的問題，最近正好也在處理公司支付相關(guān)的對接，打算寫這篇來做一個更進(jìn)一步的介紹，同時根據(jù)主要的幾個支付方式提供實現(xiàn)案例。希望能夠幫助有需要的同學(xué)，內(nèi)容主要分為兩個模塊：
1. 微信和支付寶支付方式細(xì)分
1） 支付方式的對比
2）接口實現(xiàn)形式
2. 案列實現(xiàn)（OSS.PaySdk）
1） 多方式配置支持
2） 不同支付方式接口實現(xiàn)
一.?微信和支付寶支付方式細(xì)分
在最近半年時間微信新增了 H5支付 和 小程序支付 接口。支付寶的接口沒有什么太大變化，但是文檔中對接口的描述做了新的調(diào)整和歸類（依然比較亂）。所以這里我會對在《微信和支付寶支付模式詳解及實現(xiàn)》文章中提到的支付方式再次進(jìn)行細(xì)化分類和對比。
1.?支付方式的對比
1).??掃碼支付
在支付寶文檔中現(xiàn)在歸類為當(dāng)面付（下單接口名稱：交易預(yù)創(chuàng)建-alipay.trade.precreate）。
這里再介紹下微信的掃碼的兩種模式，第一種：商家先按照規(guī)則生成產(chǎn)品相關(guān)二維碼，用戶掃碼后，微信發(fā)起對商家指定地址的請求，在這個請求中商家系統(tǒng)完成下單，獲取預(yù)支付信息返回，用戶端完成支付。第二種：用戶下單后，商家系統(tǒng)獲取預(yù)支付信息，生成二維碼給用戶完成支付。
2). H5支付
微信的這個接口為新增，并且商家需要申請才能開通。在支付寶中歸類為手機(jī)網(wǎng)站支付（下單接口名稱：手機(jī)網(wǎng)頁支付-alipay.trade.page.pay）
3). APP支付
客戶端發(fā)起支付，支付寶下單接口名稱：App支付-alipay.trade.app.pay
4). 公眾號支付
手機(jī)端平臺內(nèi)瀏覽器直接喚起支付。在微信內(nèi)則是 公眾號支付。支付寶則主要是生活號，接口文檔并沒有分類（下單接口名稱：交易創(chuàng)建-alipay.trade.create）
5). 小程序支付
內(nèi)部小程序支付，支付寶下單接口名稱：App支付-alipay.trade.app.pay
6). 電腦端支付（收銀臺）
因為歷史原因，支付寶在PC端同時還在提供這種支付方式，直接跳轉(zhuǎn)到支付寶的收銀臺界面，用戶可以直接通過支付寶密碼支付，或者在收銀臺頁面進(jìn)行掃碼，個人不再建議這個方式，流程上多了一步。下單接口名稱：支付頁面接口-alipay.trade.page.pay
7). 刷卡支付
這個主要是商家發(fā)起，掃描用戶條形碼/二維碼/聲波信息。為了不和上邊的掃碼支付產(chǎn)生歧義，并且這個操作類似商家刷用戶銀行卡，叫做刷卡支付。
微信也叫刷卡支付，接口名稱：提交刷卡支付。支付寶則歸為當(dāng)面付中的條碼支付，接口名稱：交易支付-alipay.trade.pay
前六種支付方式，是一般用在線上支付，用戶和商戶無需直接接觸，我將其歸類為線上支付。第七種則主要集中在超市，商場等，我一般歸類為線下支付。
2.接口實現(xiàn)形式
上邊的支付方式中，除了前五種微信支付接口名稱都是【統(tǒng)一下單】我沒有列出來之外。支付寶基本都不相同，且名稱歧義較大，給人相對雜亂的感覺。微信則相對有序很多，且下單接口基本都走統(tǒng)一下單接口，除了參數(shù)屬性上有些變化。這里我在接口的實現(xiàn)層面上也做一個簡單的分解，方便大家理解
1） 微信實現(xiàn)形式
微信的接口處理邏輯相對簡單，除刷卡支付，其余在喚起支付前需要通過統(tǒng)一下單接口請求微信支付系統(tǒng)獲取預(yù)支付信息。
如果是公號、小程序、APP支付，需要服務(wù)端再進(jìn)一步簽名，交給前端JS調(diào)用。
如果是掃碼支付，預(yù)支付信息中會返回二維碼鏈接，商戶通過服務(wù)端或者前端生成對應(yīng)的圖片即可
如果是H5支付，預(yù)支付會返回鏈接地址，瀏覽器跳轉(zhuǎn)即可
如果是刷卡支付，讀取附帶條碼上的token信息后，直接請求微信系統(tǒng)完成支付
2） 支付寶實現(xiàn)形式
支付寶則相對減少了請求次數(shù)
如果是H5、公號、電腦端支付，則將各自的參數(shù)組裝簽名之后，生成一個含有form表單的HTML，其中還附加了form.submit()方法，使得在頁面附加這段html后自動提交并喚起支付。
如果是APP、小程序支付，都是使用的APP支付接口，依然組裝簽名，但生成的是form內(nèi)容，類似：k1=v1&k2=v2的內(nèi)容，交由前端客戶端sdk方法喚起支付。
如果是掃碼支付，則會請求支付寶系統(tǒng)獲取預(yù)支付信息（含二維碼），生成圖片
如果是刷卡支付，和微信相同，讀取附帶條碼、聲波上的token信息后，直接請求支付寶系統(tǒng)完成支付
因為查詢，退款等相關(guān)接口就是簡單的調(diào)用，這里就不做介紹了。
二. 案例實現(xiàn)
上邊的實現(xiàn)形式介紹完，基本上思路上就沒什么障礙了，剩下就是功能代碼，以及接口交互時的加解密實現(xiàn)。兩個平臺在服務(wù)端也都提供了相應(yīng)的SDK，不過兩者都是在.net framework框架下，同時微信端SDK功能相對簡單，支付寶則封裝過于臃腫，具體參數(shù)需要調(diào)用方生成對應(yīng)json串的形式傳入。所以在年初我個人把兩個平臺的接口分別進(jìn)行了封裝，也就是這里要介紹的OSS.PaySdk。
當(dāng)前這個項目是在.Net Standard框架下，也就是同時支持Framework(4.6.1)和Core，基本覆蓋全部支付相關(guān)接口，并且提供多租戶的支持。
下邊主要是針對這個項目下兩個sdk的使用結(jié)合上邊的支付方式，做一個示例，所有代碼都在Github可以下載。
1.? 多方式配置支持
在SDK在實現(xiàn)的過程中，除了接口的功能的實現(xiàn)，考慮到調(diào)用方的各種情況，每個SDK在底層我都會提供三種配置的實現(xiàn)方式，并且每個SDK中都提供了一個后綴為ConfigProvider的類：
1）上下文配置設(shè)置方式
這個方式適用于多租戶的形式，在當(dāng)前請求上下文中根據(jù)請求信息的不同使用不同的商戶號，可以在構(gòu)造函數(shù)中調(diào)用ConfigProvider下的SetContextConfig方法，例如：
微信：
支付寶：
2） 聲明指定的方式
這種方式主要是適應(yīng)某些定制模塊下，不對主系統(tǒng)產(chǎn)生影響，支付至特定的商戶號，可以在接口聲明時通過構(gòu)造函數(shù)傳入，如果在當(dāng)前請求上下文中沒有找到配置信息，系統(tǒng)會優(yōu)先使用這個配置信息，以微信舉例：
3） 默認(rèn)配置設(shè)置
如果你是單一商戶的系統(tǒng)，則只需要在程序入口處設(shè)置這個值即可，如果系統(tǒng)未發(fā)現(xiàn)上下文和實例聲明的配置，則會使用當(dāng)前配置。依然以微信舉例：
以上配置優(yōu)先級依次遞減。
2.?不同支付方式接口實現(xiàn)
設(shè)置完配置之后，我對以上幾種支付方式的下單接口調(diào)用做一個演示，至于退款等接口，比較簡單，這里就不在特殊演示，源代碼中每個文件都有詳細(xì)的注釋可供查找
微信：
支付寶：
具體的代碼可以下載源碼查看sample項目，在Startup中設(shè)置一個默認(rèn)配置即可，前端代碼請查看相應(yīng)的cshtml文件
如果你還有其他問題，歡迎關(guān)注公眾號（OSSCoder）
