OpenRouter 充值教程：从开通到到账的完整流程与每步会卡在哪

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

OpenRouter 的充值不是「输个卡号点确定」这么一步的事，它被拆成了四段：注册账号 → 在 Credits 页面把账单地址和支付方式先存进去 → 选一种官方支持的支付方式完成购买 → 等额度到账并确认余额。真正卡人的地方几乎都不在付款那一下：首次购买时账单地址和支付方式没保存完，主购买表单根本不会出现；付完之后 Stripe 侧偶尔会延迟，官方给的处理办法是先等、再核对收据、最后才找客服；税号必须在开票之前设好，因为它只对之后的发票生效；加密货币支付按官方说明永远不可退。把这四段和各自的失败分支搞清楚，充值这件事就没有悬念了。

先弄明白你充的到底是什么

官方 FAQ 把 credits 直接定义成「存放在 OpenRouter 上的存款」（deposits），你调 API 或者用网页版 chat 界面时，从这笔存款里扣请求成本。站点和 API 上的所有定价都用同一种基础货币标注，具体币种与单价请看官方定价页，本文不复述。

计费的颗粒度值得先看清楚，因为它决定了你的额度消耗快慢：官方说明每个模型都按每百万 token 报价，而且 prompt token 和 completion token 通常是两个不同的价；除此之外还存在按请求计费的模型，以及针对图片和 reasoning token 的单独计费项，这些细节都显示在 models 页面上。一次请求打过去之后，OpenRouter 从供应商那里拿到本次处理的 token 总数，算出对应成本，再从你的额度里扣掉。

这里有一条对预算判断很关键的官方表述：OpenRouter 直接透传底层供应商的定价，不做任何加价（原文用的词是 without any markup），你付的和直接找那家供应商是同一个价；平台的收入来自购买额度时收取的那笔费用。另一条同样重要的是，官方明确说目前不提供按用量的批量优惠，如果你认为自己的场景特殊，官方给的路径是发邮件沟通，而不是在页面上找什么隐藏入口。手续费具体由哪几部分构成、你自己怎么估算，可以看OpenRouter 充值手续费是怎么产生的。

第一步：注册账号，然后进 Credits 页面

官方给新用户的入门路径只有一句话：创建账号，然后在 Credits 页面（openrouter.ai/settings/credits）添加额度。顺序不能反——有了额度之后，你才能去用 chat 界面，或者创建 API key 开始调接口。

第一次购买时，Credits 页面的 Add Credits 弹窗不会一上来就让你填金额。官方在税号配置文档里描述得很清楚：如果你之前没买过，这个弹窗会先带你添加账单地址（billing address），再添加支付方式（payment method），两件事都在同一个弹窗里完成；只有当账单地址和支付方式都保存好之后，主购买表单才会出现。

这就是很多人第一次充值时的困惑点——以为流程卡住了，其实是还没走完前置的两步。官方文档没有说明这一步为什么必须先填，只写了它是主购买表单出现的前置条件。

顺手把税号设了

主购买表单出来之后，里面有一个 Edit Tax ID 分区，展开它就能配置税号。官方给的操作是：从下拉框里选国家代码，填入税号，点 Save。保存后 Stripe 会把这个税号挂到你的客户记录上，并出现在之后每一张发票上。

注意「之后」这两个字：它不会追溯修改已经开出的发票。所以如果你的报销流程需要发票上带税号，最稳的做法是在第一次购买之前就设好。

官方还说明了几个细节：可以保存多个税号（比如一个欧盟 VAT 号加一个本地税务登记号），每个已保存的 ID 会以小标签的形式显示在输入框上方，点旁边的垃圾桶图标可以删除；支持的税号类型通过 Stripe 实现，覆盖多个国家和地区，文档里举的例子包括欧盟 VAT、美国 EIN、英国 VAT、澳大利亚 ABN、加拿大 BN、巴西 CNPJ 等（这是官方列举的类型，以官方文档当前版本为准）；输入框会根据你选的国家显示对应的格式示例。

