支付方式選擇
在收銀臺設計前，根據業務類型要對支付方式進行選擇，目前常見的收銀臺支付類型包含兩種：
收單：通過各類支付方式針對業務訂單發起付款。例如：C 端用戶在天貓購買一件衣服，點擊「提交訂單」後，系統跳轉至支付寶進行付款。這是標準的付款場景，也稱之爲收單。
充值：用戶對賬戶進行餘額充值。例如：C 端要用戶登錄支付寶等商戶自有的錢包系統對賬戶進行餘額充值。這是標準的充值場景。
業務流程及系統流程
1. 充值業務
①業務流程
用戶對錢包賬戶發起充值；
跳轉至收銀臺，根據展現的支付方式用戶選擇充值渠道（若該充值業務允許提現，收銀臺應根據充值業務配置對應的借記渠道，從業務側規避用戶使用信用卡充值做信用卡套現）；
充值成功後返回。
②系統流程
用戶在客戶端發起充值流程，客戶端獲取收銀臺地址，收銀臺返回地址；
收銀臺根據請求類型跳轉至收銀臺充值頁面，顯示對應的充值渠道；
用戶選擇對應的充值渠道後，收銀臺提交對應的充值訂單到交易系統；
交易系統通過支付核心轉化後給到清算核心，獲取對應的支付渠道信息，返回給收銀臺；
收銀臺跳轉支付渠道，用戶在第三方支付頁面進行支付；
支付結果以異步形式通知服務端，前臺根據 return_url展示對應的充值結果頁面。
2. 收單業務
①業務流程
用戶在業務端基於訂單發起付款，跳轉至收銀臺後選擇支付渠道；
根據用戶選擇的支付方式決定後續流程：
餘額支付：首先校驗餘額是否充足，若充足則用戶可選擇餘額進行全額付款；確認付款後輸入支付密碼並校驗支付密碼是否正確，若正確則扣減餘額，完成支付；
網銀或第三方支付：首先根據業務確定可使用的支付渠道列表，其次用戶選擇第三方支付後，調用第三方支付渠道發起付款，渠道限額校驗由第三方完成，最後根據支付結果變更支付狀態（正常情況下除了支付成功意外均以「處理中」做業務狀態處理）。
②系統流程
業務系統調用支付系統做業務下單，形成對應的入款交易訂單，並跳轉收銀臺；根據交易請求判斷是否返回收銀臺（有部分業業務場景指定支付方式或以確認性付款成功等流程無需收銀臺）；
獲取到收銀臺地址後，打開收銀臺界面，獲取渠道列表並展示對應渠道；
用戶選擇支付方式，支付請求發送到清算核心，調用第三方支付渠道；
收銀臺跳轉到對應支付渠道，用戶在第三方支付頁面進行付款；
支付結果以異步形式通知服務端，前臺根據 return_url 返回對應頁面。
組合支付
組合支付即通過一種以上支付渠道完成付款的支付形式。組合支付是交易系統中提供的一種交易服務類型，例如早期支付寶有組合支付功能，最常見的組合支付類型爲「賬戶餘額 + 快捷支付」模式，此種類型可在做支付系統設計時進行借鑑，可實現「賬戶餘額 + 第三方支付」的模式。
組合支付的衍生需求很好理解，當用戶在平臺的錢包賬戶內進行充值後，若想購買的商品價格超出了賬戶餘額的可支付範圍，即可使用組合支付的方式進行付款；此處的賬戶餘額可理解爲「廣義範圍內，所有涉及到支付系統內部清結算能力的支付形式」，凡是需要與其他渠道進行組合付款的場景均可使用組合支付的邏輯，例如基於營銷設計的紅包、代金券、積分以及預付卡等。
組合支付的流程、設計
1. 組合支付的流程
①餘額 + 第三方（支付成功）
用戶發起組合支付，支付前置根據用戶組合支付的行爲生成組合支付業務訂單；
支付前置系統根據系統配置的付款順序對組合支付進行推進，由內部渠道和外部渠道進行的組合支付：原則上需要先調用外部渠道，因此支付前置基於組合支付訂單生成了一筆第三方支付的子訂單，也可以稱爲支付指令；待支付成功後，通知內部賬戶系統扣減賬戶餘額，這樣避免外部渠道不成功的情況下對餘額進行了先行扣除；
外部渠道成功後通知前置系統，前置系統此時生成當筆內部餘額扣減的支付指令並調用支付核心系統；核心系統返回成功後，將這比組合支付的業務訂單置爲成功並通知業務端。
②餘額 + 第三方（支付失敗）
③組合支付設計
組合支付本身對於交易系統來說差別不大，僅在訂單發送至支付前置時，由於邏輯上來講是兩筆付款行爲，因此會生成兩條支付方式的請求：一條爲餘額支付請求，一條爲第三方支付請求；轉換到支付前置後，前置系統生成一筆組合支付的訂單，且對應着兩條支付指令（一條充值、一條轉賬），當充值的指令成功後去執行轉賬的指令，兩筆都成功的情況下則通知上層系統變更業務狀態。
定義支付業務類型：組合；
對應指令：根據外部加內部的組合，根據具體指令需執行的原子類型，生成對應指令訂單，遵循外部成功後再執行內部的流程；
支付方式：以組合種類爲準，對應種類在網關傳遞交易時進行拆分，例如代金券 + 餘額 + 第三方支付則需要分別定義三條支付方式信息。
優惠支付
優惠支付即基於支付系統的代金券、優惠券、紅包等營銷支付流程設計，本質上是基於賬戶做的營銷支付體系，無論具體優惠形式，在支付系統內部都是以賬戶形式存在：例如代金券營銷賬戶、優惠券營銷賬戶等；根據具體的業務需求，支付系統對於此類營銷支付在賬戶層面應設計兩種方案：
平臺側營銷賬戶：代金券營銷賬戶、優惠券營銷賬戶等，其營銷成本應從這兩個賬戶中進行扣減，賬戶需自行預先充值，用戶支付時所需部分抵扣的金額從該賬戶進行獲取；
用戶側營銷賬戶：紅包、消費積分等營銷賬戶與各個用戶一一對應，用戶在領取時視爲開通了紅包等營銷賬戶；每當領取紅包或獲取消費積分，視爲賬戶金額增加（相當於給用戶的賬戶進行充值入賬）。此外，也可以通過業務端對明細賬戶加以控制，支付系統則去維護總賬戶即可。
營銷支付設計
營銷支付的設計可分爲基於業務端做營銷和基於支付端做營銷兩個方向：
基於業務端做營銷：在業務平臺直接對優惠券金額進行扣除。
調用支付系統前，業務系統根據優惠方式（立減、折扣或優惠券等）對可優惠金額完成計算並直接扣減調；
調用支付系統，並將用戶實際待支付金額轉入支付系統並生成支付訂單。
此方法的弊端在於，若平臺型電商對營銷成本進行結算，僅可通過線下或其他方式完成與商戶間的結算工作，會增加財務工作量並造成賬務不清晰等結果。
基於支付端做營銷：可分爲平臺側與用戶側兩部分。
（1）平臺側：
將平臺的優惠補貼金額通過內部戶等形式存儲在賬戶系統當中，類似「營銷補貼戶」；
用戶在前端發起支付時，使用優惠券、紅包、消費積分等營銷工具抵扣部分金額，業務平臺調用支付系統下單並傳入總金額、支付金額以及抵扣金額等相關信息，根據總金額生成交易訂單後，根據總金額的構成生成對應的支付訂單；實際支付金額與用戶待付款的支付訂單相對應，抵扣金額爲平臺內部賬戶單獨的內部流轉支付訂單，通過用戶實際成功支付的消息進行後續處理；
此類方法的優勢在於將每個用戶的業務明細留存在業務平臺系統處理，支付系統只需要記錄金額；收銀臺調用支付平臺下單相關參數：業務平臺訂單號、UID、總金額、抵扣金額、支付金額、支付方式。
（2）用戶側：
當前電商平臺有部分營銷產品擁有較強的用戶屬性，例如紅包、消費積分等，此類自帶貨幣屬性的虛擬賬戶餘額，根據其業務屬性對支付系統中的每位用戶單獨開設補貼賬戶，支付時根據營銷賬戶 + 其他支付方式進行組合，與組合支付的邏輯相類似，一筆付款付多個付款渠道。
《支付系統設計白皮書》由 PingPlusPlus支付學院（ID：pingxxpi）出品。