“收銀臺”設計方法論

2 評論 10585 瀏覽 84 收藏 24 分鐘

收銀臺,字面意思是“收+銀+臺”,顧名思義就是收取銀子的臺子。本文作者對收銀臺的產品架構、業務架構、流程,以及常見的支付方式、支付場景等方面進行了分析,全面解析如何完整地設計一款收銀臺產品,一起來看一下吧。

收銀臺,從字面意思“收銀臺=收+銀+臺”,顧名思義就是收取銀子的臺子。本文主要是歸納抽象出收銀臺的通用設計方法,其中包含了收銀臺的產品架構、業務架構、流程,以及常見的支付方式分析、支付場景分析等,全面解析如何完整地去設計一款收銀臺產品。

01 初識收銀臺

1. 傳統收銀臺

在古代你去飯館吃飯喝酒吃肉,酒足飯飽后到柜臺掏出50兩的大元寶拍在了“收銀臺”上:老板結賬,不用找了;最原始的收銀臺就是那個柜臺,柜臺的特點就是結賬的場所,你把錢放上去,有專門的人員核實賬款與商品,無誤以后,交易就完成了。結賬場所最核心應該具備的內容應該包括以下點:

  • 商品信息:消費了什么
  • 價格信息:應該多少錢
  • 支付方式:如何結算,現款還是賒賬
  • 核實人員:核對貨款的一致
  • 貨款交割:付款結賬,宣布完結

這些信息構成收銀臺應該具備的基本元素以及職能,而且這些職能是在實際執行過程中逐漸形成并固定下來。對于電子支付收銀臺的設計具有參考意義。

2. 線下收銀臺

近代在電子支付出現之前,我們去超市購買商品,挑好貨品后拿到結賬處進行清點,工作人員告訴你“一共10斤糧票” ,你掏出紙質的票子完成了付款,商品就是你的了;此時的工作人員叫收銀員,他面前的臺子就是收銀臺;這里收銀臺就是商品和現金的交換場所。形式跟傳統收銀臺沒有本質差別,但在技術和管理能力上有了很大的提升——貨幣形式變了,有了專業的收銀人員,交易場所更加規?;?,商品管理也更加標準化。

3. 線上收銀臺

電子支付出現以后,出現了新的貨幣形式“賬戶貨幣”支付方式產生了電子支付方式,從而產生了線上的支付場所——電子支付收銀臺;一個可以在線上通過各種電子支付手段完成賬戶貨幣轉移的支付收銀臺形式。

  • PC收銀臺:在電腦上完成支付的收銀臺
  • H5收銀臺:手機內的H5網頁上完成支付的收銀臺
  • API收銀臺:以接口形式提供的收銀臺服務
  • SDK收銀臺:提供SDK開發工具包的收銀臺服務
  • 硬件收銀臺:pos機,mpos機等硬件設備,支付卡牌等

4. 移動端收銀臺

移動端收銀臺:填寫訂單、選擇支付方式、支付流程、支付結果。

“收銀臺”設計方法論

5. PC端收銀臺

如圖中的結算頁,主要“看元素、定布局、思緣由”:

  • 結算進度條
  • 地址信息
  • 支付方式選擇:貨到付款、在線支付、對公轉賬
  • 配送方式
  • 商品信息
  • 發票信息
  • 計費信息
  • 提交按鈕

“收銀臺”設計方法論

02 收銀臺的產品架構

我們重點關注收銀臺架構的三個方面:

  1. 公司所支持的收銀臺種類以未來拓展傾向
  2. 支付方式的枚舉及根據業務發展預判拓展傾向
  3. 收銀臺服務端的能力建設規劃和選擇

“收銀臺”設計方法論

03 收銀臺的業務架構

收銀臺,是支付的起點,所以無論是何種企業或者支付組織,收銀臺都是支付架構的最前位置,支付從“收銀臺”開始。

直面終端用戶“消費者,B端商戶,內部用戶”。

“收銀臺”設計方法論

消費者下單需要的用戶收銀臺:

“收銀臺”設計方法論

商家支付貨款或充值的商家收銀臺:

“收銀臺”設計方法論

04 收銀臺的支付流程

收銀臺是支付的起點,是交易環節和支付環節的銜接點,用戶在交易環節完成了商品的選購以及訂單的填寫、合同簽約以后,下一步就要進入支付環節完成支付,而支付的起點就是收銀臺。用戶在收銀臺選擇合適的支付方式進行支付。

