對于大多數做支付系統(tǒng)設計的同學來說幕与，對于支付業(yè)務提供的調用方式都不陌生挑势，今天，金融民工小曾就和大家一起探討一下：支付業(yè)務調用方式有哪些啦鸣？為什么微信公眾號支付采用JSAPI方式潮饱？
一、支付渠道調用方式
通常來說诫给，傳統(tǒng)的支付渠道調用方式分為以下幾種：API直接調用香拉、網關跳轉支付、移動端APP的SDK跳轉支付蝙搔、移動端APP直接跳轉支付缕溉、二維碼主被掃支付和JSAPI支付。
1.API直接調用
這種方式一般適用于支付渠道不再不涉及用戶交互吃型，直接進行扣款落地的場景证鸥。
例如：銀行卡刷卡，對于發(fā)卡方系統(tǒng)來說勤晚，直接校驗客戶余額和合法性后并進行扣款落地枉层。同樣的還有如協議支付、銀行卡代扣赐写、快捷支付等鸟蜡。
2.網關跳轉支付
這種方式最早誕生于線上電商平臺如淘寶、亞馬遜等挺邀。在這一類平臺需要與銀行網銀對接揉忘，為了保證安全性，需要電商平臺在發(fā)起支付時跳轉到銀行的B2C或者B2B支付網關完成支付端铛∑客戶在網銀支付網關上插入UKEY并輸入支付密碼后完成支付。
這一類支付方式應用在電商平臺上相當廣泛禾蚕，電商平臺或者支付公司都會提供類似于線上收銀臺這樣的支付網關頁面您朽，客戶可以在頁面上選擇各種支付方式完成支付。到移動互聯網時代還衍生出了H5或者叫WAP跳轉支付
3.移動端APP的SDK跳轉支付
這種方式是在近幾年移動互聯網興起之后開始進入大家生活中换淆。常見的比如電商APP上完成購物后調起支付公司提供的SDK插件完成銀行卡扣款支付哗总。這一類插件有的由支付公司提供（如蘋果提供的apply pay應用內支付插件几颜、銀聯云閃付支付插件），有的由像strip\paypal\ping++\現在支付等支付系統(tǒng)集成商提供
4.移動端APP直接跳轉支付
這種方式其實是在上面SDK跳轉支付方式上的更進一步讯屈。隨著微信蛋哭、支付寶等生態(tài)型APP的做大，原來支付只是以SDK插件形式存在變?yōu)榱穗娚藺PP需要直接跳轉到微信和支付寶等APP上來完成支付涮母。這里面的代表就是現在大家用的很多的手機上比如滴滴打車具壮、美團外賣、拼多多等互聯網電商APP跳轉到微信和支付寶APP上完成支付哈蝇。
5.二維碼主被掃支付
上述的幾種支付方式，在定義上攘已，還是屬于線上支付行為炮赦。如何區(qū)分線上支付和線下支付，就筆者多年的實踐經驗來看样勃，可以根據交易對手雙方是否需要當面完成交易來進行區(qū)分吠勘。所以掃碼支付當然屬于線下支付。傳統(tǒng)的銀行卡刷卡是通過收單機構是通過各收單機構與銀聯還有發(fā)卡機構進行API直接調用來完成扣款峡眶，客戶只需要在商戶的POS機上完成身份認證剧防，也就是輸入密碼和簽名。與之相對的辫樱，二維碼支付是客戶通過APP與商戶的POS機或者其他掃碼收銀終端完成交互峭拘，不管是主掃還是被掃，其支付鑒權過程都是依賴于客戶APP狮暑。
6.JSAPI支付
這種支付方式應該算是微信首創(chuàng)的鸡挠，其產品形式是，在微信內打開的網頁鏈接搬男，上面可以嵌入支付按鈕拣展，支付按鈕可以通過JSAPI方式直接調起微信的密碼控件完成支付，與此類似的是支付寶的服務窗支付缔逛。
7.其他復合的方式
比如先通過API下單备埃，再調起網關或者APP或者SDK，比如在網關支付頁面嵌入二維碼供客戶可以通過手機APP進行掃碼支付褐奴，其形式都是以上幾種方式的組合按脚。
二、微信公眾號支付采用JSAPI方式產品設計分析
微信JSAPI支付方式其實就是上述復合支付方式中典型的一種歉糜，但是從產品設計角度上乘寒，其設計的非常精巧，既考慮了商戶的個性化匪补，又保證了支付的安全伞辛，還與微信C端客戶無縫打通烂翰，這也為后來的二維碼聚合支付提供了一個APP廠商的標準支付產品設計模板。
2.1產品流程
微信公眾號JSAPI支付蚤氏，是一種典型的在線支付模式甘耿，先讓商戶系統(tǒng)從后臺下單，獲得參數后通過前端頁面直接向微信支付系統(tǒng)發(fā)起支付請求竿滨，在這個過程中完成客戶的身份授權以及密碼輸入佳恬，完成支付。支付結束后通過異步通知或者商戶主動發(fā)起查詢完成支付于游。
2.2產品的易用性
由于微信是在移動端毁葱，移動端支付與在線基于瀏覽器的支付模式不同，在線支付的瀏覽器可以通過網頁redirect在商戶平臺贰剥、支付平臺間傳遞信息倾剿，例如跳轉到銀行支付頁面讓用戶輸入密碼；而在移動支付場景下蚌成，除了商戶平臺前痘、支付平臺外，還多了商戶APP端担忧、商戶服務器芹缔、支付SDK（如果有）、支付平臺之間信息交互的過程瓶盛。中間最核心的環(huán)節(jié)是：需要在商戶APP端讓用戶授權確認最欠。
而在微信場景里，沒有商戶APP蓬网，客戶和商戶都用的是微信窒所，也就變成了，微信直接跟商戶網站之間完成交互的過程帆锋。所以微信要求先進行統(tǒng)一下單吵取，然后拿到prepay_id等支付參數后，商戶再調起微信完成支付锯厢，包括商戶掃用戶的掃碼支付皮官、APP支付、公眾號支付实辑、H5/WAP支付也是這樣設計捺氢。
仔細分析便可以理解，不同行業(yè)解決方案剪撬，對支付訂單請求參數不同摄乒，如果放在APP端或SDK端做，協議改動調整極為麻煩。放到統(tǒng)一下單來做馍佑，只需要調整統(tǒng)一下單接口斋否，APP端或SDK端不用做任何調整。例如：微信支付增加卡券標識拭荤，增加借貸記標識茵臭、紅包支持等，都是通過后臺增加附加字段完成舅世。另外旦委，由于移動端的網絡不確定性以及調用的復雜性，所以通過后臺API下單模式可以極大地簡化這中間的問題雏亚，既能減少出錯概率也能減少數據傳輸缨硝。另外通過JSAPI方式，可以讓商戶支付頁面完成自行定制罢低，整個支付過程看不到微信提供的任何網關頁面追葡，而是直接調用支付控件，讓整個支付過程和體驗更加流暢奕短。
2.3產品的安全性
在這中間，微信對安全性做了極其嚴格的管控匀钧，主要體現在以下方面：
2.3.1商戶網站防偽
1.調起支付密碼控件的業(yè)務域名必須ICP備案并且在微信支付后臺進行白名單配置
2.支付目錄和支付的appid必須預先配置和綁定
3.使用微信支付的公眾號主體與開通微信支付的商戶主體必須一致
4.對于未登記的網站還會有安全提示翎碑，請勿在頁面中輸入賬號密碼等敏感信息
以上幾點有效地防止了釣魚頁面和其他中間人頁面劫持
2.3.2客戶身份授權
1.另外，微信還針對跨號支付做了嚴格限制之斯，防止一個公眾號跳到其他支付網關上進行支付
2.客戶在微信支付下單前必須進行微信登錄授權(隱式授權日杈，讓用戶基本無感)
2.3.3支付過程安全
1.從后臺下單返回的支付要素需要用商戶私鑰簽名
2.一組支付參數不能被另外的用戶用于支付
3.微信自己的密碼控件，并且回顯交易對手
2.3.4風控系統(tǒng)
1.針對可疑交易進行阻斷
2.針對信用卡占比過高進行限額
3.另外有人工加機器的自動運營佑刷，對商戶行為風控莉擒，進行限額和關停處理
3 總結
不同的支付渠道的調用方式也是隨著支付業(yè)務的發(fā)展不斷地創(chuàng)新，產品的易用性和安全性是支付系統(tǒng)在這一類問題設計上的重中之重瘫絮，微信支付JSAPI的相關機制給我們提供了一個很好的參考涨冀，值得我們學習和借鑒。
