編輯導語：支付體系對于任何一家公司開展業(yè)務都是一項基礎支撐能力。但每家公司開展的業(yè)務和用戶場景都不同，因此所需要的支付支撐能力也不同。支付產(chǎn)品的設計非常多的步驟，今天我們來看支付代扣產(chǎn)品設計流程是如何進行的，我們一起來看看吧。

一、代扣簽約

支付體系對于任何一家公司開展業(yè)務都是一項基礎支撐能力。

畢竟沒有支付就沒有現(xiàn)金，但因每家公司開展的業(yè)務和用戶場景不一樣，所以需要的支付支撐能力也不一樣。

從今天開始，我將結合過去幾年設計過的支付產(chǎn)品來給大家做個分享。

另外因支付的內(nèi)容相對比較復雜，畢竟這玩意跟賬戶、跟風控、跟財務，甚至跟國家的宏觀政策都有關，所以每一篇分享的內(nèi)容，我都是從日常的生活場景出發(fā)，幫你詮釋支付產(chǎn)品設計的每個細節(jié)。

好，廢話不多說，今天推出支付體系產(chǎn)品設計的第一講-免密支付。

我之前在文章中提出，任何互聯(lián)網(wǎng)產(chǎn)品的設計都能在現(xiàn)實生活中找多模型映射，反過來也是一樣。

那么在講免密支付之前，同樣，先來問大家一個問題：大家有沒有在拼多多上買過東西？或者有沒有開通騰訊視頻VIP會員服務？

反正我是開通過騰訊視頻VIP會員的，另外在拼多多上買東西，只要金額在200元以下（可以調(diào)整）都是不用輸入支付密碼就能下單的，你們是不是，哈哈。

那我們就以用戶在拼多多APP上開通免密支付為例，來說明整體業(yè)務。

在理解下文內(nèi)容之前，有一點需要提前明確的是，微信里面的支付密碼是用來做什么的？

顧名思義，支付密碼是用于核驗用戶身份的。

不管是在支付的過程還是用于其他場景本質(zhì)都是校驗用戶身份。

我之前經(jīng)常提到，手機、計算機沒有眼睛沒有大腦，它沒辦法去靠生物系統(tǒng)去識別用戶，所以只能通過認證系統(tǒng)去識別。

你設置了1，下次再登錄，校驗一下1，完全吻合，那么對于手機或者計算機，它就認為是同一個人。

基于這個前提條件，我們接看下面的截圖：

如果你們沒有開通免密支付，可以嘗試進入拼多多APP的個人中心->設置->免密支付設置，選擇微信或者支付寶，點擊立即開通，走一遍流程。

好了，那么開通之后用戶就可以拼多多上買東西的時候不用輸入支付密碼就能支付成功了，這是為什么？

在回答這個問題之前，我們接著看一個現(xiàn)實生活中的例子：

老江接到合肥車管所電話，需要自己親自回去辦理車輛過戶手續(xù)，但因自己出差在外地，無法趕到合肥當?shù)剀嚬芩?，這個時候怎么解決？

這個時候老江就想到了，自己和老李關系比較好，又趕在老李最近幾天要回合肥，然后雙方簽署了一份委托協(xié)議。

老江委托老李去到合肥車管所辦理過戶手續(xù)，并且把相關的材料給老李。

于是，老李回到合肥，帶著老江所有的委托協(xié)議和相關證件，辦理了老江的車輛過戶手續(xù)。

這里面就涉及到一個場景，車管所是怎么認可老李的，明明是老江要去辦理車輛過戶是不是？

從車管所的角度來看，老李將老江的相關證件和簽署的委托協(xié)議遞交給車管所，那么車管所就等同于是老江到了車管所的現(xiàn)場。

雖然名義上是老李在辦理，但實質(zhì)上依然是老江在辦理，因為老江和老李之間形成了具有法律效應的委托關系（協(xié)議）。

好，這個里面的關系，我們再來捋一捋，是因為老江委托了老李，老李才能代理老江去辦理，對不對？

所以同樣的場景模型，我們映射到線上。

現(xiàn)在來回答上面的問題，用戶在開通免密支付之后就可以不用輸入支付密碼即可完成下單支付扣款。

