本文作者結合自己的實(shí)踐經(jīng)驗來(lái)分享下支付模塊產(chǎn)品的設計流程，enjoy~

背景

目前筆者負責的是一款平臺類(lèi)WEB端TO B產(chǎn)品，前期重心放在搭建平臺核心功能，同時(shí)平臺也是免費對客戶(hù)開(kāi)放。隨著(zhù)用戶(hù)數增加，產(chǎn)品本身也考慮從會(huì )員分級開(kāi)始，為不同等級的客戶(hù)提供不同的服務(wù)及平臺功能。因此需要引入支付模塊，滿(mǎn)足客戶(hù)在線(xiàn)付款和線(xiàn)下銀行轉賬的需求。

需求調研

通過(guò)和客戶(hù)溝通，我們發(fā)現目前國內客戶(hù)普遍比較支持銀行轉賬、支付寶/微信、銀行卡（借記卡、信用卡）付款，付款之后需要平臺可以給開(kāi)具發(fā)票或者支付憑證，他們能夠拿去報銷(xiāo)即可?；谶@點(diǎn)，我決定首先支持國內用戶(hù)的支付需求，設計了支付模塊v1.0版本。

支付渠道我們選用了國內一家第三方支付廠(chǎng)商，可以提供同時(shí)接入支付寶、微信、銀聯(lián)的支持，費率大概是0.6%單筆交易。

需求梳理

WEB端的支付流程相較于A(yíng)PP端更為復雜，需要更多的交互細節考慮。從商品選擇到訂單確認，再到選擇支付幣種，選擇支付渠道，如何給用戶(hù)比較友好的用戶(hù)體驗尤為重要。

在產(chǎn)品設計階段，我將不同等級的會(huì )員及所能提供的不同服務(wù)差異放在了一個(gè)頁(yè)面，用戶(hù)可以很清晰的看到每一等級的會(huì )員所能享受到的服務(wù)差別。這里建議不要設置過(guò)多的會(huì )員等級，增加用戶(hù)的學(xué)習成本（我們設置了3個(gè)級別：免費會(huì )員、高級會(huì )員、專(zhuān)業(yè)會(huì )員，同時(shí)留下了聯(lián)系方式可以直接聯(lián)系我們提供定制化的服務(wù)）。

不同層級的會(huì )員一定要有足夠吸引用戶(hù)選購的功能點(diǎn)，或者說(shuō)你要明確自己的客戶(hù)分層。比如中小企業(yè)客戶(hù)需要哪些功能？大企業(yè)用戶(hù)需要哪些功能等。關(guān)于用戶(hù)分級的問(wèn)題，這里先不做贅述。

線(xiàn)上支付流程

當用戶(hù)選擇了適合的服務(wù)后，進(jìn)入到確認訂單頁(yè)面。這里我省去了購物車(chē)的環(huán)節，轉而將選擇時(shí)長(cháng)、選擇支付幣種等購物車(chē)流程，與訂單詳情合并。讓用戶(hù)做到所選即所得，縮短支付路徑。同時(shí)可以非常直觀(guān)的看到自己選擇的服務(wù)，以及需要支付的金額。

線(xiàn)上支付下單流程

當用戶(hù)下單后，我們在后臺自動(dòng)生成1筆待支付狀態(tài)的訂單，同時(shí)第三方接口會(huì )回傳給我們一個(gè)URL。通過(guò)二維碼生成工具，我們會(huì )在新彈出來(lái)的頁(yè)面上將URL轉成該筆訂單所需要的二維碼。（期間涉及到我們需要用第三方支付平臺的公鑰解密文件，當時(shí)開(kāi)發(fā)就出現了密鑰格式出錯導致解密失敗的問(wèn)題，排查了半天原因最后大家也很尷尬??）

與此同時(shí)，后端數據庫會(huì )執行一個(gè)策略是線(xiàn)上支付的訂單如果在30分鐘內仍舊沒(méi)有完成支付，我們會(huì )將訂單強制關(guān)閉。前端頁(yè)面也會(huì )通過(guò)計時(shí)器的方式，告知用戶(hù)您的支付已經(jīng)超時(shí)，請重新發(fā)起這類(lèi)文案提示。這樣避免的大量堆積無(wú)效的待支付訂單，一定要對訂單自動(dòng)處理。

原支付頁(yè)面會(huì )出現一個(gè)手動(dòng)同步訂單狀態(tài)的彈窗，一旦出現用戶(hù)完成了支付但是頁(yè)面狀態(tài)沒(méi)有刷新的情況，可以允許用戶(hù)手動(dòng)刷新。當然，如果未完成支付的話(huà)點(diǎn)擊，出現提示支付尚未完成，請在新彈出的頁(yè)面完成支付。

