這個系列自己的公眾號記錄，作為入坑第三方支付2年的工作記錄。鑒于產(chǎn)品篇反響還不錯，于是在這里和大家分享和交流，歡迎拍磚。

今兒，到了這個系列的產(chǎn)品篇了。

“等等，你不是產(chǎn)品汪，能聊得清楚這個話題么？”

。

。

。

“嗯，這個嘛，過來”

。

。

。

看看這圖，然后聽我說叨說叨，好不好的，咱們再說：

提示，這部分由于話題的因素，很難有【趣味性】，本人當(dāng)時寫的時候也是非常的費事兒。正如支付安全和用戶體驗的矛盾一樣，想要有料，【趣味性】難免打折扣，所以，忍忍。申明，本文并非百分之百的完全原創(chuàng)，除了根據(jù)本人在《簡書》的那篇《YES！第三方支付沒有PM》的內(nèi)容的截取之外，同時參考來自知乎第三方支付的專題的相關(guān)帖子以及鳳凰牌老熊的《支付網(wǎng)關(guān)的設(shè)計》的相關(guān)內(nèi)容。

不是PM，這意味著我只能從【業(yè)務(wù)使用場景】為入口，一步一步去聊支付產(chǎn)品。因此，今天的東西很簡單，兩點：

    1.常見的支付方式

    2.網(wǎng)關(guān)支付設(shè)計

所謂使用場景，我們要回歸到支付系統(tǒng)的核心業(yè)務(wù)支付上。每個平臺商，但凡有對接過支付系統(tǒng)的，已經(jīng)或多或少的實現(xiàn)了支付這個核心功能，并根據(jù)實際業(yè)務(wù)場景的需要一直在改進(jìn)支付功能。平臺有自己的交易系統(tǒng)來對接第三方支付的系統(tǒng)。因此，這里有了兩個概念，一個是【交易】，另一個是【支付】。對平臺商來說，不同的公司對這個概念的定義是不一樣的。在支付這個行當(dāng)，交易即生成訂單，支付即訂單結(jié)算。對于每一個支付行為，大部分指的是一次性支付，然后是轉(zhuǎn)賬，可能的話還有退款。一次性支付是最基礎(chǔ)的支付方式，即一次結(jié)清所有交易產(chǎn)生的費用。因此，我們先理清楚了這個一次性支付的流程，其他的支付的場景基本是基于這個衍生的。

關(guān)鍵詞一：網(wǎng)銀支付分類

網(wǎng)銀支付應(yīng)該是大家最熟悉的支付方式。起初，它分為兩類，線上支付和線下支付。線下支付指的是POS收單，而線上支付則有多重方式，按照卡的類別，分為借記卡支付和信用卡支付。再細(xì)分下去，對于銀行卡這種的支付方式，有了一般有：網(wǎng)銀支付、快捷支付、認(rèn)證支付等形式。

認(rèn)證支付

顧名思義，支付前需要從付款人處驗證一些信息。C端用戶在綁卡時，將卡信息提供給平臺方（比如，電商）。在支付的時候，C端用戶無需再輸入這些信息，由平臺在服務(wù)器側(cè)保留所提供的賬戶信息，比如，姓名，身份證號，銀行卡號，手機號，而我們需要做的是接收短信的校驗碼，即完成支付。如此一來，操作方便，是很多電商喜歡的支付方式。然而，這里也就自然而然引出一個問題：安全性，因為我們是把所有的信息給了平臺，一旦被竊取，資金就容易被盜走。

快捷支付

其實，快捷支付和認(rèn)證支付是相似的，一般的C用戶或者非技術(shù)人員其實并不是非常清楚兩者的區(qū)別。而不同點在于，用戶進(jìn)行綁卡之后，有些銀行接口會返回token，后續(xù)用token為支付憑證，無需提供卡號信息，也就是說平臺不需要本地保留卡號。

什么是token？簡單的解釋就是銀聯(lián)的接口。

還不理解？

那我們再講點兒更加枯燥的？

token，中文的叫做支付標(biāo)記，簡單的理解，你們可以認(rèn)為就是銀聯(lián)logo。實現(xiàn)原理是通過token代替銀行卡號進(jìn)行交易驗證，從而避免卡號信息泄露帶來的風(fēng)險。支付標(biāo)記是使用一個唯一的數(shù)值來替代傳統(tǒng)的銀行卡主賬號的過程，同時確保該值的應(yīng)用被限定在一個特定的商戶、渠道或設(shè)備。支付標(biāo)記可以運用在銀行卡交易的各個環(huán)節(jié)，與現(xiàn)有基于銀行卡號的交易一樣，可以在產(chǎn)業(yè)中跨行使用，具有通用性。

