Paying for AI with crypto

AI is now a recurring bill for a great many people who never planned on having one. A chat subscription, an editor seat, an image tool, and then — the moment anything gets built rather than used — a metered API account that charges by the token and settles in dollars. Every one of those vendors bills through the same mechanism: a card on file, charged automatically, indefinitely. None of them accepts cryptocurrency.

That gap is the whole subject of this guide. It is not solved by finding an AI company that takes USDT, because essentially none do and the ones that dabble tend to stop. It is solved by moving the conversion one step earlier — funding an ordinary Visa or Mastercard from crypto and letting the vendor charge that card like any other. What follows is which card to use, what it actually costs, why recurring AI charges fail on the wrong prepaid card, the reason usage-based billing is the one case where prepaid beats a bank card outright, and an honest note on what a card cannot fix. If you have not met the underlying mechanics before, how crypto cards work covers the settlement path end to end.

Two billing models, and why the difference matters

Every AI charge you will ever make falls into one of two shapes, and they fail in completely different ways. Getting this distinction right in advance saves most of the trouble later.

A subscription is a fixed monthly amount with a stored mandate: ChatGPT Plus, Claude Pro, a Gemini plan, a Cursor seat, a Midjourney tier. You authorise once and the vendor re-charges the same card every month without asking again. The risk is not the first payment — it is the fourth, when the card has drifted below the amount and the renewal quietly fails.

A credit purchase is a one-off charge that buys a balance you then burn through: OpenAI and Anthropic API credit, OpenRouter, Replicate, Together, Fal. There is no recurring mandate, so nothing can fail later — but most of these vendors offer an auto-recharge switch that re-buys credit whenever the balance falls below a threshold, which quietly turns a one-off into a recurring charge of unpredictable size. That switch is the single most important setting on the page, and it is covered further down.

The pattern is that almost everything lands on the Visa Corporate range, and that is not a coincidence — BIN 472305 exists specifically for recurring software, cloud and API charges, and clears cleanly on Stripe, Recurly and Chargebee, which between them process most AI billing. The two exceptions are worth knowing: an in-app iPhone subscription is an Apple charge and belongs on the wallet-tuned Visa Platinum, and genuinely heavy API buying runs into the Corporate BIN's $5,000 per-transaction ceiling, where the Visa Business range at $10,000 per transaction and $100,000 per month is the better fit.

What it actually costs

Two fees apply and both are published. There is nothing charged per transaction, per month, or for leaving a card idle between projects. Here is the whole stack against a concrete case — one $20-a-month seat kept alive for a year, which is $240 of AI:

The line worth pausing on is the fourth. A crypto card is usually compared on its foreign-exchange margin, because most of what people buy with one is priced in their own currency and the 1.5% is unavoidable. AI is the opposite: OpenAI, Anthropic, Google, Cursor and nearly every vendor in the category bill in US dollars, and the card balance is already denominated in USD at the issuer. The margin simply never fires. That makes AI spend structurally the cheapest category to put on this card — the marginal cost after the first month is a flat 2% and nothing else. The complete fee sheet is on the pricing page, and crypto cards with no monthly fees covers the recurring-cost side in general.

Two floors are worth planning around rather than discovering. The minimum top-up is $100, so funding a single $20 seat means putting at least $100 into the account and drawing it down over five months — awkward for exactly one subscription, irrelevant the moment you have three or an API account. And the minimum card load is $20 with a maximum of $5,000, so a large one-off credit purchase is two loads rather than one. Neither is a fee; both are ceilings people meet at the worst moment.

Setting it up, once

From a standing start this is about four minutes, most of which is waiting for a confirmation. The order matters slightly: fund before you issue, because a card with no balance is a card that fails its first authorisation.

1. Open an account. Email and password. No documents, no identity verification, no KYC — for this or for anything else on the platform.
2. Top up. Any of the eight assets, minimum $100, credited in full at the spot rate once the transfer reaches finality. Use the cheapest rail available to you.
3. Issue a virtual Visa Corporate, BIN 472305. $2, live in seconds. Label it for the vendor it will pay — one card per service is a habit that pays for itself the first time you need to kill one.
4. Load it above the price, not at it. A first authorisation is frequently larger than the sticker figure. For a $20 seat, load $30; for a $100 credit purchase, load $110.
5. Enter it in the vendor billing form. Number, expiry, CVC. Leave the address fields as your card panel shows them and complete the 3-D Secure step if one appears.
6. Set the card's ceiling to what you intend to spend. Not more. This is the step that turns a card into a budget, and it is the whole subject of the section below.

