foxhound
Sign in

Decline code

Revocation of Authorization

Stripe declined this payment because the cardholder told their bank to stop authorizing recurring charges from this specific merchant. This is not a card problem or a balance problem. It is the customer's bank acting on an instruction the customer gave directly. Stripe's official definition is: "the card was declined for an unknown reason." What sits behind that generic label is specific and important: the cardholder has explicitly revoked their authorization for your business to charge this card, typically by calling their bank and asking them to block future charges from your merchant ID. The card itself may still work fine everywhere else. It just won't work for you.

Back to decline codes
revocation_of_authorizationCancel or update
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

This code is almost exclusively a subscription-billing phenomenon, since it requires an existing standing authorization for recurring charges to revoke in the first place. Customers use this route when they want to stop being charged and either couldn't cancel through your product, didn't know how, or decided going through their bank was faster than dealing with your cancellation flow directly. It is a strong, explicit signal of intent to stop paying.

How to fix it

Not in good faith, and this is the most important point in this entire batch of codes. The cardholder has explicitly told their bank to block recurring charges from your business. Continuing to retry, or continuing to charge through workarounds, creates real chargeback risk and, more basically, ignores a direct instruction from the customer. Stop charging this customer through automated retries. This is a case where industry best practice is unambiguous: treat it as a hard stop and reach out to the customer directly rather than relying on any retry schedule. Find out why they revoked authorization: unwanted charges, a cancellation that didn't go through, a dispute they didn't realize they could resolve with you directly. If they want to continue as a customer, get a fresh, explicit payment method and authorization from them rather than assuming the old relationship can just resume. If they don't want to continue, treat the account as churned and stop billing entirely.

How Foxhound recovers it

This code means the cardholder went to their bank and revoked the standing authorization for recurring charges, an explicit instruction to stop. Foxhound treats it as a hard stop rather than a recovery to push on: no retry runs (the bank has blocked charges) and no multi-step dunning sequence goes out. Instead a single, respectful email offers a clean choice, cancel and let the subscription end, or add a fresh payment method if they meant to keep it. After that one message the sequence holds, so a customer who chose to leave is never chased.

Questions

  • No. The card can still work everywhere else. The cardholder specifically told their bank to block charges from your business.

  • Often because they couldn't find a cancellation flow, didn't trust it, or found calling their bank faster or more reliable than dealing with your app.

  • Yes. Foxhound's classifier gives `revocation_of_authorization` its own revoked-authorization handling, so no automatic retry ever runs and no multi-step dunning sequence goes out. Instead the customer gets a single, respectful email offering a clean choice: cancel and let the subscription end, or add a fresh payment method if they meant to keep it.

  • Real chargeback exposure. The customer has already gone to their bank once about this; continuing to charge them after an explicit revocation is likely to produce a dispute rather than a payment.

  • Stop automated billing on that customer and contact them directly to find out whether they want to continue. If they do, collect a fresh payment method and a new authorization rather than assuming the old one still applies.

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