還不懂？

記住那個標(biāo)記，銀聯(lián)，over

網(wǎng)銀支付

比之快捷和認(rèn)證，網(wǎng)銀支付要安全很多。網(wǎng)銀支付是通過銀行的網(wǎng)上銀行的支付界面，要求用戶一定要在頁面上輸入銀行卡號，密碼等驗證信息才可以完成支付。大部分銀行還要求用戶使用U盾，K碼等其它安全控件才能支付。因此，安全和體驗在我們行業(yè)始終是矛盾存在。網(wǎng)銀的各種信息輸入，驗證帶來的用戶體驗是非常糟糕的，但是它的安全性則是多重保證的。

好了，常用的三大支付方式已經(jīng)說完了，至于其他的什么掃碼支付，NFC支付，等等，這些都是基于網(wǎng)銀支付來的，我們就不細(xì)說了。現(xiàn)在聊一個非常重要的問題，那就是支付流程。在系列的第一篇《支付那些事兒-先說一個大概》（點擊下方閱讀原文看吧）里，我從個體C端用戶和平臺方的角度做出了解釋。這里，我們從產(chǎn)品的角度來看看。

關(guān)鍵詞二：業(yè)務(wù)流程梳理

我們還是假設(shè)之前用過場景，用戶A在淘寶上買了一個200塊的面包，并通過招商銀行卡，使用快捷支付結(jié)算。這個過程是怎樣的？

C端用戶在淘寶支付頁面提交訂單，點擊一鍵支付。這個時候，我們先看平臺方這邊的流程。當(dāng)交易顯示成功的時候，這個訂單到了訂單系統(tǒng)中。然后，訂單系統(tǒng)確認(rèn)訂單無誤后，把指令傳到支付系統(tǒng)進(jìn)行結(jié)算。想了解訂單系統(tǒng)和支付系統(tǒng)的協(xié)作原理，不妨回顧一下第一篇《支付那些事兒-先說一個大概》里面的重復(fù)支付部分。

回到C端用戶。在點擊支付后，頁面會跳轉(zhuǎn)到收銀臺， 讓用戶確認(rèn)交易的金額，以及支付方式的選擇。這里，會跟據(jù)用戶的選擇，調(diào)用支付系統(tǒng)接口。當(dāng)支付系統(tǒng)接收到支付請求后，后臺會對請求的每一個字段做驗證，確認(rèn)無誤后，調(diào)用支付網(wǎng)關(guān)執(zhí)行支付（所謂ReturnURL，返回URL）。這個時候，網(wǎng)關(guān)的接口會向招商銀行的快捷支付接口發(fā)出請求，完成支付。待到支付網(wǎng)關(guān)接收到支付結(jié)果報文后，對內(nèi)容進(jìn)行解析，獲取結(jié)果，并將結(jié)果傳送到平臺的系統(tǒng)。??最后，商城系統(tǒng)收到支付結(jié)果后，開始執(zhí)行后續(xù)操作。如果是支付成功，則發(fā)貨，這個過程結(jié)束??。

與快捷相比，網(wǎng)關(guān)支付多了一步，也就是，它會將用戶的頁面引導(dǎo)到網(wǎng)銀頁面，讓用戶輸入支付信息，后續(xù)的步驟同上。從資金流看，不同地方在于，獲取返回結(jié)果上，一般銀行就直接同步返回，而銀聯(lián)則不是。它有兩種---同步返回和異步返回。

• 同步：告知操作成功或者失敗

• 異步：告知扣款成功或者失敗
  

同步操作和異步操作都需要調(diào)用方提供一個回調(diào)的URL地址，銀聯(lián)會將參數(shù)附加在這個地址上。通過解析參數(shù)可以得到執(zhí)行結(jié)果。異步操作一般有大概2秒的延遲，這個可能是因為網(wǎng)絡(luò)問題，也可能是因為交易系統(tǒng)過于復(fù)雜導(dǎo)致的。

關(guān)鍵詞三：資金流怎么走

上一節(jié)說的是支付的業(yè)務(wù)流程，那么，現(xiàn)在要看看資金流應(yīng)該是怎么走的？ 