“收銀臺”設計方法論

05 從功能上理解收銀臺

收銀臺不只是用戶看到的收銀臺頁面那么簡單,其除了在不同場所頁面元素以及交互方式不同以外,與后臺的數據交互以及子系統的劃分也會存在差別。

例如普通的商戶和三方支付機構對收銀臺的設計思路會存在差別,這些差別是由于:

  1. 其直接服務的用戶群體不同
  2. 收銀臺的業務定位不同

這些差別可以從不同角度去分析,例如分析不同組織之間的收銀臺差別、同一個組織的收銀臺的前后端的差別。

從組織維度對比:

  • 商戶側的收銀臺分:前臺/后臺,前臺面向用戶,后臺面向渠道
  • 支付公司的收銀臺:前臺對應商戶或者直接面對用戶,后臺面向渠道

從前后臺對比:

  • 收銀臺前臺:面向用戶的可視化收銀臺頁面主要是提供給用戶完成支付方式選擇和支付請求的發起
  • 收銀臺后臺:主要是調用后端獲取支付參數和支付通道,請求通道發起支付請求

06 收銀臺的關鍵指標

問自己一個問題:我的收銀臺好嗎?

產品的一切目的都是以價值為導向,無論是用戶價值還是企業價值,否則就失去的產品的方向和意義。

對收銀臺來說,我們如何定義其好壞,考量其“好壞”,所以需要建立幾個核心指標用以考核收銀臺。

  • 用戶支付體驗-NPS:好不好用,用戶用得爽不爽,界面舒服,操作流暢,支付方式豐富
  • 支付時效:最短的時間完成支付,簡單的加載5s內可以反饋支付結果
  • 支付成功率:支付成功率越高意味著用戶體驗越好,同時也是支付轉化率中最核心的一部分
  • 支付轉化率:平臺交易在“支付環節”的轉化率高低,是整個交易轉化率的一部分

“收銀臺”設計方法論

07 設計收銀臺前的準備

在設計收銀臺之前要先做好下面幾個方面的準備,才能確保設計的產品相對完整,能夠達到預期的用戶體驗,完成相關的支付指標。

1)了解公司業務模型

做任何產品的前提就是先了解業務是怎么樣的;例如售賣的是什么商品,業務模式是電商、游戲、課程售賣還是會員充值等等,其實就是搞清楚賣什么,怎么賣的問題;我們假設是電商平臺,賣的是實物商品。

2)選擇支付方式

想好要為用戶提供什么支付方式,比如微信支付,支付寶支付,銀行卡快捷支付,賬戶余額支付?一般場景中,選擇微信支付寶就夠了,但也難免有用戶想直接綁定信用卡去支付,雖然通過微信支付寶也可以使用信用卡支付;這個要看平臺的選擇,如果有能力實現就盡可能給用戶更多的選擇,滿足更多的用戶需求,覆蓋更多的支付場景。

3)簽約支付通道

完成了(2)的分析,基本就可以確定要簽約什么支付產品,也就知道該如何去設計收銀臺了。假設簽約了微信支付,易寶的快捷支付,自建錢包;就可以拿到微信的文檔,易寶支付的文檔,錢包賬戶自己來設計;拿到文檔后就知道了支付需要的參數,就能確定我們請求通道時需要哪些參數,哪些參數是用戶提供的,哪些參數需要后臺整理封裝,當前系統是不是可以提供需要的參數,還需要做哪些改造。

4)確定收銀臺的支撐系統

分析清楚要完成支付至少需要哪些支撐系統,收銀臺還需要內線的訂單賬單、賬務等,外線就需要收銀臺后臺、路由、風控(非必須)、支付處理、渠道管理等。

08 收銀臺前臺設計

收銀臺包含前端和后端,前端是用戶可以看到的收銀臺頁面,在訂單填寫頁提交訂單以后到達。對于前端頁面比較容易調研,因為直面用戶,所以到任何一個平臺操作一下下單和支付就可以到達相應的收銀臺,看到收銀臺展示的內容元素以及交互。

1)收銀臺的關鍵信息

收銀臺頁面內容主要包含以下幾個元素:

  • 商品信息(非必需展示) :用戶買的什么
  • 收款方 (非必須展示) :錢付給誰
  • 支付有效時間:在規定時間內支付
  • 支付方式列表:有什么支付方式可以選擇
  • 支付金額 :付多少錢
  • 支付操作:確認支付的按鈕