正常情況下，每次用戶支付都是需要輸入支付密碼的，確保是用戶本人在操作，但是開通了免密支付為什么就不需要了？

同樣的道理也是因為產(chǎn)生了委托協(xié)議，這份委托協(xié)議就代替了用戶的支付密碼。

因為用戶已經(jīng)委托許可了拼多多（商戶）直接在用戶綁定的賬戶里面扣錢而不用告知用戶。

既然都不用告知用戶，固然就沒必要讓用戶輸入支付密碼，對不對，這就是免密支付的本質(zhì)原理？

好，接下來，我們來給免密支付下個定義：

免密支付：某種意義上也可以稱之為代扣或者代收服務（與之相反的是代付代發(fā)），從字面意義上理解是代為扣費，本質(zhì)上就是扣費服務（原名委托代扣），委托他人代為扣費。

委托代扣可應用于定期扣款或需事后扣款以期提高效率的場景。

例如但不限于：

會員制繳費、水電煤繳費、黃鉆綠鉆增值服務、打車類軟件、停車場或高速公路無人繳費、理財通基金定投、信用卡還款、音樂視頻類VIP包月扣款（就是一開始提到的騰訊視頻VIP會員）等通過用戶授權給商戶，進行委托扣款的場景。

現(xiàn)在我們再來回想下，你在拼多多上開通免密支付是不是要簽署委托協(xié)議。

如下圖（只不過你沒注意罷了）：

上面右圖已經(jīng)說的很明確，你授權商戶（這里的商戶就是拼多多）向財付通（這里的財付通就是微信支付）發(fā)出扣款指令。

財付通在不驗證您的支付密碼、短信動態(tài)嗎等信息的情況下直接從您的銀行賬戶或者微信賬戶中扣劃商戶指定的款項。

這個就是典型的用戶授權拼多多，符合前文講的老江授權老李的場景業(yè)務。

我們再來看下用戶開通免密支付的過程：

自上到下，從左到右：

• 第1個界面：在拼多多的免密支付設置界面（下文統(tǒng)一為：商戶或商戶的移動應用）；
• 第2個界面：從第1個界面：跳轉到微信（下文統(tǒng)一為：渠道）；
• 第3個界面：微信輸入支付密碼界面；
• 第4、5個界面：開通成功界面；
• 第6個界面：回跳至拼多多的界面，更新開通狀態(tài)。

下面我們進入本篇文章的正題，代扣產(chǎn)品怎么設計：

我們還是以拼多多開通微信的免密支付為例來說明。

代扣流程的設計涉及到三方：用戶、商戶、渠道（渠道可以是銀行也可以是第三方支付）。

有些條件需要提前準備：

第一，要拿到渠道的代扣服務文檔，也就是微信的代扣文檔。

畢竟拼多多接的是微信服務，商戶要想使用騰訊微信的代扣服務，還是要按照人家微信的規(guī)矩來。

所以商戶（拼多多）的工作人員需要提前帶著你的營業(yè)執(zhí)照、法人代表的證件到深圳騰訊公司去申請，只不過現(xiàn)在都可以線上申請入住了（入住流程請查閱微信開放平臺，這里不在描述）。

當商戶入住微信平臺之后，微信會給商戶（拼多多）頒發(fā)一個賬號，等同于你去銀行開戶的時候銀行給你一張銀行卡一樣。

這個銀行卡號就是你在銀行開的賬戶，所以微信也會給拼多多開一個賬戶，這個賬戶叫做商戶號（一般以8打頭的數(shù)字）。

第二，申請“模版ID”。

包括appId、商戶號、密鑰等參數(shù)。

這些參數(shù)都是在后續(xù)流程中使用到的，所以要提前向微信工作人員申請。

如果接入的是支付寶，就需要向阿里巴巴申請。

把微信的相關參數(shù)申請下來之后，還要拿到微信的代扣接口文檔（微信那邊的工作人員會提供），網(wǎng)上也有公開的。

微信支付接入流程：https://pay.weixin.qq.com/wiki/doc/api/wxpay_v2/papay/chapter2_6.shtml。