在上面進(jìn)行到訂單信息從訂單系統(tǒng)傳遞到支付系統(tǒng)的時候，會觸發(fā)資金的實際流動。資金從用戶個人賬戶上轉(zhuǎn)移到電商公司的賬戶。當(dāng)然，銀行畢竟不是觀世音菩薩，這一筆交易是要收手續(xù)費的（資金是實時到賬，至于手續(xù)費怎么結(jié)算，有的是手續(xù)費按月結(jié)算，也有的是按交易筆數(shù)計費的，但大部分還是按照交易金額來收費）。

理清了這個之后，我們再看一個復(fù)雜一些的場景。如果支付系統(tǒng)沒有對接招商銀行，那對招行卡，就得走其它支付方式：銀聯(lián)或者第三方支付。

第一，??如果是走銀聯(lián)快捷，那要對接銀聯(lián)的接口。銀聯(lián)提供的多種接入方式，常說的快捷支付，在銀聯(lián)文檔中命名為商戶側(cè)開通token接口。通過這個接口，可以實現(xiàn)同行和跨行資金結(jié)算。不管收款行是招行還是其它行，都可以完成結(jié)算。對本地和用戶來說，體驗是一樣的。而如果是在銀聯(lián)側(cè)的，那么后臺資金流處理會不一樣。我們需要了解這個資金流，才能在異常情況下，了解資金到底跑到哪里了：

如果收款行也是招行，銀聯(lián)發(fā)報文給招行，招行的內(nèi)部系統(tǒng)要做的是兩個賬戶間的轉(zhuǎn)帳即可

如果收款行是他行，比如建行。銀聯(lián)發(fā)指令給招行和建行，分別完成各自賬戶上資金余額的增減，對個人和平臺方來說，這筆資金算是落地了。但實際資金流并不是立即發(fā)生。銀聯(lián)會在半夜做清結(jié)算后處理這筆資金。這個過程就是金融機構(gòu)之間的清結(jié)算了，一般不需要關(guān)注

第二，如果是第三方支付，對用戶來說，處理的流程和銀聯(lián)一樣。但資金流會不一樣。 第三方支付在招行和建行一般都會的托管資金。 發(fā)生交易后，一般來說不會產(chǎn)生跨行資金流動。用戶在招行的錢會被結(jié)算到第三方支付在招行的托管賬戶，而在建行的錢，會由第三方支付在建行的賬戶打到客戶賬戶上。 這就降低了跨行資金流動成本。??目前國內(nèi)主要銀行都提供快捷和直聯(lián)的接口。

對接銀聯(lián)

現(xiàn)在很多第三方支付覺得前面那些太麻煩，會選擇對接銀聯(lián)，因為對接銀聯(lián)比對接銀行簡單非常多， 不需要專線，也不需要加密機，只需要獲取ADSS認(rèn)證。 銀聯(lián)有Token接口，兩套接口，一套是銀聯(lián)側(cè)開通（可以理解為網(wǎng)銀支付），一套是商戶側(cè)開通（可以理解為快捷）。務(wù)必要求接入后者接口啊?；旧献x完接口文檔就知道怎么寫代碼了。

前面兒我們梳理了整個業(yè)務(wù)流，現(xiàn)在得來說一說，產(chǎn)品要實現(xiàn)整個流程業(yè)，要做什么?

對于支付系統(tǒng)來說，網(wǎng)關(guān)和渠道是最核心的功能，好比人的心臟，沒有了心，人活不了；同理，沒有了網(wǎng)關(guān)，支付不了。網(wǎng)關(guān)是對外提供服務(wù)的接口，所有需要渠道支持的資金操作都是通過網(wǎng)關(guān)，分發(fā)到對應(yīng)的模塊上。而支付渠道模塊是接收網(wǎng)關(guān)的請求，調(diào)用渠道接口執(zhí)行真正的資金操作。每個渠道的接口，傳輸方式是不同的。因此，網(wǎng)關(guān)的功能是為業(yè)務(wù)提供通用接口，和渠道交互的公共操作，也會放置到網(wǎng)關(guān)中。

支付系統(tǒng)對交易系統(tǒng)提供了什么服務(wù)呢？包括這么幾個點：

• 簽約

• 支付

• 充值
  

• 轉(zhuǎn)賬
  

• 退款
  

• etc...

