支付流程設(shè)計常見問題及最佳實(shí)踐

作者：隱墨星辰 2025-01-09 11:58:19

如果對支付系統(tǒng)設(shè)計與實(shí)現(xiàn)感興趣，可以看看公眾號的其它文章，就四個字：好評如潮。如果翻了一圈后不滿意，覺得浪費(fèi)了你的時間，加我微信，給你發(fā)個大紅包表示歉意和補(bǔ)償。

大家好，我是隱墨星辰，專注境內(nèi)/跨境支付架構(gòu)設(shè)計十余年。今天聊一下支付流程設(shè)計的一些常見總是及最佳實(shí)踐，包括：

組合支付要不要拆支付流水，前端輪詢查哪個域，查詢要不要穿透到外部渠道，為什么要做同步受理異步處理，支付補(bǔ)償怎么做，如何防重復(fù)支付，萬一重復(fù)支付了怎么做，支付成功后用戶關(guān)單了怎么做，返回碼怎么映射，支付要不要做系統(tǒng)自動重試，支付渠道如何做隔離，支付資損防控怎么做，支付路由怎么做。

問題來源于一個討論，回答也是五花八門。

圖片

組合支付要不要拆支付流水

當(dāng)然拆。不拆能不能做？也是可以做，但是壞處很多。有更優(yōu)解的情況下，我們要選擇更優(yōu)解。

每一種支付方式都有自己的特性，包括但不限于支付金額、支付時間、狀態(tài)等，如果放在一筆支付單，如何表達(dá)得清楚？

這里還有一個分層的概念，就是面向商戶的是收單域，生成的是交易單，交易單下面可以掛一個主支付單，這個支付單是支付域的，一個支付單下面掛多個支付流水，一個支付方式就生成一筆支付流水。

由支付域來負(fù)責(zé)多個支付方式的組合，以及主支付單的推進(jìn)。

圖片

前端輪詢查哪個域

有人查收單域，有人查支付域。

我的觀點(diǎn)是查收單域。因?yàn)槭諉问轻槍ι虘舻模虘舻挠唵纬晒α耍潘愠晒ΑＳ袝r候可能內(nèi)部出現(xiàn)故障，導(dǎo)致支付域成功但收單域沒有成功，還有可能訂單因?yàn)槌瑫r或用戶主動操作已經(jīng)關(guān)閉，這個時候支付域哪怕成功，也需要給用戶退回去。

如果是用戶充值，就以資金產(chǎn)品域?yàn)闇?zhǔn)。

為避免對收單域的數(shù)據(jù)庫造成過大壓力，建議加一層緩存。

標(biāo)準(zhǔn)收銀臺和前置收銀臺又有一點(diǎn)不一樣。上面說的是前置收銀臺的情況。

查詢要不要穿透到外部渠道

很多人喜歡直接把查詢穿透到外部渠道，比如用戶提交支付后，在收銀臺頁面轉(zhuǎn)菊花，收銀臺頁面會有一個定時任務(wù)高頻查詢后端的支付結(jié)果，這個查詢請求鏈路：收銀臺頁面->收銀臺后端->收單域->支付域->渠道網(wǎng)關(guān)域->外部渠道。

如果一旦網(wǎng)絡(luò)抖動或外部渠道抽風(fēng)，返回耗時增加，就會快速把內(nèi)部應(yīng)用的線程全部耗盡，極易引發(fā)雪崩。有興趣的可以翻翻公眾號前段時間發(fā)布的關(guān)于雪崩的超級故障。

正確的做法：

收銀臺只查自己的緩存，支付域有新數(shù)據(jù)后，更新到緩存，比如支付成功，或者需要跳到核身驗(yàn)證頁面。

圖片

為什么要做同步受理異步處理

原理和上面的查詢不要穿透到外部渠道是一個道理，如果一旦網(wǎng)絡(luò)抖動或外部渠道抽風(fēng)，返回耗時增加，就會快速把內(nèi)部應(yīng)用的線程全部耗盡，極易引發(fā)雪崩。

正確的做法：同步受理商戶的請求后，馬上返回給商戶，然后再異步處理，發(fā)送給渠道。

是不是每個域都做同步受理異步處理？也不是，那樣就太復(fù)雜了。