2)收銀臺的關鍵流程

  1. 提交訂單到達收銀臺頁面
  2. 去支付進入支付流程,當前應用或者跳轉到支付應用
  3. 支付成功或失敗的支付結果落地頁
  4. 支付落地頁的后續流程,返回什么地方
  5. 支付結束

3)收銀臺的拓展

收銀臺隨著業務的變化在不斷發生變化,在更多的端上建設收銀臺,收銀臺支持更多的支付方式,相應也會出現支付方式推薦、支付補貼露出、活動優惠推送等更多內容。

同樣收銀臺類型的拓展:逐漸發展出PC收銀臺、H5收銀臺、app收銀臺等更多的收銀臺形態。

支付方式的拓展:除了微信支付、綁卡支付、余額支付等方式以外,逐漸發展出數字人民幣支付,線下支付等支持更多支付場景的支付方式。

4)銀行卡快捷支付

銀行卡快捷支付可以選擇已經綁定的卡,也可以添加新卡;新卡的綁定一般按照綁卡鑒權的要求既可以設計出需要的要素,借記卡和貸記卡的要素不一樣;個人戶和對公戶也不一樣;隨著電子支付的發展,方式也會變化,跟著接入方的要求走即可。

5)收銀臺的余額支付

既然是自己包裝或者接入的錢包余額,算是一個新的支付方式,一個新的支付方式需要關注以下幾個要素:

  • 支付logo:就是展示給用戶的icon圖標
  • 支付方式名稱:起個名字,比如抖音支付,余額支付,錢包支付等
  • 支付發起流程:選擇這個支付方式以后,提交支付后的業務流程如何

09 常見支付場景及關系

收銀臺的設計離不開企業業務特點,而企業的業務特點又離不開交易場景,我們看下常見的支付場景有哪些,這些場景對收銀臺的訴求。

“收銀臺”設計方法論

10 支付方式選擇與分析

對于常見的支付方式選擇,可以結合上面所述的支付場景,然后通過以下幾個維度進行分析:

“收銀臺”設計方法論

對于主流支付方式,目前國內成熟市場下,主要還是微信和支付寶以及銀行卡這三種支付方式,大部分可以滿足消費需求,但也有基于其他目的比如降低費率、覆蓋低收入人群等等,可以選擇外漏支付寶花唄等消費貸支付產品。

另外還要考慮的問題就是對用戶的覆蓋、支付體驗、支付限額、用戶類型等維度,以下是主要幾個支付方式的維度分析。

“收銀臺”設計方法論

1)余額支付方式

余額支付的最大特點就是“組織內閉環”,可以不依賴外界渠道,直接在內部完成賬務處理。

好處就是可以有更好的支付體驗和額度控制,劣勢就是依賴前置的賬戶充值,依然依賴外界支付。

最典型的余額支付方式就是“微信零錢”。

余額支付的核心是:為支付系統模擬出一條“余額支付”通道。

“收銀臺”設計方法論

2)代扣支付方式

常見的代扣場景有2個,一個是自動周期性扣費,如自動會員續費;另一個是先服務后支付,如乘車碼,我們以微信代扣支付為例。

“收銀臺”設計方法論

從協議中看代扣,有幾個關鍵描述點:從哪里扣錢、代扣前的通知、訂閱周期。

我們串起來看一下騰訊視頻會員在蘋果內簽約的自動續費的扣款路徑,以及扣款賬單。

“收銀臺”設計方法論

先服務后扣款的常見場景是打車以及乘坐地鐵的乘車碼,如我用滴滴打車,結束后微信自動支付成功,看下圖微信內的支付通知和賬單信息。

“收銀臺”設計方法論

微信代扣產品叫“微信支付扣款服務(原委托代扣)”,是為微信支付為商戶和用戶提供的,可以在交易場景之外完成支付的能力,主要服務于三個場景:

  1. 免密支付:可以實現對存在簽約協議的用戶進行小額立即扣款的功能,扣費時間無延遲,無扣費前通知,商戶只需調用【申請扣款】接口發起扣款即可。
  2. 自動續費:扣費時間有延遲,需有扣費前通知,具體參看【 周期扣費】說明文檔,目前支持通知后【24小時自動扣費】或【預扣費通知】兩種模式,商戶只能選擇申請其中一種模式實現扣費,一般申請后為【24小時自動扣費】模式,如需使用另種模式,請聯系對接您的運營同學協助申請修改模式。
  3. 授權扣款:可以實現對存在簽約協議的用戶進行大額立即扣款的功能,扣費時間無延遲,無扣費前通知,商戶只需調用【申請扣款】接口發起扣款即可。

