穩定幣少付、多付或發錯網路：如何處理支付不匹配

客戶說已經付款，發來交易雜湊，而且區塊瀏覽器裡確實能看到轉帳，但你的訂單仍停留在 created。這不一定是掃描故障。轉帳可能真實存在，卻沒有滿足付款指令：金額可能少了或多了，資產或網路可能選錯了，也可能在訂單過期後才到帳。

安全原則很簡單：不要靠猜測把一筆“看起來差不多”的轉帳認定為已付款。訂單仍有效時，鏈、資產、收款地址和金額必須全部精確匹配。其他轉帳一律留在自動履約路徑之外，根據鏈上證據調查，再按成文的退款、補收或人工入帳規則處理。在非託管系統中，到達商戶地址的資金仍由商戶控制；嚴格匹配阻止的是含糊履約，並不妨礙商戶找回資金。

如果目前做法是把裸錢包地址發給客戶，可以先用穩定幣付款連結把網路、資產、精確金額、有效期和訂單狀態放進同一個結帳流程，減少可以預防的錯付。

為什麼少付後訂單仍未完成

付款指令是一組完整條件，而不是參考建議：

付款訂單
  鏈 + 資產 + 收款地址 + 精確金額 + 過期時間
                              |
                              v
觀察到轉帳 -------- 訂單為 created 且精確匹配？--------------- 是
                              |                            |
                              否                           v
                              |                 payment.detected
                              v                            |
                     未匹配鏈上事件              confirmed -> finalized
                              |
                              v
                    人工核對；訂單隨後過期

StableOps 會按代幣精度把金額換算成最小單位後比較。對於 10.00 的訂單，9.99 和 10.01 都不匹配；先後兩筆 6.00 和 4.00 也不會自動合併成一次精確付款。共享收款地址尤其需要這條規則：如果允許“差不多”或任意合併轉帳，系統就可能把一位客戶的資金分配給另一位客戶的訂單。

完整的匹配邊界如下：

任意一項不匹配，StableOps 都不會為該訂單傳送 payment.detected。訂單會繼續等待精確付款，直到過期。這種嚴格性是一項保障：它防止一筆含糊的轉帳擅自改變價格、庫存、權益、帳務或共享地址的歸屬。

先確認究竟發生了什麼

不要一上來就退款。先建立一份客服、工程和財務都能共同使用的證據記錄：

• StableOps 付款訂單號和你的 merchantOrderId；
• 客戶提供的交易雜湊；
• 客戶在錢包裡實際選擇的鏈，而不只是資產名稱；
• 規範鏈記錄裡的代幣合約或鑄幣地址、目標地址與最小單位金額；
• 訂單金額、接受的 (chain, asset) 組合、已分配地址與 expiresAt；
• 目前回執狀態、區塊雜湊與最終性狀態。

請在客戶實際使用的鏈對應的區塊瀏覽器中檢查交易。把其中的代幣轉帳日誌與原始付款指令比較，不要只看錢包裡的“成功”頁面。一筆成功交易可能並未包含符合條件的代幣轉帳；同一個 0x… 目標地址也可能同時存在於多條 EVM 鏈上。

StableOps 會收集可能的錯付金額供人工核對

商戶不必等到客戶提交工單後才發現每一筆錯誤金額。StableOps 會掃描轉入受監控商戶收款地址的受支援代幣；即使金額不一致導致轉帳無法匹配訂單，對應的規範化鏈上事件仍會保留。

開啟控制台 → 訂單 → 對應訂單。對於尚未最終完成的訂單，如果 StableOps 找到同時滿足以下條件的候選事件，頁面會顯示“可能相關的轉帳”卡片：

• 事件屬於同一組織與環境；
• 事件尚未關聯任何付款訂單；
• 鏈、資產與目標地址匹配該訂單歷史上的某條付款指令；
• StableOps 在訂單建立與過期之間檢測到該事件；
• 按代幣精度換算後，事件金額不同於 order.amount。

卡片會展示交易、資產、金額、確認數與檢測時間，方便營運人員開啟事件詳情並與客戶說法核對。候選事件根據目前記錄動態計算，而不是複製到訂單中；如果某條事件後來關聯到任何訂單，它會自動從該列表消失。

這項收集能力只是調查線索，不是自動關聯。它不會改變訂單狀態、合併多筆轉帳、傳送 payment.detected 或移動資金。只有精確匹配才能進入自動支付生命週期。

發錯網路、發錯資產或過期後到帳，可能需要搜尋更廣的鏈上歷史。只有相應的鏈、資產與地址當時處於掃描範圍內，這些事件才會出現在 StableOps 中；最終仍應以規範鏈記錄為準。payment.expired 只表示截止時間前沒有精確匹配到帳，並不能證明客戶什麼都沒轉。

各類不匹配的處理矩陣

