用加密货币支付AI费用

AI如今已经成了一大批人从未打算背上的经常性账单。先是一份聊天订阅,一个编辑器席位,一个图像工具,然后——一旦开始动手构建而不只是使用——就会多出一个按token计费、以美元结算的计量API账户。这些厂商全都用同一套机制收款:绑定一张卡,自动扣款,无限期地扣下去。没有一家接受加密货币。

这道缺口正是本文要讲的全部内容。解决办法不是去找一家接受USDT的AI公司,因为几乎没有公司这么做,偶尔尝试的也大多很快放弃。真正的解法是把兑换这一步提前一环——用加密货币给一张普通的Visa或Mastercard充值,再让厂商像扣其他任何卡一样扣这张卡。接下来要讲的是该用哪张卡、实际成本是多少、为什么经常性的AI扣款会在用错预付卡时失败、为什么按量计费恰恰是预付卡完胜银行卡的那一种场景,以及一段关于卡解决不了什么的诚实说明。如果你还不熟悉底层机制,加密卡的运作原理完整讲解了从头到尾的过程。

两种计费模式,以及这个区别为什么重要

你将来会付的每一笔AI费用,都逃不出这两种形态,而它们失败的方式截然不同。提前分清这个区别,能省下后面大部分的麻烦。

订阅是一个固定的月费金额,配合一份保存下来的扣款授权:ChatGPT Plus、Claude Pro、Gemini套餐、Cursor席位、Midjourney档位。你只需授权一次,厂商此后每个月都会对同一张卡重新扣款,不再另行询问。风险不在第一次扣款——而在第四次,那时卡上余额已经跌破扣款金额,续费在无人察觉的情况下悄悄失败。

额度购买则是一次性扣款,买下一笔你之后慢慢消耗的余额:OpenAI和Anthropic的API额度、OpenRouter、Replicate、Together、Fal。这里没有需要长期履行的扣款授权,所以日后不存在会失败的东西——但这些厂商大多提供一个自动充值开关,一旦余额跌破某个阈值就会重新购买额度,这会悄悄把一次性扣款变成一笔金额不可预测的经常性扣款。这个开关是页面上最重要的一项设置,下文会专门讲到。

规律很明显:几乎所有场景都落在Visa Corporate号段上,这并非巧合——BIN 472305正是专为经常性的软件、云服务和API扣款而设,能在Stripe、Recurly和Chargebee上顺利清算,而这三家处理商合计承担了大多数AI账单的清算。有两个例外值得记住:iPhone应用内订阅是一笔Apple扣款,应该用为钱包调校的Visa Platinum;而真正重度的API采购会触及Corporate号段单笔$5,000的上限,这时单笔$10,000、每月$100,000的Visa Business号段才是更合适的选择。

实际要花多少钱

适用两项费用,而且全部公开。不会按笔收费,不会按月收费,把卡闲置在两个项目之间也不会收费。下面用一个具体案例把整个费用结构列出来——一个每月$20的席位维持一整年,也就是$240的AI支出:

值得多停留一下的是第四行。人们通常是拿外币兑换差价来比较加密卡的优劣,因为大多数人用它购买的东西都以本国货币计价,1.5%这笔差价躲不掉。AI恰恰相反:OpenAI、Anthropic、Google、Cursor,以及这个品类里几乎所有厂商都以美元计费,而卡上余额在发卡商那里本来就是以美元计价的。这笔差价干脆就不会触发。这让AI支出在结构上成了放在这张卡上最便宜的一类消费——第一个月之后的边际成本就是统一2%,再没有别的。完整的费率表在定价页面,无月费加密卡则整体讲解了经常性成本这一面。

有两道门槛,最好提前规划好,而不是临时撞上。最低充值金额是$100,所以给一个$20的席位充值,意味着至少要往账户里放$100,再分五个月慢慢用掉——如果只订阅这一项服务会显得别扭,但只要你有三项订阅或者一个API账户,这就完全不是问题。卡片加载的下限是$20、上限是$5,000,所以一笔较大的一次性额度购买需要分两次加载,而不是一次。这两项都不是费用,而是人们往往在最不凑巧的时候撞上的上限。

只需设置一次

