蘭亭妙微UI設計公司:
先看一個”付款報錯”的現場
時間：新店鋪支付模塊上線第二天，早上 10 點。
小A 正在工位上喝咖啡，客服群突然開始連環炸：
用戶A： “我付完錢了，訂單怎么還顯示’待支付’？”
用戶B： “我明明沒付成功，為什么錢被扣了？”
用戶C： “我取消了訂單，錢什么時候退給我？”
小A 趕緊打開后臺一看，傻眼了——
同一批訂單里，“待支付”“支付中”“已支付”“支付失敗”“已退款”五種狀態交叉打架，有的訂單同時出現在”待支付”列表和”已支付”列表里，還有幾筆訂單錢已經進了商戶賬戶、但訂單狀態還停在“支付中”。
她翻出前一天熬夜畫的支付鏈路時序圖，越看越冷汗：
- 根本沒畫狀態機——訂單狀態和支付狀態揉在同一張表里，一個字段搞定一切；
- 只做了同步跳轉——支付結果全靠前端跳回來調一次接口，沒做異步回調；
- 沒做冪等——用戶多點幾次”確認支付”，就出現了重復扣款；
- 沒有主動查詢兜底——只要微信/支付寶的回調丟一次，訂單就永遠”支付中”。
小A 硬著頭皮撥通了老張的電話。
老張聽完小A 的描述，只回了一句：
“你這不是‘支付接口寫錯了’，是把支付當成了一個動作。它不是一個動作，是一條鏈路——而鏈路的地基，就是三件事。”
接著老張發來一段話，小A 把它存成了備忘：
做支付產品，要先分清三件事——
一、交易流：用戶 → 訂單；
二、資金流：錢 → 賬戶；
三、信息流：狀態 → 系統同步。
這三條流在理想情況下一一對應，但在真實生產環境里，它們永遠會錯位。你的產品工作，就是把這些錯位“兜回來”。
先澄清兩個認知
在正式拆關之前，先澄清兩個小A 一開始就搞混的認知——也是 90% 新手都會栽的坑：
認知一：支付不是”一個接口”，是”一條鏈路”
很多人以為”接入微信支付”= 調一個 API。錯。一次完整的支付涉及 7 個系統 + 2 個異步回調 + N 個狀態流轉。后面關卡二會展開。
認知二：訂單狀態機 ≠ 支付狀態機
訂單篇講過訂單狀態機，但訂單狀態 ≠ 支付狀態。一個訂單”已支付”不代表錢真到賬了，可能只是”支付成功回調到了”。這兩個狀態機必須分開設計、雙軌管理。后面關卡三會展開。
上篇拆 3 道關 · 先把”地基”打穩
支付結算整套完整拆解要過 7 道關卡，上下篇分開講：
上篇（本篇）· 地基三關 —— 錢怎么進來
第 1 關 · 支付方式全景 —— 用戶能用什么付錢
第 2 關 · 支付鏈路 —— 點“付款”之后發生了什么
第 3 關 · 支付狀態機 —— 錢到底在哪一步
下篇 · 進階四關 —— 錢怎么不出事
第 4 關 · 對賬 —— 財務最怕出事的環節
第 5 關 · 分賬 —— 多方分錢怎么分
第 6 關 · 退款 —— 錢怎么原路退回
第 7 關 · 異常資金池 —— 最后一道防線
上篇講完，你可以獨立設計一個“能把錢收進來”的支付系統；下篇講完，才能做到”錢進來之后不出事”。
第一關：支付方式全景圖——用戶能用什么付錢
小A 的第一個反問：“不就是微信、支付寶、銀行卡嗎？”
老張笑：“電商平臺的收銀臺里，平均要接 12-18 種支付方式。你要是只知道三種，寫出來的 PRD 就只能支撐一個最小 MVP。”
為什么支付方式這么多
每一種支付方式的存在，都對應著某個特定場景下用戶最低阻力的選擇：
- 用戶買 9.9 元的小商品 → 愿意用微信（免密）
- 用戶買 999 元的家電 → 愿意用花唄（分期）
- 用戶做跨境代購 → 只能用 PayPal 或境外卡
- 用戶在門店自提 → 愿意刷 POS（現場核銷）
- 企業采購 → 要求對公轉賬開發票
產品經理的第一課：不是選“最好的支付方式”，是覆蓋“用戶觸達時的最低阻力路徑”。
按資金流向分類
每種支付方式的產品要點
產品決策：選支付方式的 3 個原則
原則一：用戶畫像優先
品牌 X 的數據：
- 30 歲以下用戶 → 70% 用微信支付
- 40 歲以上用戶 → 50% 用支付寶
- 高客單（>1000 元）→ 35% 選花唄分期
- 跨境商品 → 必須接 PayPal 和境外卡
如果不接花唄，高客單商品轉化率會下降 15-20%。
原則二：費率與到賬時效平衡
原則三：接入成本要控制
每接一種支付方式 = 一套對接 + 一套回調 + 一套對賬 + 一套退款。不要盲目追求“支付方式最全”，要評估 ROI。
第二關：支付鏈路——點”付款”之后發生了什么
小A 的第二個反問：“不就是前端調個 API 嘛？”
老張說：“這也是你整天對不上賬的根因——你以為支付是一個動作，它其實是一條鏈路。”
7 個系統跳數（完整時序圖）
從用戶點擊”立即支付”按鈕，到最終”錢到賬”，一筆支付要經過 7 個系統角色 × 2 次異步回調：
7 個跳數的產品要點
為什么第 10 步最容易出事
三個真實事故（品牌 X 上月發生）：
- 回調丟失（網絡抖動）：三方發了通知，訂單系統沒收到。訂單狀態還停在”支付中”，用戶付了錢訂單沒更新。
- 回調延遲（支付系統擁堵）：訂單系統等了 35 分鐘才收到回調，但訂單已因支付超時自動取消，結果”錢后到賬”，變成異常資金。
- 重復回調（三方重試策略）：三方 3 秒內發了 3 次回調，訂單系統沒做冪等，把庫存扣了 3 次，用戶收到 3 條短信。
這三個事故的解法都寫在訂單篇下篇“支付三道防線”里——但真正在支付結算模塊里實現的，是這些：
支付鏈路兜底設計
防線一：被動回調 + 主動查詢雙保險
– 三方通知到 → 立即更新（最快路徑）
– 超過 30 秒沒通知 → 訂單系統主動反查一次
– 每 30 秒主動查詢，最多查 10 次（共 5 分鐘）
– 任一次成功即完成支付閉環
防線二：全鏈路冪等
– 支付單號（而非訂單號）作為冪等鍵
– 同一支付單號的任何操作（成功通知/失敗通知/查詢響應）都要冪等
– 重復請求的返回值必須和第一次請求一致
防線三：異常資金池
– 所有”錢進賬但找不到訂單”或”訂單已取消但錢到了”的交易，進入異常池
– 72 小時內必須處理完：原路退回 / 人工對賬 / 轉公司應付賬款
– 詳見關卡七
一個產品小心機
為什么用戶看到的是“支付中”而不是“支付成功”？
答：因為用戶點擊的一刻，錢還沒扣。扣款發生在第 8 步，那時用戶可能已經退出 App 了。
好的設計：
- 用戶點擊 → 顯示“支付中”
- App 輪詢訂單系統（5 秒一次）
- 一旦訂單系統收到第 10 步回調 → 推送給 App → 顯示“支付成功”
壞的設計（小A 第一版設計）：
- 用戶點擊 → 直接顯示“支付成功”（基于樂觀假設）
- 結果第 10 步回調失敗 → 訂單實際沒支付成功 → 用戶以為付款了但系統里是“待支付” → 客訴
第三關：支付狀態機——錢到底在哪一步
小A 的第三個反問：“訂單狀態機不就夠了嗎？為什么還要單獨的支付狀態機？”
老張說：“訂單關心的是‘貨的進度’，支付關心的是‘錢的進度’。這兩件事在 80% 的時間里是同步的，但在 20% 的異常時刻會錯位——而恰恰是那 20% 決定了你的產品水平。”
支付狀態全集
一筆完整的支付，在產品設計上至少要覆蓋 8 種狀態：
8 種狀態說明
+ 1 個兜底狀態：異常資金 — 第 7 關展開。
訂單狀態機 × 支付狀態機：映射矩陣
這是小A 在第一版 PRD 里漏掉的——她只設計了訂單狀態機，沒有獨立的支付狀態機，結果”訂單已支付”和”支付成功”混在一起，對賬時根本拆不清。
矩陣的價值：
- 綠色（? 合法）：組合成立，不用管
- 紅色（— 非法）：組合不該發生，PRD 里必須明確”不可進入”
- 橙色（? 異常）：組合可能發生但不合理，是產品必須設計兜底的地方
小A 上月踩的坑——“已取消 + 已支付”組合（矩陣右下橙色加粗格）：
訂單被超時取消，但支付回調 30 分鐘后才到。結果訂單是”已取消”，支付是”已支付”。這筆錢就掛在了系統里，進入異常資金池。
解法（關卡七深度展開）：
- 檢測到“訂單已取消 + 支付已到賬” → 立即進入異常池
- 系統自動判斷：補單（讓訂單從“已取消”恢復為“已支付”）或原路退款
- 72 小時內必須閉環
支付狀態機的 3 條鐵律
鐵律一：訂單狀態由支付狀態驅動
很多新手 PRD 的錯誤寫法：
“用戶支付成功后，把訂單狀態改為’已支付’。”
這句話邏輯上沒問題，但在系統層面是反的。正確的是：
“支付狀態機從’支付中’流轉到’已支付’時，觸發訂單狀態機從’待支付’流轉到’已支付’。”
區別在于：支付狀態是因，訂單狀態是果。如果把它們耦合在一個狀態機里，就做不到獨立兜底。
鐵律二：所有狀態變更必須帶“來源”
字段設計：
payment_status_log:
– payment_id: 支付單號
– from_status: 變更前狀態
– to_status: 變更后狀態
– source: 變更來源（user / system / callback / reconcile / manual）
– operator: 操作人（用戶ID / 系統名 / 財務人員）
– timestamp: 變更時間
– remark: 備注（必填）
為什么必須帶來源？因為財務對賬、客訴排查、合規審計，三個場景都要追溯“是誰讓它變成這個狀態的”。
鐵律三：每個異常態都要有退出通道
支付狀態機里最容易出事的”死狀態”：
- 支付中 → 過了 1 小時還沒收到回調：要么主動查詢、要么超時關閉
- 部分支付 → 另一通道長時間未到賬：要么回滾已到賬部分、要么提示用戶繼續
- 異常資金 → 不能永久卡在這里，72 小時內必須處理
任何狀態都要有“進入規則 + 退出規則”，不能只有進入沒有退出。
一個小A 踩過的典型坑
場景：品牌 X 上線”組合支付”，允許用戶用”積分 + 微信”支付。
小A 第一版設計：
- 積分扣減成功 → 訂單狀態“已支付”
- 微信支付再進行
問題：積分成功了但微信支付失敗，訂單狀態已經是”已支付”但實際只支付了積分部分。
正確設計：
- 積分扣減成功 → 訂單狀態“部分支付”
- 微信支付成功 → 訂單狀態“已支付”
- 微信支付失敗 → 回滾積分扣減 → 訂單狀態“待支付”
關鍵：組合支付必須有“部分支付”這個中間態，而不是每個支付通道成功就是”已支付”。
自查清單：你的支付地基穩不穩
訂單篇問的是“訂單系統扎不扎實”和“抗不抗壓”，支付篇上篇先問一件事：地基穩不穩。能答對 3 題以上的，才好進下篇的對賬、分賬、退款、異常資金池。
支付地基（4 題）
1. 所有支付通道都有“被動回調 + 主動查詢”雙保險嗎？ 只靠被動回調=錢進賬但訂單沒更新
2. 所有支付接口都做了冪等嗎？ 用”支付單號”做冪等鍵，不是訂單號——重復回調必須識別出來
3. 訂單狀態機和支付狀態機是獨立的嗎？ 而不是一個字段 status 揉完訂單和支付
4. 支付方式的接入是按“用戶畫像 × 客單價 × 資金成本”選的嗎？ 還是上來先接個微信和支付寶了事
總結：上篇 · 6 條支付地基認知
一句話總結上篇： 支付系統的地基，不是”接完三個通道就完事”，而是把一條鏈路、一張雙軌狀態機、一套兜底與冪等，都提前畫清楚。地基穩了，下篇才有資格談”能扛”。
蘭亭妙微（藍藍設計）m.payeee.cn 是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的大數據可視化界面設計、B端界面設計、桌面端界面設計、APP界面設計、圖標定制、用戶體驗設計、交互設計、UI咨詢、高端網站設計、平面設計，以及相關的軟件開發服務，咨詢電話：01063334945。