可以選擇在收單域做，也可以選擇在渠道網(wǎng)關(guān)域做。推薦在渠道網(wǎng)關(guān)域做，因?yàn)橥獠壳赖暮臅r最不可控，大不了多部署幾臺網(wǎng)關(guān)，多開些線程。還有一個情況，比如只需要扣余額，那就直接毫秒級扣完返回給商戶，簡單實(shí)用。

如果一定要選擇所有域都做，那也是個人的自由。但強(qiáng)烈不建議全部同步調(diào)用出去。

圖片

支付狀態(tài)補(bǔ)償怎么做

支付發(fā)出后，有四種情況可以獲得支付的結(jié)果：

渠道接口實(shí)時返回渠道處理的結(jié)果。
渠道異步通知支付平臺。
支付平臺使用定時任務(wù)梯度時間查詢渠道支付結(jié)果。
拿到渠道對賬文件。

時效性而言，依次遞減，但也不是絕對的，有時候會出現(xiàn)渠道異步通知比接口實(shí)時返回還要快。這個時候一定要設(shè)計好狀態(tài)機(jī)，否則很容易出現(xiàn)異步結(jié)果已經(jīng)推進(jìn)成功，實(shí)時接口又推進(jìn)到支付中。具體可以看看公眾號以前的發(fā)文：狀態(tài)機(jī)設(shè)計與最佳實(shí)踐。

定時查詢查詢一定要用梯度，一方面減少自己平臺和渠道壓力，同時又能獲得最好的時效性，比如間隔時間：1秒，2秒，5秒，10秒，20秒，40秒，100秒 ... ... 查到n次就不查了。再查下去也沒有意義，就等渠道文件對賬好了。如果渠道的對賬文件是支付成功，但是平臺支付已經(jīng)關(guān)閉訂單，那就走差錯給用戶退回去就好。

如何防重復(fù)支付

重復(fù)支付在很多公司都出現(xiàn)過，強(qiáng)大如支付寶，也時不時爆出大批量的重復(fù)支付。

首先是接口要有冪等設(shè)計。冪等的設(shè)計也有很多種方式，有人喜歡使用redis分布式鎖，我個人是反對的，起碼也要使用數(shù)據(jù)庫唯一索引。單機(jī)房使用唯一索引就夠，如果全球多活怎么辦？還得有一個全局冪等組件。具體怎么設(shè)計，可以在公眾號里找下：支付冪等設(shè)計與最佳實(shí)踐。

但是，冪等設(shè)計是基于商戶不換號的情況下，如果商戶換號重發(fā)，就防不住，怎么辦？最好是基于用戶的維度做個判斷，比如同一個用戶，在短時間（比如1分鐘），已經(jīng)存在相同金額的支付單，就給用戶提示：“當(dāng)前已經(jīng)有一筆xx金額的訂單，是否仍然支付？”。雖然不能完全避免，但是可以減少。

萬一重復(fù)支付了怎么做

前面有提出防重復(fù)支付，但是萬一真出現(xiàn)重復(fù)支付了怎么辦？

沒有什么好辦法，原路退回就是。

這也是我們?yōu)槭裁丛谇懊姘呀灰讍魏椭Ц秵螀^(qū)分出來的原因。各是各的單，出現(xiàn)問題好處理。

還有一個問題，如何發(fā)現(xiàn)內(nèi)部有大批量的重復(fù)支付？總不能全部等客訴吧？后面有時間再聊聊支付平臺內(nèi)部多域之間實(shí)時兩兩對賬。

支付成功后用戶關(guān)單了怎么做

不僅是重復(fù)支付后需要原路退回，如果渠道扣款成功，但是我們的訂單已經(jīng)關(guān)閉（超期關(guān)閉，用戶主動關(guān)閉等），都需要做原路退回。

這里還可以引申出另外一個問題，為什么記賬的時候，有一個“商戶待結(jié)算戶：，還有一個“支付網(wǎng)關(guān)過渡戶”。如果沒有支付網(wǎng)關(guān)過渡戶，支付成功，錢直接到了商戶待結(jié)算戶，但是如果收單域的訂單已經(jīng)關(guān)閉，這筆錢就不應(yīng)該進(jìn)入到商戶待結(jié)算戶里去，而是應(yīng)該直接從支付網(wǎng)關(guān)過渡戶給用戶退回去。