可以直接把下表作為一線客服操作手冊的起點。

以上六種情況都不應修改自動訂單。人工入帳應記錄在商戶自己的業務帳本中，並關聯原訂單、異常原因、審批人及所有相關交易雜湊。不要改寫原始支付事件，也不要把未匹配的 StableOps 訂單人工偽裝成 finalized。

少付：補差額不會讓原轉帳自動湊夠

最常見的客服錯誤，是讓客戶“再補 0.01”，並期待原訂單隨之完成。精確匹配會分別判斷每一筆轉帳。如果訂單要求 10.00，9.99 不匹配，後來補的 0.01 同樣不匹配。

應明確選擇以下三種規則之一：

1. 退回部分付款。 當自動履約與帳務必須保持一筆訂單對應一筆轉帳時，這是最清晰的選擇。
2. 人工計入部分付款，再單獨補收餘額。 為剩餘金額建立新付款訂單，然後在商戶帳本中把兩筆交易雜湊關聯到業務訂單。原 StableOps 訂單仍會過期，最終結清業務義務的是你的人工帳務決定。
3. 把短缺金額作為人工調整。 僅適用於財務事先批准且有成文規則的容差。應記錄調整，不要放寬平台的精確匹配規則。

如果客戶在原訂單仍有效時又傳送一筆完整的精確金額，第二筆轉帳可以匹配。第一筆部分付款仍然是需要退款或單獨入帳的異常，因此這種做法可能暫時收到超出預期的資金。

多付：事先決定退差額還是全額退回

多付款項不是“一筆成功付款加上一筆可以自動退回的餘額”，而是一筆金額與指令不符的轉帳，所以訂單不會推進。

你的規則可以把訂單要求金額人工入帳並退還多餘部分，也可以全額退回後讓客戶重新付款。前一種做法會產生拆分帳務：同一筆入帳交易同時覆蓋銷售收入和退款負債。應儲存實際到帳金額、入帳金額、退款金額、退款交易雜湊、網路手續費承擔方式和審批人。

絕不要不加核對就把資金退到交易的 from 地址。交易平台提幣、智慧合約錢包和中繼服務可能從無法識別客戶或無法為客戶入帳的地址發款。應讓客戶提供同一網路上的退款地址，驗證地址格式，並在發出新鏈上交易前完成地址歸屬、制裁篩查與審批。退款是一筆新轉帳，鏈上支付無法原地撤銷。

發錯網路：地址看起來有效，網路仍可能錯誤

多條 EVM 鏈之間最容易發錯網路，因為同一個 0x… 地址在 Ethereum、Base、Arbitrum、Polygon、Optimism 與 BNB Chain 上都有效。如果客戶把 Ethereum USDC 發到 Base USDC 指令展示的地址，資金可能已經到達由商戶私鑰控制的地址，但它位於 Ethereum 上，不能滿足 Base 付款指令。

承諾可以找回之前，應確認以下全部事實：

• 交易確實位於客戶所說的網路，並擁有成功的規範鏈回執；
• 代幣轉帳日誌指向準確的商戶地址；
• 商戶能在實際網路上操作同一個地址；
• 資金錢包備有該網路的燃料代幣，並支援收到的代幣合約。

在不相容的地址族之間，錢包通常會在廣播前拒絕目標地址。如果交易確實廣播成功，應根據實際鏈上記錄與私鑰控制關係判斷，不能僅憑頁面顯示的地址做假設。StableOps 從不持有商戶私鑰，因此無法替商戶簽署找回資金的交易。

發錯資產：估值前先驗證合約

錢包顯示“USDC”或“USDT”並不足以確認資產。資產身份取決於特定鏈上的代幣合約或鑄幣地址。仿冒代幣、跨鏈版本、不受支援的合約或完全不同的資產，不能只因符號相同就按訂單要求的穩定幣估值。

請根據支援資產表和你的資金規則核對合約。如果資產真實且能夠找回，再人工決定估值與退款路徑。如果資產不受支援、缺乏流動性、帶有惡意行為，或資金錢包無法安全轉出，應升級處理，不能向客戶保證一定可以找回。

過期後到帳應進入異常佇列

訂單截止時間只在訂單為 created 時生效。過期任務把訂單推進到 expired 後，已分配地址會釋放回地址池，併發出 payment.expired。此後到達的轉帳無法重新啟用訂單。該地址可能已經出現在另一筆訂單的付款指令中，所以遲到轉帳必須根據交易雜湊、時間和地址分配歷史對帳，不能只看地址。

應讓客戶停止繼續使用舊指令。如果客戶仍需付款，應建立一筆具有新有效期的新訂單。遲到資金透過退款或人工入帳單獨處理，原過期訂單保持不變，以保留審計記錄。訂單過期常見問題記錄了準確的生命週期。

付款回滾不是退款場景