从零开始,整个过程大约四分钟,其中大部分时间都花在等待链上确认。顺序有一点讲究:先充值、再发卡,因为一张没有余额的卡,第一次授权就会失败。

1. 开户。一个邮箱和一个密码。不需要证件、不需要身份验证、不需要KYC——不管是这一步,还是平台上的任何其他环节都是如此。
2. 充值。八种资产任选一种,最低$100,转账达到最终确认后,会按当时的实时汇率全额入账。选一条你能用的、手续费最低的链。
3. 发一张虚拟Visa Corporate,BIN 472305。$2,几秒钟内即可激活。给它标注上它要支付的厂商——一张服务对应一张卡,这个习惯只要你哪天需要冻结一张卡,就立刻能看出价值。
4. 加载的金额要高于价格本身,而不是刚好持平。第一次授权的金额经常会高于标价。$20的席位,加载$30;$100的额度购买,加载$110。
5. 把卡信息填进厂商的账单表单。卡号、有效期、CVC。地址栏就按卡片面板里显示的内容填,如果出现3-D Secure验证步骤,就完成它。
6. 把卡的上限设成你打算花的金额。不要更多。这一步能把一张卡变成一份预算,也是下面这一节要完整讲的内容。

正式扣款之前的验证扣款

大多数AI厂商会先验证一张卡,然后才会真正扣款,这会绊倒那些卡上余额刚好等于订阅价格的人。验证有两种形式。一种是$0的账户状态检查,它只是向发卡商询问这张卡是否存在、是否有效,不涉及资金转移,而且悄无声息地就通过了。另一种是$1的授权,它会真的预留一美元,持有几天后从不完成扣款——但在这几天里,这一美元是花不了的。

一张卡为$20的订阅刚好加载了$20,一旦出现$1的预授权持有,能用于扣款的就只剩$19,面对$20的扣款,续费会因为差了一美元的余额不足而被拒绝。解决办法就是上面的第四步,而且不花一分钱:多加载一点缓冲。免费试用会让这个问题更突出,因为卡是在注册时完成验证的,直到试用结束才会真正扣款,而这往往是一个月之后——到那时,卡上需要备好全额,而不是验证时的零余额。

经常性AI扣款为什么会失败,每种失败长什么样

一次拒绝是一条信息,而不是一次故障,在AI账单上,这条信息几乎总是下面五种之一。正确读懂它只要几秒钟;瞎猜的话能耗掉一下午。

第三行才是决定这套方法到底行不行得通的关键。很大一部分预付卡会在余额被检查之前,就被AI厂商直接拒绝,原因是处理商识别出这个BIN属于通用预付号段,拒绝的是这整个类别,而不是这一张卡具体的情况。这是处理商层面的政策决定,不是你的卡出了问题,余额加再多也改变不了。这也正是BIN 472305存在的意义:一个能以商业卡的身份、而不是匿名塑料卡的身份,在Stripe、Recurly和Chargebee上顺利清算的号段。如果遇到拒绝,原因又不明显,为什么你的虚拟卡会被拒绝提供了完整的排查思路,按最值得检查的顺序逐一列出。

按量计费:预付卡不再是将就的选择

前面讲的都是等价性——让一张加密货币充值的卡,表现得和银行卡一样。这一节正好相反:这是唯一一个预付卡明显优于它所替代的银行卡的场景,单这一节内容就值得单独写一篇指南。

一个计量API账户天生没有上限。你是按token计费的,单价小到几乎让人感觉不要钱,而普通的一周和一张四位数账单之间,唯一的防线就是你自己的注意力。每家厂商都提供某种软性保护——用量提醒、月度预算、硬性限额——但这些说到底都是厂商自己承诺不再向你扣款,由厂商执行,发生在厂商这一侧的计量表上。它们大多数时候是管用的。但它们也正是那种会在凌晨三点失灵的东西——当一个重试循环发现,一次失败的请求依然是一次要计费的请求。

预付卡是完全不同性质的一种限制。它不是一句不再扣款的承诺,而是从物理上就不可能被扣走更多。自动充值没办法从一张只有$40的卡里扣走$200。一个失控的智能体,花费不可能超过加载的金额。厂商那一侧的计费bug,也没办法透支一张本来就没有透支额度的卡,因为它背后根本没有一个账户可以伸手去够。不管你加载了多少,那就是能被扣走的上限,而且这个保证是在卡组织网络层面强制执行的,不是写在厂商的计费代码里。

