1 背景介紹

1.1 背景介紹

收銀臺的名字起的很好，見文知意，且現實生活有對應的實物映射，很好理解。我們在超市購物的最后一步就是用購物車推著選中的物品，去收銀臺結賬。收銀員逐個商品掃碼，系統根據會員身份、會員等級、活動促銷情況計算出用戶需要付款的價格，用戶選擇電子支付或者現金支付最終完成整個購物過程。

在線支付已經像是空氣和水一樣，融入了我們的生活。但是在這個過程的背后有哪些流程和邏輯，怎么保證用戶和公司的資金安全？怎么高效穩定的支持運營策略？錢是怎么收過來的，以及怎么收到哪里？我們希望通過解決這些疑問來和大家一起了解一下收銀臺的邏輯。

1.2 概念介紹

收單：收是從平臺視角的收，是指完成向用戶收款的整個過程。

提現：用戶把自己在轉轉的余額提現到微信、支付寶等三方余額的過程。

打款：向用戶支付一筆錢，錢從一個轉轉賬戶轉移到用戶的轉轉賬戶，通常意義的打款是包括提現的。

三方：這里的三方是在用戶向轉轉付款時，微信、支付寶等第三方公司的代指。

1.3 本文收銀臺的定義

在購物網站中，提供給用戶選擇付款方式的頁面，并且能支持用戶完成付款整個過程。下面的圖示是簡化的轉轉用戶購買商品的幾個環節，我們可以大概了解收銀臺在整個交易環節所處的位置（點擊可大圖瀏覽）。

2 場景問題

在正式介紹收銀臺邏輯和架構之前，我們先討論一些場景，以及思考一下這些場景會有什么問題，怎么解決。

問題1：把錢付給誰，怎么付？

傳統購物的時候，我們是一手交錢一手交貨，把現金給賣家即可，不存在類似把錢給誰這樣的問題，在超市購物展示付款碼的時候，收銀臺使用掃碼槍直接掃碼收款，我們也不用關心把錢給了誰，因為整個過程都有賣買雙方面對面在場。但是在電子支付的過程中，如果買家付款了，賣家說沒收到，這種場景怎么辦？

問題2：用戶支付了嗎？

和上面的問題類似，用戶在沒有支付的情況下，說自己付款了，這種情況怎么辦？

問題3：篡改交易金額怎么辦？

這個問題比較常見了，有意的無心的都有，電子的現金的也都有。在網上我們也見過的類似的新聞【錯把密碼當金額，長沙一男子打車支付 2.6 萬元】。那么這個問題在電商購物過程中是否存在以及怎么解決呢？

問題4：重復支付怎么處理？

假設用戶 A 要購買一部 99 新的 iPhone14，商品優惠后價格是 4000 元，用戶打開支付寶后又使用微信支付，使用微信支付完畢之后莫名其妙打開支付寶又進行了付款(不要質疑這個案例的真實性，相信我這不是個例，而且會有比這更難理解的案例)。那么這種情況應該怎么處理？

3 收銀臺功能介紹

上面的疑問我們先按下不表，大家可以繼續思考，我們介紹一下轉轉收銀臺的樣式和功能

上圖是轉轉 APP 內用戶常見的收銀臺樣式，除了 APP 內的收銀臺，我們還支持微信小程序、支付寶小程序、PC 頁面（如下圖）的收款。

收銀臺是用戶開始支付的重要環節，用戶從挑選商品到進入收銀臺此時的下單意愿很強烈，所以我們要給用戶盡量好的體驗和盡量多的選擇。比如：我們支持用戶使用微信、支付寶、分期、京東以及組合支付等。

我們可以看到收銀臺上面的核心元素有：

• 需要支付的價格
• 可以選擇的支付方式

這些是用戶能直接感受到的，還有些是用戶感受不到的部分：

• 不同的環境（安卓、IOS、小程序、PC），不同的版本（9.0 版本與 10.0 版本）提供的支付方式是有區別的
• 用戶支付時實際收款的公司賬戶不唯一
• 不同的用戶、不同的商品在信用卡使用策略不同
• 內部有哪些單據，又是怎么同三方交互的
• 支付環節異常情況處理

