本文作者結合自己的實踐經驗來分享下支付模塊產品的設計流程，enjoy~

背景

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

需求調研

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

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

需求梳理

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

在產品設計階段，我將不同等級的會員及所能提供的不同服務差異放在了一個頁面，用戶可以很清晰的看到每一等級的會員所能享受到的服務差別。這里建議不要設置過多的會員等級，增加用戶的學習成本（我們設置了3個級別：免費會員、高級會員、專業會員，同時留下了聯系方式可以直接聯系我們提供定制化的服務）。

不同層級的會員一定要有足夠吸引用戶選購的功能點，或者說你要明確自己的客戶分層。比如中小企業客戶需要哪些功能？大企業用戶需要哪些功能等。關于用戶分級的問題，這里先不做贅述。

線上支付流程

當用戶選擇了適合的服務后，進入到確認訂單頁面。這里我省去了購物車的環節，轉而將“選擇時長、選擇支付幣種”等購物車流程，與訂單詳情合并。讓用戶做到所選即所得，縮短支付路徑。同時可以非常直觀的看到自己選擇的服務，以及需要支付的金額。

線上支付下單流程

當用戶下單后，我們在后臺自動生成1筆“待支付”狀態的訂單，同時第三方接口會回傳給我們一個URL。通過二維碼生成工具，我們會在新彈出來的頁面上將URL轉成該筆訂單所需要的二維碼。（期間涉及到我們需要用第三方支付平臺的公鑰解密文件，當時開發就出現了密鑰格式出錯導致解密失敗的問題，排查了半天原因最后大家也很尷尬?）

與此同時，后端數據庫會執行一個策略是線上支付的訂單如果在30分鐘內仍舊沒有完成支付，我們會將訂單強制關閉。前端頁面也會通過計時器的方式，告知用戶“您的支付已經超時，請重新發起”這類文案提示。這樣避免的大量堆積無效的待支付訂單，一定要對訂單自動處理。

原支付頁面會出現一個手動同步訂單狀態的彈窗，一旦出現用戶完成了支付但是頁面狀態沒有刷新的情況，可以允許用戶手動刷新。當然，如果未完成支付的話點擊，出現提示“支付尚未完成，請在新彈出的頁面完成支付”。

當用戶完成支付后，二維碼頁面會出現支付成功的彈窗，同時倒計時提醒用戶將自動關閉。原有的會員頁面刷新，提醒用戶“會員已經開通啦，ENJOY！”后端訂單狀態變更為“支付成功”此時一次線上支付流程結束。

線下支付下單流程

TO B產品同樣面臨著線下支付的環節，此時的業務邏輯是，我們會給用戶展示出來需要轉賬的銀行信息，當用戶完成轉賬后，在平臺上提交“轉賬流水單號（或者轉賬編號）”，同時轉賬時備注所需要開通的服務及賬號信息。我們收到相關業務通知郵件后，運營同學會與財務進行查賬核實。如果收到款項則第一時間在后臺為此用戶開通賬號，同時郵件提醒。如果未查收到款項，則會手動關閉此訂單（線下訂單也會自動關閉，時限設置在72小時）。

比較理想的方式是可以和財務系統對接，這塊會在后續迭代繼續優化。

管理后臺

管理后臺我們提供了一系列字段直觀的展示給運營同學：例如下單時間、支付渠道、支付金額、支付狀態查看，基本的查詢功能等。同時允許運營銅同學進行訂單狀態的修改。后續會考慮加入Dashboard，批量操作等功能。

數據打點

對于支付這種重要流程，數據打點必不可少。需要監控到用戶跳入“服務選擇”頁面前的來源頁（也就是說哪個功能能觸及到用戶需求，他有強烈欲望想看看到底如何開通會員），頁面訪問量，每個按鈕點擊量，用戶再哪個環節跳出率比較高等等，為后續支付環節優化提供數據支撐。

01APR更新：

昨天線上遇到了一次交易被拒的情況。發現問題后我們第一時間查實原因：因為產品的定價特殊性，我們的客單價相對于其他產品會高一些（平均5K/人）。一些用戶如果選擇一次購買6個月以上的套餐時，會觸發第三方監控本身的封控策略（單筆超過2萬人民幣）導致交易被拒。

解決：我第一時間聯系了第三方那邊的技術同學并說明原因，表示需要將我們產品的最高單筆交易額度提升至5萬元左右。對方表示支付寶和微信并沒有做此限制，是他們自己的風控策略，可以為我們單獨設置。但是這就需要如果一旦發現大額交易，一定要進行及時的人工審查。

復盤及后續需要處理的問題

1. 支付寶/微信官方渠道說支付相關的二維碼失效時間為2小時，第三方支付渠道建議在2分鐘內完成支付。如果真存在訂單有效期內，二維碼過期的問題。那么后續需要加入頁面輪詢，及時請求新的支付URL，替換掉失效的二維碼；（目前發現京東的交互策略：二維碼45秒過期，一旦頁面定時器到期，則需要用戶手動點擊刷新按鈕，自動請求一次新的二維碼展示給用戶）

2. 會員續費：后續會加入此功能；

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

4. 折扣價：這塊我們在后臺設計時已經預留了字段，可以滿足定額折扣、比例折扣、選擇某些套餐時折扣、達到某個值后折扣等需求；

5. 頁面交互：需要優化現有頁面交互，讓支付流程更加流暢；

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

7. 支付是業務邏輯比較復雜的模塊，需要在需求評審前想清楚各個環節的邏輯及可能出現的問題，這樣可以一定程度避免因為需求沒有考慮清楚導致開發延期的問題。

歡迎互撩～～

作者：Jeffery（微信公眾號：貓狗奇談，MDJUN_1234），數據產品經理

本文由 @Jeffery 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自StockSnap.io，基于 CC0 協議