• 按月加载,而不是按季度。卡上大致保留到下次加载之前你打算花掉的金额就够了。把多余的部分卸载回账户是免费的,所以把额度控制得紧一点不会有任何成本。
• 是否开启自动充值,要想清楚再决定。关闭意味着额度用完API就停——这是一种硬停止,通常也是正确答案。开启意味着充值会自动触发,于是真正起限制作用的是卡上的余额,而不是你输入的那个阈值。
• 生产环境和实验环境用不同的卡。每张只要$2。一个在为实验预留的卡里疯狂消耗的提示词循环,不应该有机会碰到支撑线上服务运行的那笔余额。
• 不仅要盯着月度上限,单笔上限也要留意。Visa Corporate单笔授权上限是$5,000、每月$50,000;超出这个范围的大额一次性额度购买,应该用单笔$10,000、每月$100,000的Visa Business号段。
• 对账要看卡,而不是看仪表盘。卡的交易记录才是真正从你这里扣走的金额,这和用量页面估算出来的数字并不总是一致。

用代码来做这件事

如果花钱的是一个程序而不是一个人,上面这一整套流程就能压缩成三次调用。发卡、设上限、把卡号交给它——还是同样的基本操作,只是不需要浏览器。本文里描述的每一个动作,都只是一次REST调用或者一次MCP工具调用。

curl -X POST https://api.cryptocardium.com/v1/cards \
  -H "Authorization: Bearer ck_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "type": "virtual", "bin": "472305", "load_usd": 200 }'

{
  "id": "card_8f2a1c",
  "bin": "472305",
  "last4": "4417",
  "status": "active",
  "balance_usd": 200.00
}

一次调用就能完成发卡和加载,所以在卡号存在之前,上限就已经设定好了。再进一步收紧限制,让这张卡除了它要支付的那个厂商之外,在任何地方都用不了——即便额度限制已经感觉够用了,MCC白名单依然值得设置,因为一张锁定在AI厂商计费所用商户类别上的卡,不管卡号落到谁手里,都没法在一家商店里被刷走。

curl -X PATCH https://api.cryptocardium.com/v1/cards/card_8f2a1c/limits \
  -H "Authorization: Bearer ck_live_…" \
  -d '{ "monthly_usd": 200, "daily_usd": 50 }'

curl -X PATCH https://api.cryptocardium.com/v1/cards/card_8f2a1c/mcc \
  -H "Authorization: Bearer ck_live_…" \
  -d '{ "mcc_allow": ["5818", "7372"] }'

curl -X POST https://api.cryptocardium.com/v1/cards/card_8f2a1c/load \
  -H "Authorization: Bearer ck_live_…" \
  -d '{ "amount_usd": 100 }'   # reload later, same ceiling

在锁定任何东西之前,先确认你的厂商实际使用的商户类别——去一笔真实交易上读取mcc字段,而不是凭猜测,因为一份设错的白名单产生的拒绝,看起来会和资金不足的问题一模一样。把Webhook订阅到transaction.declined和authorization这两个事件,智能体就能在一笔扣款被拒的瞬间做出反应,而不是等到下一次轮询才发现;这些事件都经过HMAC签名,并且采用至少一次送达的机制。

// POST to your webhook URL
{
  "event": "authorization",
  "card_id": "card_8f2a1c",
  "amount_usd": 200.00,
  "merchant": "Anthropic",
  "mcc": "5818",
  "result": "approved"
}
// header: X-Signature: sha256=…

对于那些自己申领卡片、自己付款,而不是被人交一张卡的智能体,更完整的模式——密钥的权限范围、按智能体设置上限、授权在任务进行到一半被拒绝时该怎么办——在面向AI智能体的虚拟卡API里。对于Claude Desktop和Cursor这类兼容MCP的客户端,同样的能力会以类型化工具而非HTTP接口的形式出现,详见加密卡MCP服务器,用加密货币实现智能体支付则讲解了这两者背后共同的设计问题。端点级别的参考文档在文档里。

