OpenRouter 信用卡被拒的几种原因与官方给的处理办法

数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。

先说结论：OpenRouter 官方文档里根本没有「拒付原因码表」这种东西。 全站文档中唯一直接提到卡被拒的地方，是 FAQ 里「我的额度没到账」那一条，而且它给出的不是原因，是一条反推路径——先允许 Stripe 那边延迟最多一小时，一小时后仍没额度，就去确认「有没有真的被扣款、有没有收到 Stripe 的收据邮件」；如果既没扣款也没收据，官方的判断是 your card may have been declined. Please try again with a different card or payment method.；如果扣款了却没额度，那就不是卡的问题，要发邮件给 support。所以「信用卡被拒」在 OpenRouter 这里是个推断出来的结论，不是系统告诉你的结论，你要做的第一件事不是换卡，而是先把自己归到三种情形里的哪一种。至于发卡行为什么拒，那发生在 Stripe 与银行侧，官方文档里没有找到任何相关说明。

第一步：分清「卡被拒」和「额度延迟」

这两件事表现完全一样——你付完钱，回到账户里余额没变。但处理方式相反：一个要换支付方式重试，另一个绝对不能重试。

官方给的分界线是时间加凭证两个条件。时间上，官方明确说明 Stripe 集成偶尔会出问题导致额度延迟显示，可以等待最多一小时。这一小时是官方给的容忍窗口，不是你自己估的，在这个窗口内反复重新下单，本质上是在制造重复交易。

凭证上，一小时之后再去核两样东西：账户有没有真的被扣款，以及邮箱里有没有 Stripe 的收据邮件。这两样构成一个真值表：

• 没扣款、没收据 —— 官方判断为卡可能被拒。这时候官方给的动作就一句话：换一张卡，或者换一种支付方式再试。
• 扣款了、有收据，但额度没到 —— 支付本身是成功的，问题出在额度入账环节。官方要求的动作是发邮件到 support@openrouter.ai，并附上这笔购买的详细信息。这种情况下你继续换卡重试，只会多付一笔钱。
• 用加密货币付的，出了任何问题 —— 官方不做上面这套区分，直接让你发邮件给同一个 support 邮箱，由他们查。

注意第二条和第三条都指向人工渠道。OpenRouter 文档里，账户与账单类问题走的是 support 邮箱，另外在税号与发票相关的场景下官方也指向 Support 页面；Discord 则被限定为提交 bug 和变更请求，不是账单通道。这个分工在 FAQ 的账户管理一节里写得很清楚，别搞混了投错地方。

官方支持的支付方式，就是你换方式时的全部选项

既然官方给的动作是「换一张卡或换一种支付方式」，那能换成什么就得先弄清楚。官方 FAQ 的原文是：We accept all major credit cards, AliPay and cryptocurrency payments in USDC. 后面还跟了一句正在整合 PayPal 的说明（这属于会随版本变化的信息，以官方文档当前版本为准）。

这里有一点对国内读者特别重要：支付宝是官方直接列出的支付方式之一。也就是说，卡走不通的时候，官方渠道内部就还有路可走，不需要去碰任何官方渠道之外的东西。本文也不会讨论任何第三方代充、代注册或规避手段——那些既不在官方文档里，也不该出现在一篇讲排查的文章里。

加密货币这条路要额外注意一个变更：旧的程序化充值接口已经被移除了。官方文档明确写着 POST /api/v1/credits/coinbase 现在返回 410 Gone，错误信息是 The Coinbase APIs used by this endpoint have been deprecated, so the Coinbase Commerce credits API has been removed. Use the web credits purchase flow instead. 原因是 Coinbase 弃用了这个流程依赖的底层 API。现在的加密充值走的是 Coinbase Business Checkouts，入口在网页版的 credits 页面。文档还提醒，SDK 里可能还残留着已废弃的 createCoinbaseCharge 方法，要等下一次 SDK 重新生成才会清掉——官方同时提示，已有 SDK 里可能仍残留着这个已废弃的方法，直到下一次 SDK 重新生成为止。这类失败很容易被误当成「支付被拒」，其实是接口下线。

别在没确认前一笔是否成功时连续换卡

这是本文最想让你记住的一条操作纪律，原因在退款规则上。

官方退款政策的机制是：未使用额度的退款申请，必须在交易被处理之后的二十四小时内提出；这个窗口过去之后，未使用的额度就变成不可退。申请入口是 Credits 页面上的退款按钮，退款会退回原支付方式。有两条例外必须记住：平台手续费不退，以及 cryptocurrency payments are never refundable——加密支付永远不可退。