The verification charge before the real one

Most AI vendors validate a card before they ever bill it, and this trips people who loaded exactly the subscription price. The validation takes one of two forms. A $0 account-status check asks the issuer whether the card exists and is live without moving money, and passes silently. A $1 authorisation actually reserves a dollar, holds it for a few days and never captures it — but for those days that dollar is not spendable.

On a card loaded with precisely $20 for a $20 subscription, a $1 hold leaves $19 against a $20 charge, and the renewal is refused for insufficient funds by a margin of one dollar. The fix is the fourth step above and costs nothing: load a small buffer. Free trials make this sharper still, because the card is validated at signup and not charged until the trial ends, which is often a month later — by which time the card needs to hold the full price, not the zero it was validated at.

Why recurring AI charges fail, and what each failure looks like

A decline is a message rather than a malfunction, and on AI billing the message is nearly always one of five things. Reading it correctly takes seconds; guessing at it takes an afternoon.

The third row is the one that decides whether this works at all. A large share of prepaid cards are refused by AI vendors before any money is checked, because the processor recognises the BIN as a generic prepaid range and rejects the category rather than the card. That is a policy decision at the processor, not a fault in your card, and no amount of balance changes it. It is also precisely what BIN 472305 is for: a range that clears Stripe, Recurly and Chargebee as a business card rather than as anonymous plastic. If something is refused and the cause is not obvious, why your virtual card gets declined is the full diagnostic, in the order worth checking.

Usage-based billing: where prepaid stops being a compromise

Everything above is about parity — getting a crypto-funded card to behave like a bank card. This section is the opposite: the one place where a prepaid card is straightforwardly better than the bank card it replaces, and it is worth the whole guide on its own.

A metered API account has no natural ceiling. You are billed by the token, the rate is small enough to feel free, and the only thing standing between an ordinary week and a four-figure invoice is your own attention. Every vendor offers soft protection — usage alerts, monthly budgets, hard limits — and all of them are the vendor's promise to stop charging you, enforced by the vendor, on the vendor's side of the meter. They generally work. They are also the thing that fails at three in the morning when a retry loop discovers that a failed request is still a billable request.

A prepaid card is a different kind of limit entirely. It is not a promise to stop charging; it is a physical inability to be charged. Auto-recharge cannot pull $200 from a card holding $40. A runaway agent cannot spend past the load. A billing bug on the vendor's side cannot overdraw a card that has no overdraft, because there is no account behind it to reach into. Whatever you loaded is the maximum that can ever be taken, and that guarantee is enforced at the card network rather than in the vendor's billing code.

• Load the month, not the quarter. The card should hold roughly what you intend to spend before the next reload. Unloading the excess back to your account is free, so there is no cost to keeping it tight.
• Decide about auto-recharge deliberately. Off means the API stops when credit runs out — a hard stop, and usually the right answer. On means a top-up fires automatically, so the card balance becomes the real limit rather than the threshold you typed in.
• Keep production and experiments on separate cards. $2 each. A prompt loop burning through a card reserved for experiments should not be able to reach the balance that keeps a live service running.
• Watch the per-transaction ceiling, not just the monthly one. Visa Corporate authorises $5,000 per transaction and $50,000 per month; a single large credit purchase above that belongs on the Visa Business range at $10,000 and $100,000.
• Reconcile against the card, not the dashboard. The card's transaction list is what was actually taken from you, which is not always what the usage page estimates.

Doing it from code

If the thing spending the money is a program rather than a person, the whole loop above collapses into three calls. Issue a card, cap it, and hand it the number — the same primitives, without a browser. Every action described in this guide is a single REST call or a single MCP tool invocation.

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
}

One call issues the card and loads it, so the ceiling is set before the number exists. Constrain it further so the card is useless anywhere except at the vendor it exists to pay — the MCC allow-list is worth setting even when the limits already feel sufficient, because a card locked to the merchant categories AI vendors bill under cannot be spent at a shop, whatever happens to the number.

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