还有一条容易被忽略的：OpenRouter 上的价格是不含适用税费的，在需要的司法辖区，VAT 或 GST 由 Stripe 在购买时自动计算并加到发票上。如果税号没被接受或者需要更正后的发票，官方指的路径是 Support 页面。开票相关的更多情况见OpenRouter 充值开发票怎么办。

第二步：选支付方式

官方 FAQ 里关于支付方式的原文是：We accept all major credit cards, AliPay and cryptocurrency payments in USDC.——主流信用卡、支付宝（AliPay），以及以 USDC 结算的加密货币支付。官方另外提到正在集成 PayPal，如果你希望支持某种支付方式，可以去官方 Discord 提。

值得单独说一句：支付宝是官方直接支持的支付方式，写在官方 FAQ 里。这意味着国内读者完成充值不需要任何官方渠道之外的东西，按页面流程走即可。至于卡被拒的各种情形，官方给的处理办法是换一张卡或换一种支付方式，后面「没到账怎么办」一节会展开。

加密货币支付有两个坑

第一个是编程接口已经没了。官方文档单独挂了一条警告：Coinbase 废弃了这套流程依赖的 API，因此 POST /api/v1/credits/coinbase 端点已被移除，现在调它会返回 410 Gone，响应体里的 message 就直说了「Coinbase Commerce credits API 已移除，请改用网页购买流程」。官方给的替代方案是走 Credits 页面的网页购买流程，目前用的是 Coinbase Business Checkouts。文档还提醒：SDK 里那个废弃的 createCoinbaseCharge 方法可能会残留到下一次 SDK 重新生成为止——也就是说方法还在，调了也没用，别被它误导。

第二个坑是不可退。官方退款政策里有一句独立的说明：加密货币支付永远不可退（原文 cryptocurrency payments are never refundable）。后面讲退款时还会再提，这里先记住：用加密货币充之前，先想清楚金额，因为没有后悔按钮。

第三步：手动充，还是让它自动补

官方给了两种充值模式：手动 top up，或者设置 auto top up——余额低于你设定的阈值时自动补充。

选哪种其实取决于你怕不怕断流。这里有一条官方在 Limits 文档里写明的机制值得拿来做判断依据：如果账户额度余额为负，你可能会看到额度不足类的错误，免费模型也在波及范围内；把余额补到零以上之后才能重新使用这些模型。对于跑在生产上的服务，这意味着余额耗尽的后果不是「降级到免费模型继续跑」，而是全线中断——auto top up 的价值就在这里。

反过来，如果你只是个人试用、不希望额度被意外消耗，手动充值加上单 key 的消费上限会更可控。

第四步：等到账，以及没到账怎么办

官方在 FAQ 里给了一条完整的排查链路，顺序不要跳：

1. 如果用 Stripe 支付，官方说明 Stripe 集成偶尔会出问题，导致额度延迟显示在账户上，请允许最多等待一个小时。
2. 一个小时之后仍然没出现，先去确认你是否真的被扣款了、有没有收到 Stripe 的收据邮件。
3. 如果没有收据邮件、也没有被扣款，那么大概率是卡被拒了，官方建议换一张卡或换一种支付方式重试。
4. 如果已经被扣款但额度没到，发邮件到 support@openrouter.ai，附上本次购买的详细信息。
5. 如果是加密货币支付出问题，同样发邮件到 support@openrouter.ai，官方会去查。

这个顺序背后的逻辑是「先排除延迟，再排除拒付，最后才是需要人工介入的异常」。直接跳到第 4 步发邮件，多数情况下你会白等一轮回复。更细的失败分支整理在OpenRouter 充值失败怎么办。

顺带一提客服分流：官方明确技术支持的最佳途径是加入 Discord 在 #help 论坛提问，而账单与账户管理类问题走 support@openrouter.ai。充值到账属于后者。

到账之后：确认余额真的在，并盯住它

充完不等于结束。官方提供了两条查账路径：

• Activity 页面：查看历史用量，并且可以按模型、供应商、API key 三个维度过滤。
• credits API：官方提供了一个接口，返回账户余额与剩余额度的实时信息。

