Card Binds Fine but Every Charge Fails: A Full Investigation of a Claude API Top-Up Failure (Root Cause: 3DS)

This is the first article in our Case Files series. Every case comes from a real support ticket: we reconstruct the symptoms, the investigation path, the root cause and the resolution, with all identifying details anonymized. This one covers the most confusing kind of payment failure —the card binds just fine, yet every charge fails, and neither side shows a useful error.

1. The Case

A user opened a virtual card to top up their Anthropic Console (Claude API) account balance. Here is how it went:

• Added the card in Anthropic Console — binding succeeded, the platform showed the card as saved
• Initiated a balance top-up — payment failed, and kept failing on every retry
• The platform-side error was vague: payment not completed, no concrete reason given
• The user filed a ticket: “I can bind the card, but I can’t get charged”

From the user’s point of view this looks unsolvable: the card is fine (binding proved it), the balance is sufficient, and the platform won’t say why. Open another card? Same BIN, same outcome — because the problem was never about “this particular card”.

2. Key Clue: Not a Single Failure Record on the Card Side

After receiving the ticket, we first pulled the card’s transaction history. A “failed charge” normally leaves a declined authorization on the card side, complete with a decline reason (insufficient funds, risk control, restricted merchant category…) — you fix whatever the reason says. But this card’s history looked like this:

That is the most valuable diagnostic fingerprint in this case: an ordinary declined charge always leaves a failure record on the card side; zero records means the payment broke off before it ever reached the card issuer. Between the card and the merchant there is a checkpoint we cannot see from the card side.

3. The Full Investigation

1. Check card status: card active, limit sufficient, not frozen — the card itself is ruled out.
2. Pull all authorization records: as above, only the successful $0 binding verification, no failed authorizations — “declined by risk control” is ruled out; the failure happens before authorization.
3. Identify the payment processor: the Anthropic Console top-up page is processed by Stripe (visible right on the payment page). For some transactions Stripe enforces 3DS verification (3-D Secure, the second-factor check for online card payments) — especially where its risk model wants extra confirmation.
4. Check the BIN’s 3DS capability: we queried the card issuer for this card’s 3DS configuration — the answer came back: this card product does not support 3DS. At this point the whole chain lined up.

4. Root Cause: Binding Verification and Real Charges Go Through Different Security Lanes

The complete failure chain:

• At binding time: the platform only runs a $0 (or micro-amount) verification authorization, which normally does not trigger 3DS → passes cleanly, card saved
• At charge time: Stripe’s risk engine requires 3DS on this transaction → the BIN does not support 3DS → the verification step cannot complete → the payment fails before an authorization is ever initiated
• Because the failure happens at the 3DS challenge stage, the card issuer never sees the transaction (hence zero card-side records), and the merchant can only show a generic “payment not completed”

In one sentence: binding successfully ≠ being chargeable. Binding verification only proves the card is real and alive; a real charge still has to pass the extra security lane of risk control plus 3DS, and whether that lane appears — and whether you can get through it — depends on the merchant’s payment processor policy and the BIN’s capability, not on whether binding succeeded.

5. Which Scenarios Hit the Same Wall

Any combination of a merchant that enforces (or is likely to trigger) 3DS and a BIN without 3DS support reproduces exactly these symptoms. Scenarios that trigger 3DS more often, in our experience:

• Merchants on Stripe with stricter risk scoring (this case’s Anthropic Console top-up is one)
• Large or first-time transactions (risk engines prefer a second check)
• European merchants (under SCA strong-authentication regulation, 3DS is almost always on)

Conversely, the very same card works perfectly at merchants that do not enforce 3DS (most subscription billing) — which is why users feel the card “works on and off”; it is actually merchant policy that differs.

6. Same Symptoms? A Three-Step Self-Check

1. Check the card side for failure records: log in to your dashboard and open the card’s transaction detail. If there are decline records → handle the stated reason (seeTop 10 Reasons Virtual Cards Get Declined); zero records → most likely blocked by 3DS or pre-authorization risk checks — go to the next step.
2. Confirm the binding verification once succeeded: if the $0 check passed at binding but real charges never show up in the card history, it matches this case — a 3DS-class pre-failure is essentially confirmed.
3. Look at the merchant’s payment processor: if the payment page shows Stripe and the scenario is on the strict side (top-ups, large amounts, first charges), 3DS is likely. Switching cards will not help here — what you need is a BIN that supports 3DS.

7. Takeaways

• “It binds” only proves the card is real — not that it can be charged. To judge whether a card works for a platform, look at whether real charges succeed, not whether binding succeeds
• Zero failure records on the card side is the key fingerprint separating “declined” from “3DS pre-failure” — check there first
• Our current BINs do not support 3DS yet, so they are not suitable for scenarios that enforce it (such as this case’s Anthropic Console top-up). A 3DS-capable BIN is being onboarded, and its launch will be announced in thechangelog — until then we prefer telling you the limitation upfront over letting you burn retries
• For payment failures you cannot pin down, open a ticket with the platform name and a rough timestamp — from the card-side records we can quickly locate which link in the chain broke

For general payment-failure triage, see thePayment Failure Troubleshooting Guide; for a typical subscription-decline case, seeWhat to Do When a ChatGPT Plus Upgrade Is Declined.

8. FAQ

Binding succeeded, so the card is fine — why do charges still fail?

Binding verification ($0 authorization) and real charges go through different validation chains. A real charge can be required by the merchant’s risk engine to complete 3DS, which binding verification usually skips. When the BIN does not support 3DS, you get “binds fine, charges always fail”.

How do I tell whether a failure is caused by 3DS?

The most reliable fingerprint is the card-side transaction history: an ordinary decline leaves a failed authorization record; a 3DS pre-failure leaves nothing at all, because the transaction never reached the card issuer.

Would switching to another card fix it?

Any number of cards from the same BIN will end the same way — 3DS support is a BIN-level capability, not a per-card property. There are only two ways out: a BIN that supports 3DS, or a payment path at that merchant which does not enforce 3DS.

Will the money I deposited onto the card be lost?

No. A 3DS pre-failure happens before any charge, so no funds are taken; the card balance stays intact, everything you deposited remains credited to the card and can be used on platforms that do not enforce 3DS.

Based on a real support ticket from July 2026, with identifying details anonymized. Author: RDVCC Payments Research Team · Reviewed by: Steven Cai