Confirm the categories your vendors actually bill under before locking anything down — read the mcc field on a real transaction rather than assuming it, because a wrong allow-list produces a decline that looks exactly like a funding problem. Subscribe a webhook to transaction.declined and to authorization and an agent can react at the moment a charge is refused instead of discovering it on the next poll; the events are HMAC-signed with at-least-once delivery.

// 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=…

For an agent that provisions and pays for itself rather than being handed a card, the fuller pattern — key scoping, per-agent ceilings, what to do when an authorisation is refused mid-task — is in the virtual card API for AI agents. For MCP-compatible clients such as Claude Desktop and Cursor, the same capabilities arrive as typed tools rather than HTTP in the crypto card MCP server, and agentic payments with crypto covers the design questions underneath both. Endpoint-level reference is in the documentation.

What the vendor sees, and what your bank does not

To the AI vendor this is a Visa authorisation from a business BIN, and that is the entire extent of it. The funding path is not transmitted, not derivable from the card number, and not something the merchant's processor has any way to ask about. There is no bank in the middle of it either: funding is an on-chain transfer from a wallet you control, spending is an ordinary authorisation against a USD balance at the issuer, and no institution you hold an account with is party to the transaction or generates a statement line for it.

The trade-off deserves stating as plainly as the benefit. Because no address is ever collected, there is nothing for an address-verification check to match against, and a strict AVS check will read that absence as a failure. In practice this rarely bites on AI billing — AVS is largely a US retail phenomenon and the major AI vendors do not enforce it hard — but it is the one structural weakness of an identity-free card and it is better known in advance than discovered at a checkout. No-KYC crypto cards explained covers what identity-free issuance does and does not mean, and anonymous subscriptions extends the same pattern to streaming, VPNs and everything else that bills monthly.

What a card does not fix

Two things, and both are worth being blunt about because the internet is not.

The first is eligibility. If an AI vendor does not offer its service in your country, that restriction lives in signup and in the terms of service, not in the payment form, and presenting a differently-issued card does not change your standing with the vendor. Attempting to route around it risks the account and any credit balance sitting in it. What a card genuinely solves is the far more common adjacent case: the service is available to you, but your local card is refused for cross-border USD billing, your bank blocks the merchant category, or you have no card at all. That is a payment problem, and a payment instrument fixes it.

The second is refunds. Money returned by a vendor goes back to the card it came from, which is correct and also slower than a bank refund and dependent on that card still existing. If you expect a refund — a mis-sized annual plan, a duplicated credit purchase — leave the card open until it lands rather than cancelling it the moment you cancel the service. Formal disputes are filed on your behalf at no charge, but a dispute is a last resort measured in weeks, not the routine path.

A short checklist

1. Issue a virtual Visa Corporate, BIN 472305. $2, live in seconds, the range tuned for exactly this kind of charge.
2. One card per vendor. Cheap, and it makes every later decision — cancel, cap, replace — a one-click operation instead of a negotiation.
3. Load 20% above the price, not exactly at it. Validation holds and checkout tax are the two most common first-charge failures.
4. Complete the 3-D Secure challenge if one appears. Abandoning it looks like a decline and is not one.
5. Decide about auto-recharge before you enable an API key, not after. Off is a hard stop; on makes the card balance the real limit.
6. Set daily and monthly ceilings, and an MCC allow-list if the card is used by code. A minute now, against an unbounded bill later.
7. Top up before the renewal date, not after the failure. A missed renewal on an AI account is usually a downgrade, occasionally a lost history.
8. Keep the card open until any expected refund lands. Refunds return to the card, and a cancelled card has nowhere to put them.

Done together, these cover the entire failure surface of paying for AI with crypto except vendor eligibility — which is not a payment problem and is not solved by a payment instrument.

Related reading

For the settlement mechanics beneath all of this, start with how crypto cards work. For funding and the confirmation timing that catches people out, funding a Visa card with USDT. For the same pattern applied to streaming, VPNs and everything else that bills monthly, a virtual card for anonymous subscriptions. If a charge is refused, why your virtual card gets declined is the diagnostic in the order worth checking. If the thing spending the money is an agent rather than a person, the virtual card API for AI agents and the crypto card MCP server are the two to read next, and the best crypto card for AI agents compares the field. The whole library is on the guides hub, and the five BINs are described on the cards page.