processing_error: what this Stripe error means and why nobody declined anything

What it means

Nobody said no. Something between you and an answer failed: a timeout at the issuer's host, a hiccup on the network, a link in the processing chain that didn't respond. Stripe reports it as processing_error and files it with the card errors, but the card is usually a bystander, and this is the one entry in the decline table whose documented next step is simply to attempt the payment again.

It can arrive under its own top-level error code, processing_error, the way expired_card and incorrect_cvc do, rather than inside card_declined. It also has a narrower sibling, issuer_not_available, which says specifically that the issuer couldn't be reached. Stripe's suggested handling is the same for both, another attempt, and the distinction rarely changes what you do.

The real hazard is the answer you didn't get. A timeout can land after the issuer approved, with the response lost on the way back, which means a careless retry can charge the customer twice. Retry through the same PaymentIntent, or with the same idempotency key, and Stripe's state tracking keeps a late success from becoming a duplicate. The second hazard is quieter: an error that keeps recurring on the same card has stopped being weather, and the useful question becomes what stays constant.

Why it happens

1. A timeout in the chain

   Authorisation crosses several systems, and any of them can fail to answer in time: the issuer's host, the network, a processor in between. What comes back is an error rather than a decision.

2. Issuer or processor downtime

   Issuer systems have maintenance windows and outages like anyone's. While one is down, attempts error instead of being answered, and some of those surface as processing_error rather than issuer_not_available.

3. A mangled exchange

   Something in the message pair didn't parse: a field an intermediate system corrupted, a response in a shape nobody expected. Rare, invisible to you, and indistinguishable from a timeout in what you receive.

4. A structural problem in transient clothing

   When the same card errors on every attempt, the cause has stopped being a moment. Incompatibilities between card and route exist, and the code doesn't distinguish a bad moment from a bad match.

Common mistakes

• Treating it as a decline

  Nobody refused this payment. A your-card-was-declined email over a network timeout tells the customer something false about their card and opens a support thread about nothing. If any code deserves a quiet retry before anyone is told anything, it is this one.

• Retrying outside the PaymentIntent

  A fresh payment for every attempt discards the state Stripe keeps and opens the door to a doubled charge if an earlier attempt succeeded after its response was lost. Retry the same PaymentIntent, or reuse the idempotency key, so a late success can't turn into a duplicate.

• Abandoning the invoice on the first error

  Stripe's own next step for this code is to attempt the payment again. An error that clears is the expected shape here, and giving up on the first one throws away the easiest recovery in the table.

How Lirova handles it

Lirova routes processing_error to retry_aggressive: attempts come quickly at first, then back off. The lane exists for failures where nothing is wrong with the card and nothing needs the customer, and this code is its clearest resident. Early retries are there to catch the hiccup while it is still a hiccup; the backing off is there because an error that keeps repeating has stopped being one. The schedule differs by decline reason and isn't stated here, and an advice code from the issuer, or the PaymentIntent's own state, outranks the lane when either says something different.

FAQ

Related codes

• try_again_later
• generic_decline
• card_declined