微信協(xié)議簽約和扣費接口文檔：https://pay.weixin.qq.com/wiki/doc/api/wxpay_v2/papay/chapter1_1.shtml。

以上是完成產(chǎn)品設計的前提條件，作為產(chǎn)品經(jīng)理要會閱讀接口文檔。

以上準備工作完成之后就需要著手開始設計代扣的流程，這個是重點。

進行流程設計之前，我們先明確幾個系統(tǒng)角色，當然只是舉例：

移動應用：用戶簽約代扣業(yè)務的移動APP，或商戶APP。

移動應用server：一般指的是移動應用對應的后臺處理系統(tǒng)，需要實現(xiàn)支付相關接口支付系統(tǒng)。

公司內(nèi)部支付系統(tǒng)，又稱支付網(wǎng)關服務系統(tǒng)，連接移動應用server 端和第三方支付系統(tǒng)，對第三方支付系統(tǒng)協(xié)議簽約、解約、查詢等接口進行封裝；

渠道系統(tǒng)：第三方支付機構或銀行。

大概的系統(tǒng)流程如下：

當然每家公司的系統(tǒng)架構不一樣，這個只是舉例：我們看微信需要哪些材料（參數(shù)）：

好，上面兩張圖，是微信需要的文件材料，我們放到計算機的世界里，那就是數(shù)據(jù)或參數(shù)，上面的圖都有解釋，這里不再細說。

我們需要提煉的是這些參數(shù)如果給錯了，怎么處理，我們一個一個的來分析：

應用ID、商戶號、模板id：這三個參數(shù)如果給錯了會有什么結果？不用說交易肯定會失敗。

因為這個都是提前申請的，就像你去國外之前要辦理護照一樣，這個護照就是你的證件。

如果你拿了一個錯的護照或者假的護照，也是去不了國外的，對不對。

回調(diào)通知url：這個如果提供錯了，會怎么樣？

我們首先看看，這個參數(shù)人家微信那邊是怎么解釋的：

回調(diào)通知url是用于接收簽約成功消息的回調(diào)通知地址，以http或https開頭，通知url必須為外網(wǎng)可訪問的url，不能攜帶參數(shù)。

那么問題來了，如果這個地址因為開發(fā)人員或者因為計算機本身的原因搞錯了，那么就會導致平臺系統(tǒng)（什么是平臺系統(tǒng)？請看上面的圖）收不到協(xié)議簽約結果的通知或返回。

就會導致兩邊的數(shù)據(jù)不一致（微信系統(tǒng)那邊簽約成功，而平臺系統(tǒng)的簽約失?。?，這個時候怎么辦？

這時候平臺系統(tǒng)需要主動發(fā)起查詢。

我們再來看看這張圖：

這張圖中，明確說明外部（也就是拼多多）App拉起微信客戶端發(fā)起簽約前，需先后臺調(diào)用預簽約接口完成預簽約，獲取pre_entrustweb_id。

再拉起微信客戶端，完成簽約，返回App。

所以微信的要求是商戶先拿到預簽約ID（pre_entrustweb_id），怎么拿呢？

我們來嘗試畫下預簽約ID獲取的流程圖：

好，思考下這個流程有沒有問題？

接下來，當商戶也就是拼多多拿到這個預簽約ID（pre_entrustweb_id）了。

接下來，怎么處理？

拼多多APP是不是要跳轉微信客戶端APP，這個流程怎么設計？

我們把上面的流程再進一步細化一下，完成的簽約流程如下圖：

到此是不是就結束了？當然不是。

我們設計流程不是單純的為開發(fā)設計流程，還要為自己設計流程。

我來問大家一個問題，如果這個流程設計結束了，產(chǎn)品經(jīng)理怎么跟蹤每個用戶簽約的簽約狀態(tài)，沒法跟蹤吧。

所以呢，你先思考，不要著急往下看。

你怎么做呢？

我們給簽約增加幾個狀態(tài)值（已創(chuàng)建、處理中、簽約成功、已過期、簽約失?。?，用于跟蹤和查詢每個用戶簽約的過程。

有兩點好處：

• 每筆簽約都有過程節(jié)點，方便在出現(xiàn)問題的時候能迅速定位問題；
• 針對所有簽約免密支付的用戶我能通過直觀的原型設計展現(xiàn)簽約記錄。

