微信支付和支付寶等移動支付巨頭通過長期的市場教育，已經為收銀台的互動設立了事實上的行業标準。本文深入剖析了收銀台設計的“四段式”流程和“轉圈圈”互動體驗，揭示了在實作一個高效、穩定且使用者友好的收銀台過程中所需考慮的關鍵要素和設計原則。
支付不就是個收銀台嘛？你一個頁面怎麼要幹這麼久？這可能是每個做支付的人遇到過得尴尬問題。其實這是微信、支付寶的收銀台支付體驗做的太好了，給普通人産生的錯覺，以為收銀台就是幾張頁面。當你被“野生收銀台”制的服服帖帖的時候，你才會發現收銀台有大講究。
這次不廢話，沒有場景和需求背景，直接講原理上設計。
一、四段式和轉圈圈
随着移動支付的推廣，以及微信/支付寶的長期的市場教育，他們的收銀台互動已經成為事實上的行業标準。隻要掌握這個标準流程，做個收銀台你就不會被繞暈了。
總結下來就是“四段式”和“轉圈圈”。
圖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. 轉圈圈
為了保障流程的銜接緊密和互動體驗的統一，一般會跨系統支付會增加一個本地過渡頁面，主要作用是銜接調用收銀台和結果傳回之間的流程和資料處理。
本文由人人都是産品經理作者【剛哥】，微信公衆号：【剛哥白話】，原創/授權 釋出于人人都是産品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于 CC0 協定。