3)小額免密支付

小額免密支付是在零售小額場景下,一定金額以下的小額支付時,無需用戶進行支付密碼確認,商戶直接發起扣款指令完成扣款的支付方式。

“收銀臺”設計方法論

4)消費分期支付方式

接入外部消費分期產品方式,以接入花唄為例,至于獨立設計消費分期屬于信貸范疇,體系龐大,后續會出單獨的內容體系,這里站在大多數普通企業視角做分期支付場景。

花唄分期是螞蟻集團推出的消費金融產品,用戶在商家端網站或線下門店購物時使用花唄分期支付,訂單全額實時支付到商家支付寶賬戶中,用戶分期償還花唄。

“收銀臺”設計方法論

11 支付方式的展示策略

收銀臺的個性化展示:我們可以從以下幾個方面去分析,當然還有很多種其他原因,歸根結底都是因為多樣化業務訴求的產生。

1)支付方式多樣化

隨著平臺的發展,為了迎合更多場景及用戶,會簽約更多的支付渠道,從微信支付寶,到銀行卡支付、蘋果支付,再到銀聯閃付、數字人民幣支付、余額支付等等,多樣化的支付方式就必然對收銀臺的展示策略提出了更高的要求。

2)業務的多樣化

有了豐富的支付渠道之后,其實業務多樣化同樣也會影響支付方式的展示,比如有些渠道拒絕某些品類的支付請求,所以如果用戶選擇了這種品類下的商品,那收銀臺就不應該展示不接收該類商品交易的渠道支付方式。

3)商戶需求的多樣化

隨著商戶數量的增加,種類的增加,合作模式的增加,對支付渠道的要求,甚至是收銀臺的要求也會相應增加,比如有些ka大商戶因為跟某些渠道有合作,可能就會要求僅支持某幾類支付方式,這樣就需要根據大商戶的特殊要求設定支付方式。

4)平臺訴求的多樣化

平臺本身也會有營銷等各種訴求,AB實驗的訴求等,也會對收銀臺的個性化提出要求,比如某些用戶優先推薦微信支付,某些已經綁了銀行卡的用戶優先推薦銀行卡支付等。

5)渠道合作的多樣化

有些渠道可能會提供一些合作模式,比如你把我放在第一位我就給你降費率,或者更有甚者,你把競品折疊,我再給你降一些費率,而這種合作模式又可能不是全量用戶,比如你要將50%的交易采用這種收銀臺模式。

6)用戶習慣的多樣化

用戶體量足夠大時,你就不得不考慮更好的用戶習慣和體驗的訴求,比如有些用戶每次購物都是用微信支付,那么下次支付你要是推薦了支付寶而折疊了微信,那必然會讓用戶多操作幾次去找到自己想要的支付方式;而如果有些用戶上次使用了銀行卡支付,那么下次推薦上次用的卡可能是一個不錯的選擇。

7)渠道營銷合作

有些銀行渠道可能會提供一些支付補貼,這也會成為支付方式個性化的需求來源,但是這種營銷又可能不是全量用戶,所以這里又需要策略問題。

所以說,收銀臺個性化展示的目的有時為了更高的成功率,有時為了提高用戶體驗,為了給某一個支付渠道引流等不同的訴求,但最終實現的業務效果就是不同的人可能看到的收銀臺頁面的支付方式的種類和順序會有差別。

專欄作家

陳天宇宙,微信公眾號:陳天宇宙,人人都是產品經理專欄作家。多平臺支付領域專欄作者,十年資深產品;專注為10萬支付產品經理和支付機構以及企業提供深度支付內容和服務!

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

題圖來自 Unsplash,基于 CC0 協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 對于沒有支付牌照的公司,如果本身是平臺化業務,是不能直接做錢包余額功能的吧,需要找持牌的三方機構來做資金流,不然涉及二清

    來自浙江 回復
    1. 你說的沒錯,余額如果是真的錢的話,確實需要考慮合規性問題;只不過,平臺側的設計依然可以如上文設計方法,資金層基于合規性底層可以接入支付機構的錢包

      來自北京 回復