微信支付和支付寶等移動支付巨頭通過長期的市場教育，已經為收銀臺的交互設立了事實上的行業標準。本文深入剖析了收銀臺設計的“四段式”流程和“轉圈圈”交互體驗，揭示了在實現一個高效、穩定且用戶友好的收銀臺過程中所需考慮的關鍵要素和設計原則。

支付不就是個收銀臺嘛？你一個頁面怎么要干這么久？這可能是每個做支付的人遇到過得尷尬問題。其實這是微信、支付寶的收銀臺支付體驗做的太好了，給普通人產生的錯覺，以為收銀臺就是幾張頁面。當你被“野生收銀臺”制的服服帖帖的時候，你才會發現收銀臺有大講究。

這次不廢話，沒有場景和需求背景，直接講原理上設計。

一、四段式和轉圈圈

隨著移動支付的推廣，以及微信/支付寶的長期的市場教育，他們的收銀臺交互已經成為事實上的行業標準。只要掌握這個標準流程，做個收銀臺你就不會被繞暈了。

總結下來就是“四段式”和“轉圈圈”。

圖1：收銀臺四段式和轉圈圈

1. 四段式

收銀臺的支付過程被切分成非常原子化的四個階段，主要分為“下單、跳轉收銀臺、后臺回調、返回結果頁”，其中跳轉收銀臺這個階段合理利用可以進行聚合包裝，而不合理包裝最容易在“返回結果頁”這個階段出現“掉鏈子”的情況。（即無法跳轉回下單頁面，需要用戶手工切回）。

2. 轉圈圈

并且這四次交互需要參數銜接的非常緊密，因此一般會在“調用收銀臺”和“返回結果頁”之間增加一個本地收銀臺作為過渡頁，一方面是為了擴展本地的快捷、余額等支付方式；另一方面是為了更好銜接這三個步驟，即我們平時看到的加載頁面“轉圈圈”。（詳細的我在第四節介紹）

3. 收銀臺參數串聯

收銀臺能夠有效的銜接首先需要了解清楚不同支付產品的渠道側參數，這些參數決定了收銀臺銜接是否順暢。我們以微信支付為例來看下數據的串聯（支付寶也是類似，其他收銀臺均參考這個標準設計的）。

圖2：收銀臺參數串聯（微信為例）

收銀臺關鍵參數分為配置申請和支付過程兩類數據。

• 配置申請：在申請收銀臺之前就要有一些預設參數作為保障，這里包括了“申請參數、安全加密、應用配置”，前面兩項都是基礎參數，應用配置則會直接影響收銀臺對接和體驗的。
• 支付對接：支付對接分為四個過程，每種支付產品返回方式各有不同，下面我們結合四段交互來介紹。

（1）支付下單

圖3：下單接口串聯

圖4：下單關鍵參數說明

用戶進入收銀臺選擇支付方式提交后，就會創建一筆預支付訂單，這筆訂單是為了讓用戶跳轉收銀臺后讓其按照下單的金額進行支付。

同時下單過程也會把訂單信息，商戶號、回調URL同步傳給渠道。渠道會根據請求返回收銀臺地址或者預支付id（prepay_id），商戶側可以根據這些參數來調用收銀臺。下單完成后本地交易訂單的狀態為“初始”表示未進行支付。

（2）調用收銀臺

圖5：幾種調用收銀臺方式

根據下單返回的參數，商戶則會調用收銀臺讓用戶跳轉到渠道側進行支付，并將訂單置為“待支付”表示用戶正在進行支付。

調用收銀臺是非常重要的聚合支付的切入點，通過調用不同的收銀臺可以把很多的支付方式聚合在一起。當然這種包裝方式如果沒有按照渠道的規范處理，很容易出現結果頁無法返回的問題。

（3）后臺回調