4 三方產品能力介紹

我們向用戶收款是需要借助三方支付公司的，所以必須了解一下三方支付公司有哪些能力和交互提供給我們，故在此簡單介紹一下，詳細內容可以在三方支付公司官網了解。

1 不同的環境需要使用不同的支付產品，比如：在集成了三方支付公司的 SDK 之后，可以使用 APP 支付，對應的交互更安全。特別注意：不同的支付產品需要分別開通

2 我們可以通過參數控制用戶能夠使用的支付方式：余額、儲蓄卡、花唄、信用卡等。

5 收銀臺實現邏輯和架構

5.1 邏輯交互流程

這里使用幾個流程圖來介紹我們整體的交互和內部的邏輯。

從支付中心視角看整個支付下單過程的時序交互圖如下：

收銀臺內部部分細節說明流程圖如下：

5.2 支付中心技術架構

通過上面的介紹，我們對收銀臺已經有了基本的認識和了解，在實際的運行中也會有各種各樣的問題和解決方案，下面分享幾個技術方面的細節。

5.3 收銀臺收款配置規則引擎介紹

收銀臺設計初期就是支持不同環境不同業務可以有不同的收款方式和不同的三方產品的，而且隨著公司發展業務線也會越來越多，而且也會出現更多維度支持的需求，比如不同版本支持不同的支付產品等等。而這些業務規則不適合寫在代碼內（你要是非要寫一堆 if else 我相信你也是可以滿足需求的），在代碼邏輯和業務代碼面臨錯綜復雜難舍難分的風險面前，我們選擇使用規則引擎Easy Rules來解決我們收銀臺路由的問題。

• 定義業務規則

一個規則包括以下幾個部分：名字、描述、優先級、校驗匹配邏輯、匹配成功邏輯、匹配失敗邏輯等等 我們的業務規則主要有以下元素：業務信息、賣方信息

• 定義場景規則

場景規則包括：業務規則、終端信息、版本信息、可用付款方式集合 這樣我們通過使用規則引擎，避免在代碼冗余太多的業務邏輯判斷，也便于擴展。相對完整的收銀臺路由規則見下圖

目前的規則引擎還沒有支持低代碼的方式，這也是我們后續的一個優化方向。

5.4 海量數據的解決方案

隨著數據規模的增長，我們也會遇到很多來自海量數據的問題，目前轉轉僅支付相關的核心表就已達到十億級數據量，單表存儲幾乎是不可能的。目前比較通用的解決辦法有分庫分表或冷熱庫。其中分庫分表又分為水平分和垂直分等等。在此我們簡單對比一下兩種方式的優缺點和適應的場景。

針對支付場景的特點：數據修改不頻繁、超過3個月的數據很少再次使用、比較依賴事務。我們選擇的解決方式是冷熱庫的方式，其中冷庫使用的是分布式數據庫 TIDB，擴展性和存儲支持的比較好，語法命令和 MySQL 兼容。對于已經進入冷庫需要再次修改的數據，我們通過程序代碼進行回填數據兼容。

6 場景問題回顧

問題1：把錢付給誰，怎么付？

用戶在支付時，支付系統內部會根據支付信息和業務配置，獲取需要收款三方賬戶，并且使用賬戶的證書密鑰等信息向三方創建支付單。

問題2：用戶支付了嗎？

當收付雙方對交易存在爭議的時候，可以根據交易流水號在三方平臺查詢。

問題3：篡改交易金額怎么辦？

系統在創建支付單的時候會同步設置需要支付的金額，這個過程不需要用戶主動輸入金額，自然也沒有篡改交易金額的問題。

問題4：重復支付怎么處理？

系統在收到三方支付成功的回調之后，會再次和三方查詢確認。如果對應的支付單已經有不同的支付成功信息，會進行退款處理。

關于作者

張一鳴，轉轉支付后端研發，曾夢見仗劍走天涯，后來五公里都很少跑了。