1 背景介紹

1.1 背景介紹

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

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

1.2 概念介紹

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

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

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

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

1.3 本文收銀臺的定義

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

2 場景問題

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

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

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

問題2：用戶支付了嗎？

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

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

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

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

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

3 收銀臺功能介紹

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

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

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

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

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

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

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

4 三方產品能力介紹

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

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

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

5 收銀臺實現(xiàn)邏輯和架構

5.1 邏輯交互流程

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

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

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

5.2 支付中心技術架構

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

5.3 收銀臺收款配置規(guī)則引擎介紹

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

• 定義業(yè)務規(guī)則

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

• 定義場景規(guī)則

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

目前的規(guī)則引擎還沒有支持低代碼的方式，這也是我們后續(xù)的一個優(yōu)化方向。

5.4 海量數(shù)據(jù)的解決方案

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

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

6 場景問題回顧

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

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

問題2：用戶支付了嗎？

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

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

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

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

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

關于作者

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