payment.reverted 與所有未匹配轉帳不同。訂單之前確實匹配到一筆轉帳，但該交易回執後來失敗，或發生鏈重組後，即時回執的區塊雜湊不再等於事件入庫時儲存的雜湊。在規範鏈上，這筆付款已經不再成立。

此時可能根本沒有資金可退。只撤銷此前的樂觀介面、庫存預留或其他可逆操作；核對規範鏈狀態後，如果客戶仍需付款，再建立新訂單。不可逆履約應等待經過驗籤和去重的 payment.finalized 事件。有關最終性邊界，請閱讀穩定幣支付確認數；有關安全處理重放，請閱讀穩定幣支付 Webhook。

讓異常處理留在自動履約之外

下面這個簡短的 TypeScript 判斷函式展示了這條邊界。它比較已經歸一化的事實，不會改動付款訂單，也不會假裝多筆轉帳能夠組成一次付款。

type PaymentFacts = {
  expected: { chain: string; asset: string; address: string; amountMinor: bigint }
  actual: { chain: string; asset: string; address: string; amountMinor: bigint }
  orderOpen: boolean
}

export function routePayment(facts: PaymentFacts) {
  if (!facts.orderOpen) return { outcome: 'manual_review', reason: 'order_not_open' } as const
  if (facts.actual.chain !== facts.expected.chain)
    return { outcome: 'manual_review', reason: 'wrong_network' } as const
  if (facts.actual.asset !== facts.expected.asset)
    return { outcome: 'manual_review', reason: 'wrong_asset' } as const
  if (facts.actual.address !== facts.expected.address)
    return { outcome: 'manual_review', reason: 'wrong_address' } as const
  if (facts.actual.amountMinor < facts.expected.amountMinor)
    return { outcome: 'manual_review', reason: 'underpaid' } as const
  if (facts.actual.amountMinor > facts.expected.amountMinor)
    return { outcome: 'manual_review', reason: 'overpaid' } as const

  return { outcome: 'continue_confirmation', reason: 'exact_match' } as const
}

在生產環境中，應根據已驗證代幣的精度換算兩邊金額，再比較整數；絕不要用 JavaScript 浮點數表示代幣金額。在進入這層業務比較前，還要保留組織與環境隔離。StableOps 的實際匹配器會在伺服器端強制執行這些邊界。

預防核對清單

• 原樣展示返回的 order.amount。使用自動金額調整時，它可能與最初請求的金額略有不同。
• 從客戶所選的 paymentInstructions 項讀取鏈、資產和地址；絕不脫離網路單獨展示地址。
• 禁止編輯金額，並用同一組返回值生成錢包請求或二維碼。
• 當錢包中可能出現同名資產時，展示代幣合約或鑄幣地址。
• 提醒 EVM 使用者在簽名前再次核對目前網路。
• 過期視窗要足夠等待真人操作或交易平台提幣到帳，但不要讓已放棄訂單無限期佔用地址。
• 在經過驗籤和去重的 payment.finalized Webhook 到達前，停止不可逆履約。
• 允許客服只讀檢視訂單詳情、可能的錯付事件和區塊瀏覽器；退款簽名必須經過資金審批。
• 上線前確定少付、多付、發錯網路、發錯資產、遲到付款以及退款手續費規則。
• 每筆人工入帳和退款都應關聯 merchantOrderId、付款訂單號、入帳交易雜湊及退款交易雜湊。

有關多鏈 USDT 結帳與精確展示付款指令的完整設計，請閱讀如何可靠接受 USDT 付款。

常見問題

客戶少付、多付或發錯鏈後會怎樣？

訂單不會推進，因為這筆轉帳至少缺少一個精確匹配鍵。到達商戶控制地址的資金仍由商戶控制，但退款或人工入帳發生在自動訂單生命週期之外。金額或鏈錯誤常見問題給出了產品行為與找回步驟。

訂單過期後才收到付款會怎樣？

付款不會重新啟用訂單。地址已經釋放，而且可能已被複用，因此應按交易雜湊和分配歷史對帳，再人工退款或入帳。客戶再次嘗試時應使用新訂單。詳見訂單何時過期。

已確認的穩定幣付款還會回滾嗎？

會。處於 detected 或 confirmed 的付款仍可能因回執失敗或鏈重組變成 reverted。應把 payment.reverted 當作回滾訊號，而不是持有可退款資金的未匹配付款；不可逆履約應等到 payment.finalized。付款回滾常見問題解釋了兩者的區別。

把第一次客服工單變成可複用操作手冊

以金額或鏈錯誤常見問題為起點，補上訂單過期與付款回滾分支，併為上文處理矩陣的每一行指定負責人和審批規則。然後在沙盒環境中分別測試一次少付、多付和訂單過期。不匹配付款應該留下證據並進入受控異常流程，而不是導致意外履約。