foxhound
Sign in

Decline code

Call Issuer

Stripe declined this payment with an instruction for the cardholder to call their bank before the charge can go through. This code puts the next step in the cardholder's hands, not the merchant's. Stripe's official definition is: "the card was declined for an unknown reason." In practice, this code typically means the issuing bank wants to speak with the cardholder directly before allowing the charge, often tied to a security hold, a verification step, or something on the account that only the cardholder can clear by contacting the bank themselves. The merchant has no visibility into what specifically triggered the hold and no way to resolve it directly.

Back to decline codes
call_issuerNo automatic retry
Draft content: this page's explanatory copy is Pass 3 template writing pending a dedicated content pass. The classification badge above and the recovery behavior described below are live, not draft: both come directly from the recovery engine.

Why it happens

On recurring billing, `call_issuer` can surface for reasons like a bank's security system flagging the transaction for extra verification, a card that was recently reissued and needs a confirmation call, or an account-level hold the bank placed for reasons unrelated to this specific merchant at all. It's frustrating precisely because the fix sits entirely outside the merchant's control: only the cardholder, on the phone with their own bank, can typically clear it.

How to fix it

Not productively until the cardholder has actually contacted their bank. An automated retry with no change in circumstances will most likely hit the same hold again, since nothing about a repeated charge attempt satisfies whatever verification the bank is waiting on. The customer needs to be told, clearly, that their bank wants to hear from them directly. A vague "your payment failed, please update your card" message is the wrong message here, since updating the card won't help if the same bank places the same hold on the replacement. Be specific in the customer communication: their bank has asked them to call, and once they've done that, the charge (or a retry of it) should go through normally. Giving a specific, accurate explanation here tends to produce faster resolution than a generic dunning message would.

How Foxhound recovers it

This code has no dedicated bucket in the recovery engine's classification sets, so it fails closed rather than defaulting to a silent retry: no repeat charge runs against a code Foxhound cannot classify. Recovery goes straight to the same email sequence expired cards get, carrying the hosted card-update link, until this code earns its own bucket.

Questions

  • Call their bank. The issuer has placed a hold that typically requires the cardholder to verify something directly with them before the charge will go through.

  • Usually not. If the customer just adds a new card without calling their bank, the same kind of hold can reappear, since the issue is with the bank's verification process, not the card number itself.

  • Not a purpose-built one yet. Foxhound's classifier has no named case for `call_issuer`, so it falls to the unknown bucket, which fails closed rather than retrying automatically: no repeat charge runs, and recovery goes straight to the standard card-update email instead of a message asking the customer to call their bank specifically.

  • Yes, if the customer has contacted their bank in the meantime and the hold has been cleared, a later retry with the same card can succeed without needing a new payment method at all.

  • Not necessarily. It's often a routine security or verification hold from the issuing bank rather than any indication of wrongdoing by the cardholder or the merchant.

See what this looks like on your account

The free audit shows what Stripe already recovered and what is still dying, no signup required.

Run your free audit