厂商看到什么,你的银行又看不到什么

在AI厂商眼里,这只是一笔来自商业BIN的Visa授权,仅此而已。资金来源不会被传输,无法从卡号反推出来,商户的处理商也没有任何办法去询问这一点。中间同样没有银行参与:充值是从一个由你自己掌控的钱包发起的链上转账,消费则是针对发卡商那里一笔美元余额进行的一次普通授权,你开户的任何机构都不会介入这笔交易,也不会为它生成一条对账单记录。

代价也应该像好处一样被直白地说清楚。因为从不收集地址信息,地址核验检查就没有可以比对的对象,严格的AVS核验会把这种缺失读成一次失败。实际情况中,这种问题在AI账单上很少发生——AVS主要是美国零售场景中的现象,主流AI厂商也不会严格执行它——但这确实是一张无需身份的卡在结构上的唯一弱点,提前了解总好过在结账时才发现。免KYC加密卡详解讲清楚了无身份发卡意味着什么、不意味着什么,匿名订阅把同样的思路延伸到了流媒体、VPN,以及其他所有按月计费的服务上。

一张卡解决不了什么

有两件事,而且都值得直说,因为互联网上很少有人愿意直说。

第一件是准入资格。如果某个AI厂商没有在你所在的国家提供服务,这道限制存在于注册环节和服务条款里,而不是支付表单里,出示一张发行方不同的卡也改变不了你和这家厂商之间的关系。试图绕开它,会让账户以及里面的任何额度余额都面临风险。这张卡真正能解决的,是更常见的一种相邻情形:服务本身对你开放,但你本地的卡因跨境美元计费被拒、你的银行拦截了这个商户类别,或者你压根就没有卡。那才是一个支付问题,而支付工具能解决的正是支付问题。

第二件是退款。厂商退回的钱,会退回到它原本扣款的那张卡上,这一点没有问题,但会比银行退款慢,而且前提是那张卡还存在。如果你预期会收到退款——比如买错了年费档位、额度购买重复下单——在退款到账之前,先别关闭那张卡,而不是一取消服务就顺手把卡也注销了。正式的争议申诉可以免费代你提出,但争议是以周为单位的最后手段,不是常规路径。

一份简明清单

1. 发一张虚拟Visa Corporate,BIN 472305。$2,几秒钟内激活,这个号段就是为这类扣款调校的。
2. 每个厂商一张卡。成本很低,而且能让之后每一个决定——取消、设上限、更换——都变成一次点击,而不是一场交涉。
3. 加载比价格高20%的金额,而不是刚好持平。验证预授权和结账时加收的税费,是首次扣款失败最常见的两个原因。
4. 如果出现3-D Secure验证,就完成它。中途放弃看起来像是被拒绝,但其实不是。
5. 在启用API密钥之前,先想清楚要不要开自动充值,而不是事后再想。关闭是硬停止;开启则让卡上余额成为真正起作用的限制。
6. 设置每日和每月上限,如果卡由代码使用,再加上MCC白名单。现在花一分钟,换来的是日后不会收到一张没有上限的账单。
7. 在续费日之前充值,而不是等失败之后才充值。AI账户一旦错过续费,通常是降级,偶尔还会丢失历史记录。
8. 在预期的退款到账之前,别关闭这张卡。退款会退回原卡,一张已注销的卡没有地方接收它。

把这些都做到,基本上就覆盖了用加密货币支付AI费用可能出问题的全部环节,唯独厂商准入资格除外——那不是一个支付问题,也不是支付工具能解决的。

相关阅读

想了解这一切背后的清算机制,可以从加密卡的运作原理开始。想了解充值,以及那个经常让人栽跟头的确认时机问题,可以看用USDT给Visa卡充值。想把同样的思路用到流媒体、VPN和其他所有按月计费的服务上,可以看用于匿名订阅的虚拟卡。如果扣款被拒,为什么你的虚拟卡会被拒绝按最值得排查的顺序给出了诊断方法。如果花钱的是一个智能体而不是一个人,接下来该读的是面向AI智能体的虚拟卡API和加密卡MCP服务器这两篇,最适合AI智能体的加密卡则对这个领域做了比较。完整的文章库在指南中心,五种BIN的介绍在卡片页面。