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