編輯導語：随着移動支付的發展，人們越來越習慣于無現金的生活。用戶在移動端進行支付、賬戶充值時最常用的功能模塊就是收銀台，本文作者從項目實踐出發，對收銀台功能設計的流程以及過程中需要注意的問題進行了梳理盤點，與大家分享。

線下購物場景中，收銀台是顧客在超市最後停留的地方。互聯網的發展，線下場景轉移到線上，線上的收銀台也是用戶在網站最後的停留位置。

交易的存在是支付發生的前提，使用支付方式讓交易完成，支付是交易達成的最後一個環節，這通過支付産品之一的收銀台來實現。

公司内部往往有多條業務線，凡是商業活動一定涉及收款，支付系統扮演平台的角色，為多條業務線提供收款能力，接入的業務線我們稱之為商戶。

支付平台向商戶提供C端支付産品和B端商戶平台兩種類型的支付産品。商戶接入一種C端支付産品向用戶提供支付服務，同時使用B端商戶平台向C端支付産品進行功能配置，這樣商戶就具備了收款能力。

今天重點講C端支付産品的收銀台。

之前有一些人問到我，支付還需要專門的産品經理嗎？接入國内的支付寶和微信不就完了嘛。事實上，大家看到的支付隻是冰山一角，僅看商戶平台的功能模塊中，風控、路由、對賬等都是大家看不到的後台支持模塊，前端覺察不到卻需要花很大功夫去做。

一、概念解釋

以支付平台的角色來看（支付平台往往接入多家支付渠道，比如支付寶、微信支付和京東支付等），需要解決公司各個業務線在不同場景下，對收銀台提供支付方式的不同需求。

所以收銀台有兩層概念，分别為：能夠提供的收銀台類别以及各種收銀台上能夠支持的支付方式及提供支付方式的支付網關。這裡涉及到三個名詞概念：支付産品、支付方式和支付網關。

1. 支付産品

适用不同業務的不同場景的API接口，不同收銀台類型即不同的支付産品。這裡定義了四類：

1. PC收銀台：電腦PC端完成支付的收銀台；
2. H5收銀台：手機内的H5網頁上完成支付的收銀台；
3. APP收銀台：商戶APP内完成支付的收銀台（APP上使用，不含前端頁面）；
4. 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）默認支付方式選中規則

默認讓用戶使用哪種支付方式，減少用戶的操作成本（直接選擇底部确認支付按鈕發起支付）。可以用戶自定義設置，比如京東的收銀台默認支付工具。

也可以采用動态策略。動态策略一般從幾個方面考慮：用戶最近使用的支付方式、用戶最常用的支付方式、限額滿足條件、公司推廣的支付方式等，這個要根據公司的業務發展來綜合考量默認支付方式的展示規則。

（5）營銷信息展示

支付也涉及營銷，比如分期支付方式的免息配置，某種支付方式的推廣，與銀行或通道洽談的優惠

政策，例如，綁定XX銀行的卡享受随機立減優惠等。

（6）确認支付

确認支付後，支付系統和第三方網關開始交互，調用後端獲取支付參數和支付網關，請求網關發起支付請求。确認支付時還要考慮此時是單一支付，還是組合支付或者是拆單支付。

用戶選擇支付方式，确認支付後，開始發起支付。不同的支付方式支付流程有較大差異，這裡以商戶的H5收銀台，用戶選擇支付寶支付，且用戶已安裝支付寶為例。

用戶在浏覽器中訪問商家網頁應用，選擇商品下單、确認購買，進入支付環節，選擇支付寶付款，用戶點擊去支付，如下圖 1; 進入到支付寶支付路由頁面，支付寶處理支付請求，并嘗試喚起支付寶客戶端，如下圖 2（此頁無法自定義删除）； 進入到支付寶頁面，調起支付寶支付，出現确認支付界面，如下圖 3；

用戶确認收款方和金額，點擊立即支付後出現輸入密碼界面，如下圖 4； 輸入正确密碼後，支付寶端顯示支付結果，如下圖 5；

支付後用戶主要是回到商戶網站确認訂單支付狀态，商戶也要根據支付結果個性化展示訂單處理結果。

3.2 商戶平台

向商戶提供配置收銀台的一些功能，以下為主要功能模塊介紹。

• 接入商戶信息配置，如商戶号等信息。
• 渠道中心。渠道的賬号配置、渠道是否可用、渠道關聯的支付方式等配置。
• 支付方式中心。支付方式禁用策略、支付方式排序策略配置。
• 風控中心。黑名單、風控規則引擎、風控告警等配置。
• 路由中心。支付渠道的分流規則配置，在不同端，不同業務和商品，不同的用戶，可以使用什麼支付渠道。
• 營銷中心。免息、支付方式推廣等配置。

3.3 支付系統

看得到的支付産品後面一定有看不到的系統支撐着，這是支付系統。這裡隻做簡單講述。

用戶進到收銀台列表，支付系統會當前的業務訂單生成一筆自己的支付訂單，用戶每選擇一次支付方式，支付系統會請求第三方創建一筆交易，交易中的交易号用來跟第三方網關交互，同時支付系統也會創建一些參數向第三方網關發起支付（發起支付成功，第三方頁面才會打開），若用戶支付成功，支付系統還會将該筆交易流水推送給财務系統，供财務進行對賬查詢。

四、總結

以上為收銀台的簡要介紹，可以發現，大家看到的某電商收銀台這層皮，其實隻是冰山一角，真正在解決問題的，是多數人都看不到的水面下的血肉和骨骼。

如果你想從0到1設計一個收銀台，需要先做好以下幾個準備：

（1）了解公司業務模型

知道業務是怎麼樣的，售賣的是什麼商品，是電商、遊戲、課程售賣等等。其實就是賣什麼，怎麼賣的問題。假設是電商平台，賣的是實物商品，假設售賣課程，賣的就是虛拟商品，實物商品和虛拟商品要考慮的業務規則肯定不同。

（2）選擇支付方式

想好計劃為用戶提供什麼可用的支付方式，比如微信支付，支付寶支付，銀行卡快捷支付，賬戶餘額支付？一般微信支付寶就夠了，難免有用戶想直接綁定信用卡去支付，雖然通過微信支付寶也可以使用信用卡支付；這個看平台選擇，如果有能力盡可能給用戶更多的選擇，覆蓋更多的用戶群體需求。

（3）簽約支付通道

支付寶或者微信的某一支付産品，不能直接接入，首先要合同簽署。

（4）确定收銀台的支撐系統

收銀台要想能完成支付至少需要哪些系統，賬号、渠道和支付方式的數據結構是怎樣的，哪些功能做成可配置，這些要提前做好技術方案。

（5）根據網關提供API文檔接入

最後一步根據網關提供的API文檔接入支付和退款流程即可。

#相關閱讀#

支付體系（一）：關于支付産品經理的思考

支付體系（二）：支付的基本概念

#專欄作家#

花開不敗，涵小仙女，人人都是産品經理專欄作家。文藝女青年一枚，白天工作，晚上碼字，愛美、愛跑步、愛旅行，願我手寫我心，餘生不将就。

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

題圖來自 Unsplash，基于 CC0 協議

,