稳定币支付选哪条链：费用、最终性与付款人实际在用的网络

评估稳定币收款的团队通常把“我们应该支持哪条链”当成单选题来问。这个提问框架本身就错了。网络手续费由付款人承担，最终性由平台策略处理，而真正决定结账转化率的变量是：付款人是否已经在那条链上持有稳定币。

所以先给结论：稳定币支付的最佳链不是某一条链。应该接受一小组与付款人资金分布相匹配的 (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 事件，履约处理器保持同一个。真正随链增长的是对应家族的收款地址池和面向付款人的文案，代码路径不会分叉。

下一步

打开文档首页中的链与资产支持表，标出与你付款人分布吻合的组合。然后按照快速开始在 Sandbox 创建一张接受两条链的支付订单：一次接口调用会同时返回两份付款指令，无论从哪条链付款，Webhook 生命周期都完全一致。之后按付款人资金的真实分布，一条一条扩展你的链集。