另外还有一个 GET https://openrouter.ai/api/v1/key 端点，用来查某个 API key 上的限额与剩余额度。官方文档给出的响应结构里包含这些字段：label、limit（该 key 的额度上限，无上限时为 null）、limit_reset（该 key 的限额重置类型，从不重置时为 null）、limit_remaining（剩余额度，无上限时为 null）、include_byok_in_limit，以及一组用量字段 usage（全时段）、usage_daily（当前 UTC 日）、usage_weekly（当前 UTC 周，从周一开始）、usage_monthly（当前 UTC 月），BYOK 用量另有一组对应字段，还有一个 is_free_tier 表示该用户此前是否付费购买过额度。响应里那个 rate_limit 对象已经废弃，官方注明可以安全忽略。

★ 注意 usage_weekly 是从周一开始算的，usage_daily 和 usage_monthly 都按 UTC 时区。如果你按本地时区做日报对账，跨时区那几个小时的差异不是 bug。

官方把限制明确分成了两类，别混：额度限制管你能花多少，超了报额度不足类错误，检查点是 GET /api/v1/key 的 limit_remaining；速率限制管你能发多少请求，超了报限流错误，检查点是错误响应上的 X-RateLimit-* 响应头。额度限制本身又有两个来源——账户余额，以及某个 API key 上可选配置的消费上限。所以你排查「为什么请求被拒」时，第一件事是分清到底是余额问题还是单 key 上限问题。

还有一条官方提示能省掉一次弯路：多开账号或多建 API key 不会改变你的速率限制，因为容量是全局管理的；官方说不同模型的速率限制不同，真遇到瓶颈可以从模型维度分散负载。想把用量盯得更细，可以配合API 成本监控怎么做。

想反悔：退款窗口与额度有效期

官方退款政策的几个要点：未使用的额度可以在交易处理后二十四小时内申请退款；如果购买后二十四小时内没有提出退款申请，未使用的额度即变为不可退。申请方式是在 Credits 页面用退款按钮操作，未使用的额度部分退回原支付方式；平台手续费不退；以及前面说过的，加密货币支付永远不可退。

额度本身也不是永久的。官方在条款里保留了在购买之后一段时间内未使用即作废的权利，具体期限以官方条款为准。

还有一个容易忽略的场景：官方在账户管理 FAQ 里说明，删除账户会导致未使用的额度丢失且无法找回，即使你之后重新创建账户也一样。所以别拿删号当「重置」手段。

团队场景：组织账户下谁有权充值

如果你在公司里用，权限边界要提前问清楚。官方文档写明：普通组织成员不能购买额度，也不能访问账单信息，有额度需求要找组织管理员。管理员这一侧才拥有为组织购买额度、查看详细账单信息、管理支付方式与开票设置的权限。

个人账户里的合格额度可以自己转给组织，官方给的步骤是：进 Settings > Credits，选择 Move credits to organization，挑一个符合条件的组织，确认金额后点 Transfer。

但转账有几条硬约束：走发票结算或欠款计费的组织无法接收转入的额度，因为它们是按发票结算而不是使用预付额度余额；此外转账对话框还会强制两条限制——新加入组织的成员需要满足一个任职时长要求，组织才能接收转账；刚刚接收过一次转账的组织，需要经过一段冷却期才能再接收下一次。这两条官方只说了机制存在，没有给具体门槛。

最后：这条路上最容易栽的四个坑

1. 首次购买卡在弹窗里——不是故障，是账单地址和支付方式还没保存完，主购买表单不会提前出现。
2. 税号设晚了——它只影响之后开出的发票，已开的不会追溯。
3. 加密货币支付按下去就没有退路——官方写死了不可退，而且那条编程接口已经返回 410 Gone，只能走网页流程。
4. 余额掉到负数会让免费模型也一起停——这一条最反直觉，很多人以为免费模型是兜底，实际不是。生产环境请认真考虑 auto top up。

把这四条避开，剩下的就是照着 Credits 页面点。真出了问题，记住官方的分流规则：技术问题去 Discord 的 #help，账单和账户问题发 support@openrouter.ai。