穩定幣支付選哪條鏈：費用、最終性與付款人實際在用的網路

評估穩定幣收款的團隊通常把“我們應該支援哪條鏈”當成單選題來問。這個提問框架本身就錯了。網路手續費由付款人承擔，最終性由平台策略處理，而真正決定結帳轉化率的變數是：付款人是否已經在那條鏈上持有穩定幣。

所以先給結論：穩定幣支付的最佳鏈不是某一條鏈。應該接受一小組與付款人資金分佈相匹配的 (chain, asset) 組合，把每筆支付做成按訂單的精確匹配，再讓歸一化的訂單與事件層承載所有鏈，使營運成本在鏈集擴大時保持接近恆定。本文給出決策維度、費用與最終性差異背後的機制，以及按客群劃分的起步鏈集。

從付款人出發，而不是從鏈出發

按吞吐量或手續費表給鏈排名，會忽略支付轉化中最硬的約束：付款人不會為了付你的錢去跨鏈。持有 TRON USDT 的人不會把資金搬到 Base 來完成你的結帳，他要麼放棄購買，要麼直接用你沒有列出的網路轉帳，然後找客服。

錢包與資產的分佈是不均勻的，而且無法靠架構解決：

• 相當大比例的零售 USDT 活動發生在 TRON 上。交易所提幣、跨境匯款和場外結算讓 TRON USDT 成為許多付款人的預設通道，在美歐以外尤其明顯。
• USDC 原生髮行在 Base 上，也是 Coinbase 生態使用者最可能已經持有的資產。對這類客群，Base 上的 USDC 勝過任何一條他們從未入金、只是技術上更便宜的鏈。
• Solana 上的原生 USDC 有真實的消費級錢包覆蓋，轉帳費用幾乎可以忽略，消費類支付應用因此聚集在這裡。
• Ethereum 依然是金庫、基金和企業級交易對手存放大額資金的地方。對發票量級的付款，它的費用水平無關緊要，保守的最終性反而是優點。

選錯鏈不會表現為技術故障，而會表現為放棄支付和錯誤網路轉帳。既然一張付款訂單可以同時開放多條鏈，真正的決策就不是“選哪一條”，而是“先上哪一組、下一條加什麼”。

StableOps 目前支援在 Ethereum、Base、Arbitrum、Polygon、Optimism、BNB Chain、TRON 和 Solana 主網收款。支援組合以文件首頁中的鏈與資產表為準。

真正區分鏈的四個維度

費用水平和確認耗時會隨網路狀況漂移，所以下表刻意只描述量級和機制，不寫會過時的具體數字。

表格背後有三個機制值得理解。

結帳網路費首先是付款人摩擦，但不是全部商戶成本。 在所有支援的鏈上，網路手續費都由傳送方支付，所以問題不是收款花你多少錢，而是付款人和一筆完成的轉帳之間隔著什麼。最經典的失敗是“有 USDT，沒有燃料幣”：EVM 鏈的付款人需要在那條具體網路上持有 ETH 或 BNB，TRON 自持錢包的付款人做代幣轉帳需要 TRX 或能量。交易所提幣繞開了這個問題，因為手續費一側由交易所處理，這也是交易所重度客群在 TRON 和 BNB Chain 上轉化更好的原因之一。資金歸集也有同樣的帳要算：非託管模式下收到的資金由你自己歸集，每個一次性地址的歸集各付一筆鏈上手續費，所以高頻小額收款天然適合低費網路，發票量級的收款則適合 Ethereum。網路費、歸集、退款、兌換和營運成本應按穩定幣支付手續費的總成本口徑分開計算。

最終性是平台策略，你的程式碼不應硬編碼它。 底層機制各不相同：Ethereum 的檢查點最終性、Rollup 的排序打包加深度、TRON 的 DPoS、Solana 的確認級別。StableOps 把它們全部歸一成同一套生命週期，從 payment.detected 到 payment.confirmed 再到 payment.finalized，各鏈的閾值作為平台設定維護。目前預設深度和估算耗時見確認狀態說明；它們是估算值，不是服務承諾。你的業務規則在每條鏈上保持一致：detected 時展示進度，confirmed 時做謹慎的可撤銷動作，只有收到已驗證的 payment.finalized 事件才執行不可逆履約。完整的決策框架見如何為穩定幣支付設計確認閾值。

資產深度按鏈計，不按品牌計。 不寫清網路的“我們收 USDT”是不完整的：同一個品牌在每條鏈上是不同的代幣合約、不同的付款人深度，有些組合在支援表裡根本不存在。金額匹配按各合約的小數位換算成最小單位進行，包括 BNB Chain 上 18 位小數的對映代幣，所以精確性不會被這些差異破壞。鏈加資產的匹配模型在可靠的 USDT 收款流程一文中有完整展開。

地址家族決定你的營運面

八條鏈歸入三個地址家族，而營運事故恰恰發生在家族邊界上。

EVM 這一行值得強調。由於同一個 0x… 地址存在於每條 EVM 鏈上，拿到 Base USDC 付款指令的付款人，可能把 USDC 從 Ethereum 發到同一個地址：轉帳確實落在你控制的地址裡，只是落在了錯誤的網路。嚴格的按訂單匹配保證這類轉帳不會錯誤地完成任何訂單；又因為模式是非託管的，資金停在私鑰由你掌握的地址中，可以在流程外自行取回。營運層面的處理方式見錯誤金額或錯誤鏈 FAQ。