當用戶(hù)完成支付后，二維碼頁(yè)面會(huì )出現支付成功的彈窗，同時(shí)倒計時(shí)提醒用戶(hù)將自動(dòng)關(guān)閉。原有的會(huì )員頁(yè)面刷新，提醒用戶(hù)會(huì )員已經(jīng)開(kāi)通啦，ENJOY！后端訂單狀態(tài)變更為支付成功此時(shí)一次線(xiàn)上支付流程結束。

線(xiàn)下支付下單流程

TO B產(chǎn)品同樣面臨著(zhù)線(xiàn)下支付的環(huán)節，此時(shí)的業(yè)務(wù)邏輯是，我們會(huì )給用戶(hù)展示出來(lái)需要轉賬的銀行信息，當用戶(hù)完成轉賬后，在平臺上提交轉賬流水單號（或者轉賬編號），同時(shí)轉賬時(shí)備注所需要開(kāi)通的服務(wù)及賬號信息。我們收到相關(guān)業(yè)務(wù)通知郵件后，運營(yíng)同學(xué)會(huì )與財務(wù)進(jìn)行查賬核實(shí)。如果收到款項則第一時(shí)間在后臺為此用戶(hù)開(kāi)通賬號，同時(shí)郵件提醒。如果未查收到款項，則會(huì )手動(dòng)關(guān)閉此訂單（線(xiàn)下訂單也會(huì )自動(dòng)關(guān)閉，時(shí)限設置在72小時(shí)）。

比較理想的方式是可以和財務(wù)系統對接，這塊會(huì )在后續迭代繼續優(yōu)化。

管理后臺

管理后臺我們提供了一系列字段直觀(guān)的展示給運營(yíng)同學(xué)：例如下單時(shí)間、支付渠道、支付金額、支付狀態(tài)查看，基本的查詢(xún)功能等。同時(shí)允許運營(yíng)銅同學(xué)進(jìn)行訂單狀態(tài)的修改。后續會(huì )考慮加入Dashboard，批量操作等功能。

數據打點(diǎn)

對于支付這種重要流程，數據打點(diǎn)必不可少。需要監控到用戶(hù)跳入服務(wù)選擇頁(yè)面前的來(lái)源頁(yè)（也就是說(shuō)哪個(gè)功能能觸及到用戶(hù)需求，他有強烈欲望想看看到底如何開(kāi)通會(huì )員），頁(yè)面訪(fǎng)問(wèn)量，每個(gè)按鈕點(diǎn)擊量，用戶(hù)再哪個(gè)環(huán)節跳出率比較高等等，為后續支付環(huán)節優(yōu)化提供數據支撐。

復盤(pán)及后續需要處理的問(wèn)題

1. 支付寶/微信官方渠道說(shuō)支付相關(guān)的二維碼失效時(shí)間為2小時(shí)，第三方支付渠道建議在2分鐘內完成支付。如果真存在訂單有效期內，二維碼過(guò)期的問(wèn)題。那么后續需要加入頁(yè)面輪詢(xún)，及時(shí)請求新的支付URL，替換掉失效的二維碼；

2. 會(huì )員續費：后續會(huì )加入此功能；

3. 會(huì )員升級：需要制定升級策略，如何補差價(jià)，如何計算有效期，是否某些情況下不允許升級等等；

4. 折扣價(jià)：這塊我們在后臺設計時(shí)已經(jīng)預留了字段，可以滿(mǎn)足定額折扣、比例折扣、選擇某些套餐時(shí)折扣、達到某個(gè)值后折扣等需求；

5. 頁(yè)面交互：需要優(yōu)化現有頁(yè)面交互，讓支付流程更加流暢；

6. 風(fēng)控環(huán)節：因為目前訂單量不大，因此采用人工審核的方式。后續會(huì )加入機器自動(dòng)風(fēng)控的策略，對于一些操作違規的賬號第一時(shí)間作出限制；

7. 支付是業(yè)務(wù)邏輯比較復雜的模塊，需要在需求評審前想清楚各個(gè)環(huán)節的邏輯及可能出現的問(wèn)題，這樣可以一定程度避免因為需求沒(méi)有考慮清楚導致開(kāi)發(fā)延期的問(wèn)題。

歡迎互撩～～

作者：Jeffery（微信公眾號：貓狗奇談，MDJUN_1234），數據產(chǎn)品經(jīng)理

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

題圖來(lái)自StockSnap.io，基于 CC0 協(xié)議