每個服務(wù)實現(xiàn)的流程會對應(yīng)上面的點，包括：下訂單，取消訂單，退單，訂單查詢等操作。每個操作的實現(xiàn)，都包括校驗參數(shù)，支付路由，訂單生成，交易風(fēng)險評估，調(diào)用支付渠道，訂單更新，發(fā)送消息，和異步通知等幾個步驟。然而這些都是最為基本的點，實際業(yè)務(wù)上，業(yè)務(wù)場景復(fù)雜得很多，還會涉及到同步異步通知處理的內(nèi)容，這也是下面我們要進(jìn)一步闡釋的內(nèi)容。

1. 校驗參數(shù)

所有的支付操作，有一步是必不可少的，那就是校驗輸入的執(zhí)行參數(shù)。那具體驗證什么呢？首先，要驗證的是輸入?yún)?shù)中各字段的有效性，比如，用戶ID，商戶ID，價格，返回地址等。接下來是驗證賬戶狀態(tài)，這里涉及的是交易主體、交易對象等賬戶的狀態(tài)是處于可交易。

待這些都驗證好了，下一步就是驗證訂單了。如果是接的電商或者是酒店，還會有預(yù)單，還要驗證訂單號的有效性，以及確認(rèn)訂單狀態(tài)是未支付還是其他。最后也是比較關(guān)鍵的是驗證簽名，簽名signature，是為了防止支付接口被偽造而加密的操作。一般情況下，商戶拿到的key拼接成的字符串我們叫做MD5 加密，然后作為一個參數(shù)隨其他參數(shù)一起提交到服務(wù)器端。

2. 支付路由

這塊和我們在網(wǎng)上下載東西是一個道理，需要通過支付路由來提供支付。而路由的根據(jù)是用戶選擇的支付方式確定。這是充分不必要的東西，也就是說用戶指定的支付方式不一定是最終的執(zhí)行支付的渠道。比如，我選擇的是招行信用卡支付，但是，我沒有實現(xiàn)和招行對接，而是可以通過第三方支付，比如支付寶、微信，或者銀聯(lián)來。那如何選擇合適的支付渠道，就通過支付路由來實現(xiàn)。支付路由會綜合考慮收費、渠道的可用性等因素來選擇最優(yōu)方案（回頭這個可以單獨拉出來一篇談支付路由）。

3. 交易風(fēng)控評估

簡單的說就是評估你這筆交易是否存在風(fēng)險。這也是有接口的，而返回的結(jié)果有三個：

• 終止交易

• 二次驗證

• 交易通過
  

終止交易就是說系統(tǒng)評估下來，認(rèn)為該交易存在高風(fēng)險，需要終止。二次驗證，說的是該交易有一定的風(fēng)險，需要和商戶確認(rèn)該交易是否由用戶本人操作。方式有這么幾種：比如通過短信驗證碼，或者電話驗證，或者郵件驗證，等可以驗證用戶身份的方式來來校驗，通過后，則可以繼續(xù)執(zhí)行該交易。交易通過，也就是評估認(rèn)為交易是安全的，可以進(jìn)入下一步。

4. 訂單生成

將訂單信息進(jìn)入數(shù)據(jù)庫中。這個很考量系統(tǒng)穩(wěn)定性，特別是一天峰值大的時候，大批量的訂單數(shù)據(jù)的導(dǎo)入是否會影響系統(tǒng)的正常運轉(zhuǎn)。

5. 調(diào)用支付渠道

所有支付都要第三方通道來完成。一般銀行渠道的調(diào)用比較簡單，可以直接返回結(jié)果。一些第三方支付，支付寶，微信支付等，會通過異步接口來告知支付結(jié)果。比如某些第三方支付反接支付寶微信的掃碼支付服務(wù)，就需要這個異步接口的告知。

6. 訂單更新

同步返回的結(jié)果，需要我們要在主線程中更新訂單狀態(tài)，標(biāo)記支付成功還是失敗。還有一種是異步返回的渠道，需要在異步程序中處理。

7. 發(fā)送消息

通過銀行返回的消息來通知相關(guān)系統(tǒng)關(guān)于訂單的變更。

8. 異步通知

