支付體系(三):支付產品之收銀臺設計詳解
編輯導語:隨著移動支付的發展,人們越來越習慣于無現金的生活。用戶在移動端進行支付、賬戶充值時最常用的功能模塊就是收銀臺,本文作者從項目實踐出發,對收銀臺功能設計的流程以及過程中需要注意的問題進行了梳理盤點,與大家分享。
線下購物場景中,收銀臺是顧客在超市最后停留的地方?;ヂ摼W的發展,線下場景轉移到線上,線上的收銀臺也是用戶在網站最后的停留位置。
交易的存在是支付發生的前提,使用支付方式讓交易完成,支付是交易達成的最后一個環節,這通過支付產品之一的收銀臺來實現。
公司內部往往有多條業務線,凡是商業活動一定涉及收款,支付系統扮演平臺的角色,為多條業務線提供收款能力,接入的業務線我們稱之為商戶。
支付平臺向商戶提供C端支付產品和B端商戶平臺兩種類型的支付產品。商戶接入一種C端支付產品向用戶提供支付服務,同時使用B端商戶平臺向C端支付產品進行功能配置,這樣商戶就具備了收款能力。
今天重點講C端支付產品的收銀臺。
之前有一些人問到我,支付還需要專門的產品經理嗎?接入國內的支付寶和微信不就完了嘛。事實上,大家看到的支付只是冰山一角,僅看商戶平臺的功能模塊中,風控、路由、對賬等都是大家看不到的后臺支持模塊,前端覺察不到卻需要花很大功夫去做。
一、概念解釋
以支付平臺的角色來看(支付平臺往往接入多家支付渠道,比如支付寶、微信支付和京東支付等),需要解決公司各個業務線在不同場景下,對收銀臺提供支付方式的不同需求。
所以收銀臺有兩層概念,分別為:能夠提供的收銀臺類別以及各種收銀臺上能夠支持的支付方式及提供支付方式的支付網關。這里涉及到三個名詞概念:支付產品、支付方式和支付網關。
1. 支付產品
適用不同業務的不同場景的API接口,不同收銀臺類型即不同的支付產品。這里定義了四類:
- PC收銀臺:電腦PC端完成支付的收銀臺;
- H5收銀臺:手機內的H5網頁上完成支付的收銀臺;
- APP收銀臺:商戶APP內完成支付的收銀臺(APP上使用,不含前端頁面);
- API收銀臺:提供給商戶自己進行包裝成自己收銀臺前端頁面的底層接口(不含前端頁面,商戶自己設計前端頁面)。
不同的支付產品有不同的優缺點,比如PC和H5收銀臺相較于API收銀臺,商戶接入不需要開發前端頁面,接入后可直接使用,但缺點可能是與上游的業務系統UI風格不一樣,所以商戶接入時要視自己的實際情況而定。
大家對支付方式這個概念很熟悉,對支付產品這一概念可能陌生。事實上,支付寶、微信支付等對支付產品有明確的定義。
例如微信支付根據用戶不同的支付場景定義了不同的支付產品:付款碼支付、APP支付等。
在APP上使用微信支付時,我們常常稱作微信支付,但從微信支付產品角度看,稱APP支付。(大家可以自行去微信支付開發文檔上查閱)
2. 支付方式
不同支付產品的支付方式在支付流程時可能會有差別,比如PC收銀臺的支付寶是外跳轉到支付寶收銀臺頁面。但用戶在瀏覽器中訪問商家網頁應用,選擇商品下單、確認購買,進入支付環節,選擇支付寶付款,用戶點擊去支付,進入到支付寶支付路由頁面。
3. 支付網關
PC收銀臺的支付寶和H5收銀臺的支付寶,這兩種支付方式對應的支付網關都是支付寶網關。
不管是接入PC支付寶還是H5 支付寶,首先都需要商務層面先簽約,同支付寶簽約這兩種支付產品,成為我們支付平臺的兩種支付方式,進而支付平臺的兩種支付產品也得到豐富和完善。
總的來說,支付網關是為了提供不同類型的支付方式,多種支付方式豐富了支付產品,支付產品向公司不同業務提供服務。
業務的持續發展需要不斷完善支付產品,比如線上拓展到線下,那就需要新增線下的一種支付產品,進而也需要對應線下的支付方式和支付網關。
支付方式和支付網關并不是1:n的關系,有些支付方式并不僅僅通過一種支付網關來提供,比如招行快捷支付,既可以通過支付寶網關也可以通過銀聯網關,從系統穩定性或者商務層面的網關費率等因素考慮,同一支付方式對接不同的支付網關也是支付平臺要拓展的方向。
二、收銀臺產品設計思路
1、明確用戶目標。明確用戶使用你的產品要完成什么任務,這里用戶使用收銀臺是要完成支付。
2、拆解用戶行為路徑。根據用戶行為過程:觸達-參與-完成,拆解用戶使用收銀臺這一產品的支付過程:支付前-支付中-支付后,在這三個階段中用戶分別有在該階段要做的操作行為。
3、為每個階段找到對應的產品目標。產品是用戶行為的載體,產品必須要有目標,這樣才能聚焦。收銀臺的總目標為安全、簡單,至于為什么是這兩個目標,這得從支付的起源說起。
在近二十年來,支付方式經歷了不少演變。支付方式從最早的現金交易,到后來的刷卡消費、線上支付,以及分期支付。支付這些年一直在變化、在豐富、在演進,但它一直在解決兩個核心問題:信任和效率,對應到支付產品上來,即是安全和簡單。
4、找到衡量產品目標的數據指標。產品好不好,數據來說話。用戶操作行為的各個階段指標為時長和轉化率,但北極星指標為用戶從達收銀臺列表到支付完成,獲取支付結果這一整個訂單成功轉化率。
三、收銀臺功能設計
整體上分三塊:用戶使用的收銀臺前端頁面、商戶對收銀臺進行配置的商戶平臺和看不見的支付系統。
3.1 收銀臺
按照前面講到的用戶行為路徑支付前-支付中-支付后列舉功能點依次為:
(1)頁面的通用模塊
頁面的標題、底部的一些信息展示。
(2)訂單相關信息展示
訂單有效時間。業務系統告知,訂單有效時間可能不唯一,比如常規訂單也許1小時,但是活動訂單也許15min。
訂單待支付金額。訂單需要支付的金額,業務系統告知,值是唯一不變的,即使用余額、禮品卡等和支付寶組合支付,該值也不應該變,表明訂單需要被支付金額,而不管使用何種支付方式支付。
商品信息和發貨信息。業務系統告知,非必須字段,看商戶訂單類型,如蘋果官網主要售賣高客單價商品,用戶對商品和地址會更關注。
(3)支付方式展示
涉及到可展示出來的支付方式有哪些以及這些支付方式的的排序規則。
(4)默認支付方式選中規則
默認讓用戶使用哪種支付方式,減少用戶的操作成本(直接選擇底部確認支付按鈕發起支付)??梢杂脩糇远x設置,比如京東的收銀臺默認支付工具。
也可以采用動態策略。動態策略一般從幾個方面考慮:用戶最近使用的支付方式、用戶最常用的支付方式、限額滿足條件、公司推廣的支付方式等,這個要根據公司的業務發展來綜合考量默認支付方式的展示規則。
(5)營銷信息展示
支付也涉及營銷,比如分期支付方式的免息配置,某種支付方式的推廣,與銀行或通道洽談的優惠
政策,例如,綁定XX銀行的卡享受隨機立減優惠等。
(6)確認支付
確認支付后,支付系統和第三方網關開始交互,調用后端獲取支付參數和支付網關,請求網關發起支付請求。確認支付時還要考慮此時是單一支付,還是組合支付或者是拆單支付。
用戶選擇支付方式,確認支付后,開始發起支付。不同的支付方式支付流程有較大差異,這里以商戶的H5收銀臺,用戶選擇支付寶支付,且用戶已安裝支付寶為例。
- 用戶在瀏覽器中訪問商家網頁應用,選擇商品下單、確認購買,進入支付環節,選擇支付寶付款,用戶點擊去支付,如下圖 1;
- 進入到支付寶支付路由頁面,支付寶處理支付請求,并嘗試喚起支付寶客戶端,如下圖 2(此頁無法自定義刪除);
- 進入到支付寶頁面,調起支付寶支付,出現確認支付界面,如下圖 3;
- 用戶確認收款方和金額,點擊立即支付后出現輸入密碼界面,如下圖 4;
- 輸入正確密碼后,支付寶端顯示支付結果,如下圖 5;
支付后用戶主要是回到商戶網站確認訂單支付狀態,商戶也要根據支付結果個性化展示訂單處理結果。
3.2 商戶平臺
向商戶提供配置收銀臺的一些功能,以下為主要功能模塊介紹。
- 接入商戶信息配置,如商戶號等信息。
- 渠道中心。渠道的賬號配置、渠道是否可用、渠道關聯的支付方式等配置。
- 支付方式中心。支付方式禁用策略、支付方式排序策略配置。
- 風控中心。黑名單、風控規則引擎、風控告警等配置。
- 路由中心。支付渠道的分流規則配置,在不同端,不同業務和商品,不同的用戶,可以使用什么支付渠道。
- 營銷中心。免息、支付方式推廣等配置。
3.3 支付系統
看得到的支付產品后面一定有看不到的系統支撐著,這是支付系統。這里只做簡單講述。
用戶進到收銀臺列表,支付系統會當前的業務訂單生成一筆自己的支付訂單,用戶每選擇一次支付方式,支付系統會請求第三方創建一筆交易,交易中的交易號用來跟第三方網關交互,同時支付系統也會創建一些參數向第三方網關發起支付(發起支付成功,第三方頁面才會打開),若用戶支付成功,支付系統還會將該筆交易流水推送給財務系統,供財務進行對賬查詢。
四、總結
以上為收銀臺的簡要介紹,可以發現,大家看到的某電商收銀臺這層皮,其實只是冰山一角,真正在解決問題的,是多數人都看不到的水面下的血肉和骨骼。
如果你想從0到1設計一個收銀臺,需要先做好以下幾個準備:
(1)了解公司業務模型
知道業務是怎么樣的,售賣的是什么商品,是電商、游戲、課程售賣等等。其實就是賣什么,怎么賣的問題。假設是電商平臺,賣的是實物商品,假設售賣課程,賣的就是虛擬商品,實物商品和虛擬商品要考慮的業務規則肯定不同。
(2)選擇支付方式
想好計劃為用戶提供什么可用的支付方式,比如微信支付,支付寶支付,銀行卡快捷支付,賬戶余額支付?一般微信支付寶就夠了,難免有用戶想直接綁定信用卡去支付,雖然通過微信支付寶也可以使用信用卡支付;這個看平臺選擇,如果有能力盡可能給用戶更多的選擇,覆蓋更多的用戶群體需求。
(3)簽約支付通道
支付寶或者微信的某一支付產品,不能直接接入,首先要合同簽署。
(4)確定收銀臺的支撐系統
收銀臺要想能完成支付至少需要哪些系統,賬號、渠道和支付方式的數據結構是怎樣的,哪些功能做成可配置,這些要提前做好技術方案。
(5)根據網關提供API文檔接入
最后一步根據網關提供的API文檔接入支付和退款流程即可。
#相關閱讀#
#專欄作家#
花開不敗,微信公眾號:涵小仙女,人人都是產品經理專欄作家。文藝女青年一枚,白天工作,晚上碼字,愛美、愛跑步、愛旅行,愿我手寫我心,余生不將就。
本文原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協議
專欄作家
涵小仙女,微信公眾號:涵小仙女,人人都是產品經理專欄作家。文藝女青年一枚,白天工作,晚上碼字,愛美、愛跑步、愛旅行,愿我手寫我心,余生不將就。
本文原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自 Pixabay,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
寫的很不錯,多來點。
這篇很棒,有邏輯,有圖表,說明也很清晰。
老板寫的棒棒噠。這是第三方支付的場景,能分享下第三方支付平臺與銀行的實現,包括對賬之類的
(二)咋找不到
看你作者幾篇文章,感覺思維都很連貫
寫的很棒,感謝
你好,能和你學習下B端支付產品的設計么 wx:zzw19930428
請教下,企業在平臺注冊成商家后,我們平臺自動分配商家一個虛擬的資金賬戶(用于入金出金轉賬),資金賬戶的支付密碼,是每個員工都可設自己的支付密碼嗎?還是一個資金賬戶只有一個支付密碼?
肯定是一個子賬戶(商家的后臺)唯一的支付密碼。。熊dei
入行支付行業沒多久,有好多坑還等著我填呢,表示想加你某個聯系方式,請教問題
贊
好像沒有系列2哦
太棒了,給小白普及了一大波知識。