把这条规则和上一节的时间线叠起来看，问题就出来了：官方让你等最多一小时确认额度是否延迟，而退款窗口是二十四小时。如果你在一小时内因为着急连下了几单，最后发现全都成功了，你还有时间去申请退掉多余的部分——但每一笔的手续费都拿不回来，而且如果其中某一笔是加密支付，那笔就彻底退不了。所以正确顺序永远是：等窗口 → 核扣款与收据 → 确认失败 → 再换方式，而不是失败一次就立刻换一张卡再刷一遍。

关于手续费本身是怎么产生的、为什么它和调用费是两笔完全不同的账，可以看充值手续费的构成与自估方法那一篇，这里不重复。

有一类「付不了」，压根不是卡的问题

排查到这一步，还有几种情形会被误当成拒付，值得单独拎出来。

首次购买的表单比你以为的长

官方在讲发票 Tax ID 的文档里，顺带把首次购买的流程完整写出来了：进 settings/credits 页点 Add Credits，如果你此前没有购买过，弹出的 modal 会先引导你填账单地址，再填支付方式，两步都在同一个 modal 里完成；只有账单地址和支付方式都保存成功之后，真正的购买表单才会出现。

这意味着首次充值比老用户多两个前置步骤，卡在账单地址这一步走不下去，跟卡有没有被拒完全是两回事。购买表单出现之后，还可以展开 Edit Tax ID 一节填税号：选国家代码、填税号、保存。官方说明 OpenRouter 的支付与税务由 Stripe 处理，税号保存后会挂到 Stripe 的客户记录上，并出现在此后每一张发票上；支持的税号类型覆盖数十个国家和地区（具体清单以官方文档为准），可以存多个，每个已保存的税号会以 chip 的形式显示在输入框上方，点旁边的垃圾桶图标可以删掉。

组织账户下，你可能压根没有付款权限

如果你是在组织（Organization）上下文里操作，官方的权限边界是硬的：只有组织管理员能为组织购买额度、查看详细账单信息、管理支付方式与开票设置。文档里那条警告写得很直白——Regular organization members cannot purchase credits or access billing information. 普通成员遇到账单相关的需求，官方给的动作是联系管理员。

还有一条容易踩的：个人账户可以自己把符合条件的额度转给组织，路径是 Settings > Credits → Move credits to organization，选组织、确认金额、点 Transfer。但走发票或欠款计费的组织收不到转入的额度，因为它们是按发票结算而不是用预付余额。转账对话框还额外强制两条限制：新加入的组织成员要满足一定的任职时长要求，组织才能接收转账；刚接收过一次转账的组织，要过一段冷却期才能再接收下一次。这几条任何一条不满足，操作都会被挡下来，但它们跟支付本身没关系。

调用报错的 402，也不是拒付

充值失败和调用失败是两条独立链路，别混在一起排。官方文档里的额度限制来自两个地方：一是账户余额，二是单个 API key 上可选的消费上限——后者由 GET /api/v1/key 响应里的 limit、limit_reset、limit_remaining 三个字段描述。

这里有个反直觉的设计值得单独说：账户余额为负时，请求可能失败，免费模型也在波及范围内，必须充值把余额补回零以上才能继续用。很多人以为免费模型是完全独立的通道，实际上它同样被账户余额这道闸卡着。

官方给 402 的处理顺序是三步：充值把余额提到零以上；检查单 key 的限额是否已经耗尽，耗尽了就调高这个 key 的上限，或者等 limit_reset 到点；以及主动定期调 GET /api/v1/key 监控 limit_remaining，在请求开始失败之前就发现问题。这些字段和监控节奏，在额度管理与不超支的操作清单里展开得更细。

按 error_type 字段区分会更精确：额度不足是 payment_required，key 缺失或无效是 authentication，key 有效但缺权限或被 guardrail 拦是 permission_denied（以官方文档为准）。这三个都不是「信用卡被拒」，一个都不是。

收尾：把监控前移，比排查拒付更划算

官方提供了两种充值节奏：手动充值，或者设置 auto top up，让余额低于你设定的阈值时自动补充。文档说明了 auto top up 的触发条件，但扣款失败时它会怎么表现，官方文档里没有找到相关说明——所以不建议把它当成唯一防线。

更稳的做法是自己盯着余额：Activity 页可以按模型、供应商、API key 过滤历史用量，官方另外提供了 credits API，能拿到账户余额与剩余额度的实时信息。把这个查询接进你自己的告警里，就不会出现「调用全线报错了才发现要充值、一充值又发现卡被拒」这种双重故障叠在一起的局面。这套思路是通用的，跟具体哪家平台无关，可以参考API 成本监控的三层结构。

最后重申一次最容易栽的坑：在没有确认前一笔到底成没成功之前，不要连续换卡重试。你以为自己在解决拒付，实际上可能在制造几笔重复扣款，而其中一部分的手续费和加密支付部分，是拿不回来的。