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

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

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

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

今天重點講C端支付產品的收銀臺。

一、概念解釋

所以收銀臺有兩層概念，分別為：能夠提供的收銀臺類別以及各種收銀臺上能夠支援的支付方式及提供支付方式的支付閘道器。這裡涉及到三個名詞概念：支付產品、支付方式和支付閘道器。

支付產品

適用不同業務的不同場景的API介面，不同收銀臺型別即不同的支付產品。這裡定義了四類：

PC收銀臺：電腦PC端完成支付的收銀臺；H5收銀臺：手機內的H5網頁上完成支付的收銀臺；APP收銀臺：商戶APP內完成支付的收銀臺（APP上使用，不含前端頁面）；API收銀臺：提供給商戶自己進行包裝成自己收銀臺前端頁面的底層介面（不含前端頁面，商戶自己設計前端頁面）。

不同的支付產品有不同的優缺點，比如PC和H5收銀臺相較於API收銀臺，商戶接入不需要開發前端頁面，接入後可直接使用，但缺點可能是與上游的業務系統UI風格不一樣，所以商戶接入時要視自己的實際情況而定。

支付方式

不同支付產品的支付方式在支付流程時可能會有差別，比如PC收銀臺的支付寶是外跳轉到支付寶收銀臺頁面。

支付閘道器

PC收銀臺的支付寶和H5收銀臺的支付寶，這兩種支付方式對應的支付閘道器都是支付寶閘道器。

不管是接入PC支付寶還是H5 支付寶，首先都需要商務層面先簽約，同支付寶簽約這兩種支付產品，成為我們支付平臺的兩種支付方式，進而支付平臺的兩種支付產品也得到豐富和完善。

總的來說，支付閘道器是為了提供不同型別的支付方式，多種支付方式豐富了支付產品，支付產品向公司不同業務提供服務。

業務的持續發展需要不斷完善支付產品，比如線上拓展到線下，那就需要新增線下的一種支付產品，進而也需要對應線下的支付方式和支付閘道器。

支付方式和支付閘道器並不是1：n的關係，有些支付方式並不僅僅透過一種支付閘道器來提供，比如招行快捷支付，既可以透過支付寶閘道器也可以透過銀聯閘道器，從系統穩定性或者商務層面的閘道器費率等因素考慮，同一支付方式對接不同的支付閘道器也是支付平臺要拓展的方向。

二、收銀臺產品設計思路

1、明確使用者目標。明確使用者使用你的產品要完成什麼任務，這裡使用者使用收銀臺是要完成支付。

2、拆解使用者行為路徑。根據使用者行為過程：觸達-參與-完成，拆解使用者使用收銀臺這一產品的支付過程：支付前-支付中-支付後，在這三個階段中使用者分別有在該階段要做的操作行為。

3、為每個階段找到對應的產品目標。產品是使用者行為的載體，產品必須要有目標，這樣才能聚焦。收銀臺的總目標為安全、簡單，至於為什麼是這兩個目標，這得從支付的起源說起。

在近二十年來，支付方式經歷了不少演變。支付方式從最早的現金交易，到後來的刷卡消費、線上支付，以及分期支付。支付這些年一直在變化、在豐富、在演進，但它一直在解決兩個核心問題：信任和效率，對應到支付產品上來，即是安全和簡單。

4、找到衡量產品目標的資料指標。產品好不好，資料來說話。使用者操作行為的各個階段指標為時長和轉化率，但北極星指標為使用者從達收銀臺列表到支付完成，獲取支付結果這一整個訂單成功轉化率。

三、收銀臺功能設計

整體上分三塊：使用者使用的收銀臺前端頁面、商戶對收銀臺進行配置的商戶平臺和看不見的支付系統。

3.1 收銀臺

按照前面講到的使用者行為路徑支付前-支付中-支付後列舉功能點依次為：

頁面的通用模組

頁面的標題、底部的一些資訊展示。

訂單相關資訊展示

訂單有效時間。業務系統告知，訂單有效時間可能不唯一，比如常規訂單也許1小時，但是活動訂單也許15min。

訂單待支付金額。訂單需要支付的金額，業務系統告知，值是唯一不變的，即使用餘額、禮品卡等和支付寶組合支付，該值也不應該變，表明訂單需要被支付金額，而不管使用何種支付方式支付。

商品資訊和發貨資訊。業務系統告知，非必須欄位，看商戶訂單型別，如蘋果官網主要售賣高客單價商品，使用者對商品和地址會更關注。

支付方式展示

涉及到可展示出來的支付方式有哪些以及這些支付方式的的排序規則。

預設支付方式選中規則

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

營銷資訊展示

支付也涉及營銷，比如分期支付方式的免息配置，某種支付方式的推廣，與銀行或通道洽談的優惠政策，例如，繫結XX銀行的卡享受隨機立減優惠等。

確認支付

確認支付後，支付系統和第三方閘道器開始互動，呼叫後端獲取支付引數和支付閘道器，請求閘道器發起支付請求。確認支付時還要考慮此時是單一支付，還是組合支付或者是拆單支付。

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

使用者在瀏覽器中訪問商家網頁應用，選擇商品下單、確認購買，進入支付環節，選擇支付寶付款，使用者點選去支付，如下圖 1；進入到支付寶支付路由頁面，支付寶處理支付請求，並嘗試喚起支付寶客戶端，如下圖 2（此頁無法自定義刪除）；進入到支付寶頁面，調起支付寶支付，出現確認支付介面，如下圖 3；使用者確認收款方和金額，點選立即支付後出現輸入密碼介面，如下圖 4；輸入正確密碼後，支付寶端顯示支付結果，如下圖 5；

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

3.2 商戶平臺

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

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

3.3 支付系統

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

使用者進到收銀臺列表，支付系統會當前的業務訂單生成一筆自己的支付訂單，使用者每選擇一次支付方式，支付系統會請求第三方建立一筆交易，交易中的交易號用來跟第三方閘道器互動，同時支付系統也會建立一些引數向第三方閘道器發起支付（發起支付成功，第三方頁面才會開啟），若使用者支付成功，支付系統還會將該筆交易流水推送給財務系統，供財務進行對賬查詢。

四、總結

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

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

瞭解公司業務模型

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

選擇支付方式簽約支付通道確定收銀臺的支撐系統

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

根據閘道器提供API文件接入

最後一步根據閘道器提供的API文件接入支付和退款流程即可。