这是 AI API 计费里最常见、却几乎没人写清楚的一类故障，而且它不是你钱包的 bug。它是加密货币用户以为自己在做的事，与收银台背后那个支付处理商实际接受的东西之间的结构性错配。这一页讲清成因，给出一套现实可行的追回流程，并对时间预期说实话。
本文于 2026 年 8 月 10 日核实。支付处理商的行为和支持的链会变，所以转账前请先在实时收银台页面确认它接受的网络。
一句话版本
OpenRouter 自己并不处理加密货币付款。它用的是一个托管式加密货币收银台 —— Coinbase Commerce —— 只有当进来的这笔转账，精确匹配该笔订单创建时指定接受的那个链与币种组合时，才会记入付款。
币对了链错了，或者链对了币错了，钱都会到达一个真实存在、由真实处理商控制的地址，但系统里没有任何东西把它和你的订单关联起来。没有报错页面。交易成功了。订单就那样一直未支付，直到过期。
这道缝隙 —— 一笔链上成功、却仍然不被识别的付款 —— 就是几乎所有这类案例的所在。
到底出了什么错，按发生频率排序
- 币对了，网络错了。这是最常见的一种，遥遥领先。USDC 同时存在于 Ethereum、Base、Polygon、Solana、Arbitrum、Optimism、Avalanche 等多条链上。它们是合约地址不同的不同代币，只是恰好共用一个名字和一个价格。一个典型案例：用户从某大交易所提 USDC，因为提现费最低而选了 Polygon，发出略低于 15 美元的金额，转账几秒内确认。而订单等待的是另一条网络。资金落在了处理商的 Polygon 地址上，而这笔订单根本不监听那个地址。什么都没记账，也什么都没报错。这个决定是在交易所的提现页面上做出的，而它几乎总是基于手续费高低，而不是基于订单要求的是什么。
- 只接受 USDC，却发了 USDT。用户把 USDT 和 USDC 当成可以互换的，因为它们都锚定美元。支付处理商不这么看。以 USDC 计价的订单，即使在同一条链上也不接受 USDT。我们反复见到的一个模式：一笔走 Solana 的 USDT 转账在链上确认，付款人手里有有效签名、钱包里打着绿色对勾，而 OpenRouter 余额纹丝不动。另一个：一笔走 Polygon 的小额 USDT，一周后仍未入账，工单也还没有回复。
- 通过聚合器或 swap 路径付款。用 swap 聚合器或 DEX 路由付款，而不是钱包直接转账，会改变收款地址实际看到的东西 —— 发送方地址、代币路径，有时候连代币本身都变了。有位用户通过一个 Solana 聚合器付了大约 15 USDC；swap 执行了，资金也动了，credits 却一个都没出现。就订单付款而言，从你自己控制的钱包直接转账，远比任何经过 swap 的路径安全。
- 金额不匹配，包括多付。少付订单当然会一直开着。但在某些处理商配置下，多付同样会破坏自动入账，因为收到的金额与预期金额对不上，这笔付款会被标记为需要人工处理，而不是自动结算。多发一点用来覆盖手续费，并不像感觉上那么保险。
- 转账确认之前订单就过期了。托管式加密货币订单都带一个时间窗，通常是 15 到 60 分钟。如果你生成了订单、转头去忙别的、一小时后才发 —— 或者你在网络拥堵时发 —— 转账就可能在窗口关闭之后才落地。地址依然是真实的。只是订单已经不再监听了。
第 1 步：确认你到底发了什么
联系任何人之前，先把事实收集齐。没有这些信息客服帮不了你，而且你很可能五分钟内自己就找到了答案。
打开你所用那条链的区块浏览器，调出你的交易。记下：
- 交易哈希 —— 完整字符串，不是一张被截断的截图。
- 网络 —— 实际的那条链，例如 Polygon PoS、Solana mainnet、Base。
- 代币合约地址 —— 这一项能一锤定音地判定到底是 USDC 还是 USDT。
- 确切金额 —— 精确到全部小数位。
- 收款地址 —— 钱最终去了哪里。
- 时间戳 —— 用 UTC。
- 发送地址 —— 你付款用的那个钱包。
然后与订单对照：收银台页面要求的是哪条链、哪个币，订单的过期时间是什么时候？如果订单页面或邮件还在，这些信息都在里面。到这一步，你通常已经知道自己撞上的是五种成因里的哪一种。
第 2 步：先看看这笔钱是不是已经出现在某个地方
在升级处理之前，有两件事值得先查。
这笔付款在收银台里是不是显示为 pending 或未解决？托管式加密货币收银台通常有少付、多付或延迟这几种状态，人工可以处理。只要你的付款能在那里出现，你的处境就好得多。
你收到过支付处理商发来的邮件吗？Coinbase Commerce 会独立于 OpenRouter 发送自己的通知。搜一下收件箱，包括垃圾邮件，找这笔订单。
如果资金落在了一条订单从未监听的链上，它在收银台里哪儿都不会出现。这是更棘手的一种情况，诚实地讲：发到处理商地址、但走了不支持网络的资金，能否追回完全取决于处理商的自由裁量。协议层面没有任何机制能把它拉回来。有些处理商确实会帮忙追回；那是一个人工的、缓慢的、尽力而为的过程。
第 3 步：用正确的方式联系客服
一张工单是当天解决还是躺一个礼拜，差别几乎全在第一条消息怎么写。发一条包含全部信息的消息，而不是先发一句短的、再跟着五轮补充。
按这个顺序写清：
- 你的 OpenRouter 账号邮箱。
- 一句话说明问题：链上转账已确认，credits 未入账。
- 订单或 payment link 标识符。
- 交易哈希、网络、代币合约地址、确切金额、UTC 时间戳。
- 这笔交易的区块浏览器 URL。
- 你想要的结果：入账 credits，或退款到发送地址。
该联系哪一方就都联系。OpenRouter 客服负责 credits 那一侧；资金在支付处理商手里。如果你的转账去了订单未覆盖的网络，能真正找到这笔钱的是处理商。
基于我们跟踪过的案例，现实的时间预期是：付款在收银台里显示为少付或延迟的简单案例，通常几个工作日内解决。错网络和错币种的案例经常要一到三周，有些则一直没有回音。多位用户报告这类工单整整一周都没有收到第一次回复。请据此安排 —— 如果你有生产流量依赖这笔余额，别干等工单。用别的方式先把账户充上，把卡住的这笔转账当成一件独立的追回工作来推进。
礼貌地升级比大声地升级更管用。每隔三到四个工作日在你自己的工单里回复一行，重申交易哈希即可。不要开重复工单；在大多数客服系统上，那会把你的排队位置重置掉。
第 4 步：下次怎么避免
三种做法，从最保守到最省事。
严格按订单指定的链和币种付款，其他一律不碰。碰钱包之前先把收银台页面读一遍。确认网络名称与你的提现页面完全一致 —— 交易所下拉框里写着 USDC，这点信息远远不够。发确切金额，不要凑整往上取。生成订单后立刻发，别隔一小时。
从一个能让你有意识地选择网络的账户出钱。如果你手上的 USDC 只在一条订单不接受的链上，那就在生成订单之前把它跨过去，而不是在付款过程中跨。先生成订单、再开始一次 20 分钟的跨链，正是订单过期的典型剧本。
或者，用一个接受你手上真正持有的资产的收银台。这就是这个问题所属的类别：故障的根因是可接受资产清单太窄，那么一个更宽的清单就能消除它。checkout.rozo.ai 上的 ROZO Checkout 是这里的一个选择 —— 你粘贴 OpenRouter payment link，用 USDT、Solana 或 Stellar 或 BNB Chain 上的 USDC、或者 Lightning 上的 Bitcoin 付款，它会替你结算成 USDC。错网络这一整类故障不会发生，因为它根本不要求你去匹配某一条特定的链。
它不是唯一的选择，而这里的取舍值得说明白：你是在通过一个第三方路由，而不是直接付给商家的处理商，而且 ROZO 与 OpenRouter 和 Coinbase 均无隶属关系。有些人会更愿意走直连路径、自己仔细挑网络，这完全是合理的选择。另一些人手上本来就只有 USDT 或 sats，压根没有直连路径。按这个标准来选。
无论你走哪条路，那个能长期救命的习惯都是同一个：签名之前，看网络和代币合约，而不是只看代币代号和数字。