Verification Checklist

  • ✓Open ChatGPT web billing and the API platform billing page. Confirm which ledger posted the success and which one failed.
  • ✓Check the BIN with the issuer or virtual-card dashboard: standard credit/debit versus prepaid. OpenAI says prepaid cards cannot buy API credits.
  • ✓In Claude Console Settings > Billing, see whether the failure is “Buy credits” or a seat invoice, and whether billing country matches the card’s country of issue.
  • ✓Look at issuer activity: posted charge, pending authorization, or no record. No record usually means 3DS or region, not a low balance.
  • ✓Do not reuse one card for the subscription rail and the API-credit rail. Change rails before you change models.

1. Two charges on one card are not the same transaction

Teams treat “can this virtual card pay for AI?” as a yes-or-no. In practice the answer is often split: ChatGPT Plus renews, then Claude Console or OpenAI API credit purchase declines. In the chat box both look like an outage. On the acquiring side they are different transaction types.

OpenAI documents the split: ChatGPT and the API platform keep separate bills. A Plus charge only proves the subscription rail accepted the method. It does not prove the API organization has prepaid balance, and it does not prove the same card is allowed on the API rail. Claude splits the same way: API, playground and Claude Code default to prepaid credits. Failed requests are not billed. Buying credits is a one-off (or auto-reload) sale, not a merchant-initiated recurring Plus charge.

MIT recurring and a one-time credit purchase sit in different issuer risk buckets. The first may already have completed 3DS; later renewals reuse merchant credentials. The second can demand SCA, AVS and a card-type allowlist every time. Sampling both outcomes as “does this card work?” produces a false binary.

2. OpenAI’s hard rule: prepaid cards cannot buy API credits

Harder than “the issuer is in a mood” is a line in OpenAI’s decline article: prepaid cards cannot be used to purchase API credits. Only standard credit or debit cards are accepted for that product. Many virtual cards are prepaid BINs. They may clear Plus and still be refused at the API credit form. The issuer app may show no decline at all, because the request never reached authorization.

The same page lists blocked cross-border or online payments, billing-address mismatch, 3DS/SCA blocked by pop-up blockers, and unsupported regions. OpenAI usually does not receive a detailed decline code, so support will send you to the bank. The useful sequence is: confirm the failure is on the API ledger, check prepaid versus credit/debit, then see whether the issuer recorded an authorization. If the ledger is empty, adding balance or swapping models will not help.

Anthropic’s decline article uses a different constraint: billing address country must match the card’s country of issue, and self-serve API accounts do not accept PayPal or Venmo. A virtual card filled with the program’s registered address while the user sits in another country will fail AVS. If Claude.ai seats charge and Console credit purchase fails, check that rule before assuming “Claude is pickier than ChatGPT”.

3. Enterprise still splits seats from usage

Team plans add another cut. Anthropic states that Enterprise usage is not included in the seat fee; tokens bill at API rates. Self-serve usage draws prepaid credits and stops when they run out until someone with Billing permission buys more. Seat invoices and usage credits are two payments. Finance saying “AI is already paid this month” can coexist with a zero Console balance.

Keep four fields on the procurement log: product (ChatGPT / Claude.ai / API), rail (web subscription, app store, or Console credits), card type (credit / debit / prepaid), billing country. If those four disagree, do not add seats or move to a more expensive model. App-store subscriptions are a fifth rail: updating the web card does not cancel Apple or Google auto-renew.

4. Isolate subscription cards from API cards

The diagnostic order is: which ledger, which card type, which billing country and 3DS outcome, then whether to change the card or the rail. A long-lived card for Plus and Claude.ai, plus a standard credit/debit card for API credits, cuts the blast radius. One card for everything looks tidy and then ties Plus renewals, API top-ups, 3DS and prepaid-BIN rules to a single decline point.

If you need a dedicated card for ChatGPT Plus or Claude.ai with its own limit and expiry, a virtual-card issuer such as RDVCC can isolate each subscription and cap the single-transaction limit just above the monthly fee so API auto-reload cannot drain it. That is a sponsored link, not a claim that prepaid virtual cards will buy API credits — OpenAI already excludes prepaid cards from that product. API top-ups still need a method that matches the official card-type rule, starting with a small test charge.

5. Three questions beat “does this card work?”

Do not close the month with “is the card good?”. Ask: which bill failed, did the issuer see an authorization, and do card type plus billing country meet that rail’s hard rules? Those answers pick the next action: new card, corrected address, different rail, or finish 3DS. Swapping models without those answers is using the capability layer to patch acquiring.

Stable AI access is not luck on a PAN. It is rails managed separately. Subscription continuity and API capacity are two businesses and two risk engines. Treat them as one “AI bill” and a half-success, half-decline looks like the product flaking out.