用戶支付完成后會把支付結果以回調的方式通知到商戶的支付系統?；卣{參數是個標準處理方式，通過下單時上傳notify_url來統一處理。

回調通知到商戶后臺，交易系統記錄支付結果為“支付成功”，此時支付結果只有商戶后臺知道，用戶還停留在渠道頁面呢，所以還需要讓用戶跳回原交易頁面。

（4）返回結果頁

圖6：調用和返回的方式

用戶支付完后就要跳轉到原有的支付頁面，并且查看支付結果。這里的返回方式是與調用的方式相匹配的。

• 預設地址：公眾號、小程序、h5是要在渠道的后臺預先配置返回的地址，地址要接受渠道方審核；
• app內返回：native屬于動態訂單碼，用戶掃碼后在掃碼的錢包app內返回（例如微信、支付寶的app）；
• Sdk返回：app應用需要集成渠道側提供的sdk來返回；
• 付款碼：屬于用戶主動展碼支付，直接在手機端返回結果頁。支付結果頁的返回直接決定了支付流程的閉環和用戶體驗的良好，所以收銀臺調用方式錯配很容易造成無法返回的情況出現。

二、收銀臺架構

由于收銀臺是一層頁面包裝，因此架構設計我們主要是來看下他的功能視圖、用例集成關系和關鍵接口要素。

1. 功能視圖

圖7：收銀臺功能視圖

從上圖中我們可以看到，微信、支付寶兩套接口整體交互基本是一致的，唯一的區別就在調用的收銀臺由于適配的終端不同需要采用不同的調用方式。

快捷、賬戶兩種支付方式，他們的交互沒有按照四段式處理，功能層面并不一致。所以我們統一把這些個性化的支付方式按照“四段交互”標準包裝成“APP和H5”形式的“聚合收銀臺”，這樣支付的整體交互就統一了。

2. 用例模型

這些功能如何與整個支付系統如何集成在一起呢？下面我們來看下系統外部邊界和內部功能結構。

圖8：收銀臺用例

（1）外部邊界

1）網關訪問：

收銀臺對外提供“收銀臺服務接口”，接收來自收單網關、會員網關的支付請求。

2）客戶系統：

收銀臺對“客戶系統”主要是訪問“會員認證”和“商戶產品”配置。其中“會員認證”用于對用戶支付方式對應的“銀行卡”和“賬戶”進行信息驗證，同時也可以擴展“綁卡/開戶”的操作。

收銀臺本身是商戶簽約產品的一部分，因此收銀臺的配置是從商戶簽約產品中獲得信息。

3）支付系統：在收銀臺支付過程中，分別要與交易、渠道、風控系統進行交互，具體交互要素參看上圖。

（2）內部結構

1）收銀臺接口：收銀臺提供給外部的服務接口，包括“地址獲取、頁面獲取、回調處理、結果查詢”等；

2）收銀臺服務：收銀臺服務的主控服務，通過讀取商家的收銀臺參數來控制頁面展示和交易處理流程。

3）支付方式：以接口或者頁面的形式，提供收銀臺支付方式的信息的查詢，以及在收銀臺上對于綁卡、開戶操作的擴展。

4）支付頁面：按支付前、支付中、支付后三個步驟來操作對應的支付頁面。

2. 接口要素

我們知道做一個收銀臺它的個性化部分主要是在下單和調用收銀臺，我們就從這里下手來做統一收銀臺接口。其實這個接口我們對微信的接口要素稍加改造就能形成我們自己的聚合收銀臺接口了。

圖9：收銀臺接口要素

1）增加支付類型

要做聚合收銀臺，并不是簡單的照抄微信，因為微信雖然標準但它不是聚合收銀。所以我們在統一下單的報文中增加一個“支付類型”，讓商家要使用什么支付方式進行選擇，這樣就能無限擴展新增的收銀臺了。

2）定義公共要素

我們希望每個報文公共部分都是一樣的，業務要素是可以根據具體場景再來補充。所以我們需要仔細研讀各種收銀臺的接口文檔抽取出公共部分，當然這個過程還是挺費時間和費功夫的。為了節約大家時間我這里給大家一套標準的方案直接拿去改吧。

把圖中標紅的字段作為公共的報文要素，保持每個報文都按此方式統一處理。其他信息按照具體業務場景進行增減即可。

3）擴展業務信息

統一下單目的是創建一筆訂單來記錄交易過程，然后根據不同支付方式返回不同類型的收銀臺提供下一步操作。因此我們還要給返回報文增加一個擴展參數支持各種收銀臺參數和交互業務信息的返回給下一步交易處理提供數據。

三、收銀臺設計

1. 收銀臺前端設計

我們前面介紹過，為能夠把四段交互統一的整合起來，一般都會增加一個本地收銀臺頁面來實現過渡，他的作用有兩個，一個是包裝本地支付方式，另一個是銜接收銀臺跳轉的交互過程，即我們平時看到的轉圈圈。

主流移動支付形式有四類“銀行卡支付、余額支付、APP支付、掃碼支付”，這些支付方式都遵循了“四段式”的支付方式，并且普遍增加了轉圈圈過渡頁（大廠的app一般是做個動畫的蒙屏效果）。

（1）銀行卡支付

圖10：銀行卡快捷支付

銀行卡支付一般使用快捷支付產品，他特點就是需要簽約綁卡，支付的時候也一般需要短信驗證碼。因此這里的選擇支付方式之后是調用了本地快捷收銀臺，其后的回調結果由于是本地支付方式因此速度非?？炀涂梢酝瓿?，隨后將結果同步給商家。

圖11：銀行卡支付流程

從流程中可以看到，用戶進入聚合收銀臺后，會讀取其可用的支付產品和綁定的銀行卡，為了防止綁定銀行卡所對應的渠道無效造成支付失敗，可以采用預路由的方式把有效的銀行卡展現給用戶使用（無效的可以置灰或者折疊）。

快捷支付作為一種本地支付方式，通過包裝成一個本地收銀臺進行短信驗證和支付確認，實現了交互的統一。如果本地通過密碼驗證，可以無需發送短信驗證碼直接進行快捷支付。

支付結果一般會通過輪詢的方式查詢本地或者渠道支付結果，成功后返回支付結果頁面，并查詢訂單信息展示給用戶確認。（實際開發時回調和輪詢一般二選一即可）

（2）本地余額支付

圖12：支付賬戶余額支付

本地余額支付主要指通過本地支付賬戶進行支付（支付賬戶又叫會員賬戶、余額賬戶）。用戶選擇支付方式后會跳轉到余額賬戶的收銀臺確認訂單與賬戶后輸入密碼完成支付，返回商家頁面。

圖13：本地余額支付流程（實時返回）

由于賬戶是本地的因此這里實時扣款后直接返回給商家頁面即可。由于大廠用戶量比較大，本地余額扣款也會采用MQ異步的方式處理。因此整體交互設計上還是保持回調的處理方式。

（3）渠道賬戶支付

圖14：渠道賬戶支付渠道

賬戶支付主要是指接入“微信、支付寶”或者“銀行數字賬戶”等產品。這些支付方式就是我們四段式大展神威的場合了，其調用的收銀臺部分需要跳轉到渠道的支付環境進行支付。

圖15：渠道賬戶支付流程

從流程圖上可以看出，這里的本地收銀臺就是一個一閃而過的過渡頁，當用戶支付完成后，需要在返回的結果頁面增加輪詢來查詢訂單結果，然后返回給支付結果頁面展示訂單信息。

（4）掃碼支付

圖16：掃碼支付交互

掃碼支付主要是指“靜態碼牌”或者“網站/自助設備商品碼”，他們的特點就是可以自制一個二維碼，在用戶掃碼下單后，判斷掃碼APP來跳轉到不同的收銀臺（一般是公眾號或者服務窗）完成支付，返回方式也需要支付渠道來調用結果頁面返回。

圖17：掃碼支付流程

從流程上可以看到，由于是套用的公眾號或者服務窗接口，因此需要一個自營的公眾號/服務窗環境來嵌入一個H5的頁面。用戶掃碼時通過獲取“http報文頭”來判斷掃碼的app類型，然后選擇調用公眾號/服務窗內的H5頁面，用戶輸入金額向渠道下單完成支付?；卣{和返回處理與前面的案例相同。

2. 后端配置

有了收銀臺支付產品，就需要能夠靈活的配置出來提供給商戶使用，并且收銀臺上的所展示的內容可以進行靈活的配置，滿足不同產品、不同客戶的需求。因此收銀臺采用了如下的配置過程。

圖18：收銀臺配置關系

商戶入網申請通過后，會給商戶配置所申請的“簽約產品”，簽約產品一般是提前設置好的，只要在“商戶簽約設置”中將簽約產品關聯上就可以了。

（1）商戶信息管理

圖19：商戶信息列表

一個商戶簽約入網完成實名認證和事前審核后，商戶運營人員就會在此處給商戶創建支付產品，點擊創建會跳轉到的“商戶產品配置”頁面進行產品設置，設置完成后簽約產品會與商戶進行關聯這樣商戶就能接入使用了。當然每次配置創建、修改都需要重新審核通過后才能生效，避免配置不當造成不當配置影響商戶使用。

（2）商戶產品配置

商戶產品配置的目的就是把商戶和簽約產品關聯起來，并對支付方式提供的默認參數進行修改以符合客戶的使用需求。

圖20：商戶產品配置

從圖中我們可以看到，一個商戶可以添加多個簽約產品，并且每種簽約產品可以根據“原始簽約產品”提供的參數進行設置，以滿足不同商戶交易、賬戶和優惠活動參與的需求。

（3）簽約產品配置

在提供商戶配置之前，要先創建一個默認的支付方式配置。像聚合收銀臺這樣的產品，它可能是多組支付方式組成的，因此在這里我們把這一組的支付方式稱為一個“簽約產品”。

圖21：簽約產品設置

創建一個簽約產品需要給他設置很多東西，包括使用什么網關接口，交易類型，收付款賬戶，默認分賬方，以及為每個支付方式設置他們的交易屬性。

從上圖我們可以看到，支付方式可以進行多級分組，這樣就能適應收銀臺多種支付方式分類展示，讓用戶使用更加一目了然。同時每個支付方式還能設置它的排序、是否展開，logo，營銷文案，綁定卡很多時默認展示幾張卡等一系列細致入微的特性。

一般情況下簽約產品是提前設置好的，商戶簽約的時候直接選擇就可以了；如果商戶有特殊需求我們按照模板重新給他創建一個就能滿足不同商戶的需求。

需要再次說明的是，這里的簽約產品配置是以“收單機構”場景下的產品設置，與普通非持牌機構設置不同之處在于賬戶部分的設置。因為收單機構有清結算資質可以做渠道路由，所以不必每個支付方式綁定對應的渠道，只要設置商戶結算賬戶就可以了。

如果是非持牌機構只要把“賬戶設置部分”改為“支付渠道”的設置就可以了。

四、總結

收銀臺的詳細實現方式就介紹到這里了，我們來總結下，主要就是“四段式和轉圈圈”

1. 四段式

為了實現收銀臺的原子化包裝，因此現在收銀臺普遍采用了“統一下單、調用收銀臺、后臺回調、頁面返回”四個步驟，其中兩個地方是需要注意的。

1）調用收銀臺：是聚合收銀臺包裝的切入點，各種聚合收銀臺的奇淫技巧就是在這里大顯身手。

2）返回結果頁：是比較容易掉鏈子的地方，需要和收銀臺調用的參數緊密配合。

2. 轉圈圈

為了保障流程的銜接緊密和交互體驗的統一，一般會跨系統支付會增加一個本地過渡頁面，主要作用是銜接調用收銀臺和結果返回之間的流程和數據處理。