落到實操：每接受一個家族，就要為它匯入收款地址，並準備該家族的區塊瀏覽器排查手冊。而在同一家族內再加一條鏈，複用的正是你已有的技能和大部分工具。

鏈多不等於營運負擔乘以鏈數

對多鏈收款合理的擔憂是：每加一條鏈就多一套掃描器、一套確認規則、一批 Webhook 差異和一套對帳模型，負擔隨鏈數相乘。如果按鏈各建一套，這個擔憂成立；當訂單、確認與事件層做了歸一化，它就不再成立：

 Base USDC      Ethereum USDC      TRON USDT      Solana USDC
     \               |                  |               /
      +------ 一張付款訂單，一份 acceptedAssets 列表 ------+
                             |
         精確匹配：組織 + 環境 + 鏈 + 資產 + 地址 + 金額
                             |
    detected -> confirmed -> finalized（或 expired / reverted）
                             |
          同一條簽名 Webhook 事件流，同一個履約處理器

一張訂單同時開放所有接受的組合：

import { StableOps } from '@stableops/api-sdk'

const stableops = new StableOps({
  apiKey: process.env.STABLEOPS_API_KEY!,
})

export async function createCheckoutOrder(order: {
  id: string
  amount: string
  paymentExpiresAt: string
}) {
  return stableops.paymentOrders.create(
    {
      merchantOrderId: order.id,
      amount: order.amount,
      acceptedAssets: [
        { chain: 'base', asset: 'USDC' },
        { chain: 'ethereum', asset: 'USDC' },
        { chain: 'tron', asset: 'USDT' },
        { chain: 'solana', asset: 'USDC' },
      ],
      expiresAt: order.paymentExpiresAt,
      metadata: { product: 'checkout' },
    },
    { idempotencyKey: `payment-order:${order.id}` },
  )
}

建立時，StableOps 為每個接受的組合分配一個可用候選地址，並在 paymentInstructions 中一併返回。付款人在結帳頁選擇網路後，你只需原樣渲染對應條目：鏈、資產、地址加上精確的 order.amount，並且永遠不要脫離鏈資訊單獨展示地址。訂單到達終態時未被使用的候選地址會被釋放；用相同的 merchantOrderId 和冪等鍵重試是安全的。分配與匹配行為見 Payment Orders；各鏈完全一致的 Webhook 與履約邊界見生產級 USDC 收款架構。

按客群選擇起步鏈集

把下表當作可以直接複製再調整的起點，然後讓證據驅動擴充套件：錯誤網路的客服工單和放棄的結帳，會準確告訴你付款人想要的下一條鏈是什麼。

上線一組鏈之前，過一遍這份清單：

• 每個接受的 (chain, asset) 組合都已匯入合格的收款地址，並開啟地址池告警。
• 結帳頁從返回的付款指令渲染鏈、資產、地址和精確的 order.amount，金額不可編輯。
• 付款頁文案按鏈設定確認時長預期：Solana 與 Rollup 網路以秒計，Ethereum 以分鐘計。
• 在需要的場景給出燃料幣提示，例如 Base 轉帳需要在 Base 上備少量 ETH。
• expiresAt 按付款人的真實付款方式設定；交易所提幣到帳通常比錢包直轉更慢。
• 每個地址家族都有錯誤網路處理手冊，並把 EVM 之間的錯轉當作預期中的常見情況。
• 不可逆履約只由已驗證的 payment.finalized 事件觸發，每條鏈一致，不設例外。
• 對帳記錄保留內部訂單號、付款訂單號、鏈、資產、地址與金額的完整元組。

FAQ

USDC 收款應該選 Base 還是 Ethereum？

通常兩條都開，因為一張付款訂單可以把兩者並排提供，由付款人自己選。如果必須排優先順序，就按客單價和客群決定：消費級金額優先 Base，付款人手續費只是主網的很小一部分，而且 Coinbase 生態使用者已經持有原生 USDC；發票量級的企業付款優先 Ethereum，交易對手的金庫餘額在那裡，更深的最終性閾值也和金額風險相稱。

為什麼這麼多客戶要求用 TRON USDT 付款？

因為他們的 USDT 本來就在那裡。交易所提幣預設項、匯款通道和場外結算讓 TRON 成為大量零售 USDT 的實際歸屬地，這些付款人很少會為了付你的錢跨鏈。如果你的客群偏全球零售卻不開放 TRON USDT，換來的不是別的收入，而是放棄支付和錯誤網路轉帳。營運側的處理見可靠的 USDT 收款流程。

每條鏈都需要單獨接入一次嗎？

不需要。一張付款訂單列出全部接受的 (chain, asset) 組合，同一條 Webhook 事件流為所有鏈承載同樣的 payment.detected、payment.confirmed 和 payment.finalized 事件，履約處理器保持同一個。真正隨鏈增長的是對應家族的收款地址池和麵向付款人的文案，程式碼路徑不會分叉。

下一步

開啟文件首頁中的鏈與資產支援表，標出與你付款人分佈吻合的組合；若還未決定先支援 USDC、USDT 還是兩者，可先閱讀面向商戶的穩定幣對比。然後按照快速開始在 Sandbox 建立一張接受兩條鏈的付款訂單：一次介面呼叫會同時返回兩份付款指令，無論從哪條鏈付款，Webhook 生命週期都完全一致。之後按付款人資金的真實分佈，一條一條擴充套件你的鏈集。