這塊我也是最近才了解的。按照上面7步的正常流程，涉及到調(diào)用遠(yuǎn)程接口，可想而知，延遲是在所難免的。如果，調(diào)用方一直出現(xiàn)堵塞，很容易超時。引入異步通知機制，就可以很好的處理這個問題。因為，通過異步，我們可以讓調(diào)用方在主線程中盡快返回，通過異步線程來得到支付結(jié)果。通過異步來獲取支付結(jié)果的渠道接口，也需要對應(yīng)的在異步通知中將結(jié)果返回給調(diào)用方。異步通知需要調(diào)用方提供一個回調(diào)地址，一般以http或者h(yuǎn)ttps的方式。好，問題來了，因為需要一個回調(diào)的http或者h(yuǎn)ttps的地址，那么技術(shù)上有問題。一旦調(diào)用失敗，是需要重試的，一兩次還好，如果太頻繁，時間間隔長了，收款方收不到款就會找到銀行去調(diào)查，也也就是支付公司發(fā)生【調(diào)單】的原因。

支付整體架構(gòu)

這塊的話，我之前碼了很多字，后來發(fā)現(xiàn)還不如XX寶的這張圖來得干脆：

接下來，我只談我知道的支付渠道的事兒，至于這里涉及的支付網(wǎng)關(guān)前置，風(fēng)控模塊等，本人才疏學(xué)淺，還是不談的好。想了解的，不妨上知乎或者找鳳凰牌老熊的文章去看個明白。

支付渠道

這一塊嘛，我也是從日常斷斷續(xù)續(xù)的跨部門溝通中了解到的，所以能夠涉及到的有限，但對于科普來說，足夠了。支付渠道在實際應(yīng)用上有兩種策略：

• 按服務(wù)來拆分

• 按渠道來拆分
  

如果是按照渠道拆分，那么相當(dāng)于我們把每個渠道單獨放在一個籃子里，對支付網(wǎng)關(guān)提供相同的服務(wù)。如果是按服務(wù)拆分，其本質(zhì)就是按不同接口來分，內(nèi)容就涉及到支付，對賬，退款等子系統(tǒng)，每個服務(wù)是獨立的，所有籃子的服務(wù)是實現(xiàn)在一起的。

還是沒懂，對嗎？

額，其實我也不太懂。太技術(shù)的事兒，我一BD汪沒懂，也沒必要懂。

但是，我們要知道一件事情，那就是支付渠道是有優(yōu)先級的，也就是先接哪個，后接哪個是有規(guī)則的。第三方支付，對大部分app來說，支付寶和微信支付肯定是必須的，一般來說，占有率大約在90%以上的交易量。為什么？因為用戶不需要綁卡，授權(quán)后就可以直接支付了。各平臺都支持，另外性能和穩(wěn)定性都不錯。對于一些特殊業(yè)務(wù)，比如B2B企業(yè)支付，那另當(dāng)別論，可以看一些專用的第三方支付平臺（比如說我司，哈哈，這里就不透入，省得有廣告之嫌）。接下來就是銀聯(lián)了，這可是嫡長子啊，它的存在唯一的好處就是簡化了和銀行對接的過程。和第三方支付主要不同的地方：需綁卡，也就是說用戶必須先把卡號，手機，身份證號提供出來。這一步，其實會折損很多用戶，因為這些都是隱私嘛。綁卡后，以后的支付操作一鍵搞定，很簡單了，用戶只需要輸入密碼就行?？偟脕碚f，網(wǎng)銀支付還是挺麻煩的，而銀聯(lián)接入也需要ADSS認(rèn)證。

和銀行對接。這一塊的話，可以自行知乎腦補一下。這里我就不細(xì)說了，等到網(wǎng)聯(lián)的正式上線，這一塊的復(fù)雜程度會減少非常的多，因此，我就不談了，自行知乎吧。

最后

本文從業(yè)務(wù)場景作為出發(fā)點，聊到了網(wǎng)關(guān)支付的方式，聊到了支付系統(tǒng)層面的流程，資金流，網(wǎng)關(guān)支付設(shè)計，支付系統(tǒng)的運行模式等。而在支付系統(tǒng)運行的地方，我們涉及到了支付路由，支付渠道，風(fēng)險評估，支付的賬戶等，那么下一期的話題也就顯而易見了，我們要談一談那支付的賬戶體系設(shè)計（也可以結(jié)合上面腦圖，先看一下大體的框架），凱撒也需要去整理一下，再開說，盡情期待。

以上。

本文由原創(chuàng)作者 @凱撒  原創(chuàng)發(fā)布于產(chǎn)品社，未經(jīng)許可，禁止轉(zhuǎn)載。

本系列一共6個部分，這是第3篇產(chǎn)品部分，想看完整6部分的，可以持續(xù)關(guān)注公眾號（jr-talk）。