所以我們再把上面的簽約流程翻譯一下，如下圖。

通過這個圖，把簽約的協(xié)議ID做成節(jié)點狀態(tài)，方便后臺查詢和問題定位。

好了，到此為止，一個完整的簽約協(xié)議的流程圖就設計完畢。

好了，再看下面的流程圖，對比上面微信簽約，有什么區(qū)別？

再回到上面的問題，如果因開發(fā)人員或者因為計算機本身程序的原因搞錯參數(shù)了，導致平臺系統(tǒng)收不到協(xié)議簽約結果的通知或返回，就會導致兩邊的數(shù)據(jù)不一致（微信系統(tǒng)那邊簽約成功，而平臺系統(tǒng)的簽約失?。?。

這個時候怎么辦？

好，要主動發(fā)起查詢，查詢的接口，我們再來看下微信需要的參數(shù)：

說白了，微信需要的是商戶號、協(xié)議號、應用ID三個關鍵性的參數(shù)，流程怎么設計？

上面的流程是針對當渠道側沒有返回或者平臺側未接收到任何簽約結果，平臺側主動發(fā)起協(xié)議號簽約查詢的流程圖。

好，上面描述了一個用戶從商戶APP發(fā)起開通免密支付或代扣的簽約和查詢流程圖，這個里面還會涉及到支付流程常見的冪等原則，這里不再細說。

簽約完畢了，接下來就是支付扣款了。

流程怎么設計？首先依然看微信代扣的接口文檔：

二、代扣設計

前面講了支付產(chǎn)品里面的代扣簽約流程，與之對應，當用戶開通了免密支付，用戶即可在無需支付密碼的情況完成下單支付，整個流程怎么設計；

同樣，我們還是要先預設幾個系統(tǒng)角色：

• 移動應用：用戶簽約代扣業(yè)務的移動APP，或商戶APP。
• 移動應用server：一般指的是移動應用對應的后臺處理系統(tǒng)，需要實現(xiàn)支付相關接口
• 支付系統(tǒng)：公司內(nèi)部支付系統(tǒng)，又稱支付網(wǎng)關服務系統(tǒng)，連接移動應用server 端和第三方支付系統(tǒng)，對第三方支付系統(tǒng)協(xié)議簽約、解約、查詢等接口進行封裝；
• 渠道系統(tǒng)：第三方支付機構或銀行；

好，在用戶簽約了代扣之后，按照之前的接口文檔，渠道會返回一個簽約協(xié)議protocolId，公司內(nèi)部的支付平臺需要及時記錄這個ID；

那么我們在上篇文章提到了一個protocolId就等同于是老江授權老李的委托協(xié)議，為了方便問題定位也為了更好的完成產(chǎn)品設計和后臺查詢業(yè)務的可視化，所以增加了不同的狀態(tài)節(jié)點比如協(xié)議號的創(chuàng)建、處理中、簽約失敗、簽約成功、已過期、已解約（已過期這個狀態(tài)是必須要有的，拼多多在和微信簽訂商業(yè)合作協(xié)議時就需要明確代扣簽約后，這個協(xié)議的有效期，有的一年，有的三年）；

以下為示例流程圖（具體要結合公司實際系統(tǒng)架構靈活調(diào)整）。

三、平臺系統(tǒng)解約（代扣解約）

首先看解約的業(yè)務場景，看下圖：

上上面的兩幅截圖是用戶在拼多多側的截圖，上面的圖是微信側的截圖，也就是說用戶在拼多多側可以關閉免密服務，也可以在微信側關閉免密服務，那么這個流程怎么設計。

直接上圖：渠道側解約：

平臺側解約流程：

好了，關于代扣簽約、代扣、平臺側解約和渠道側解約的流程已經(jīng)PUSH完畢；再來思考一個場景，就是用戶一般情況下都是一般支付一邊簽約（開通）免密支付的，也就是支付并簽約的場景，這個流程該怎么設計，一樣，我們先看微信的接口文檔：

本文由 @產(chǎn)品經(jīng)理研究站?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載

題圖來自Pexels，基于CC0協(xié)議