Skip to content

Decline code 96: System Malfunction

Jordan MederichBy Jordan Mederich · Co-Founder & CEOReviewed by Sean WeasUpdated 3 min read
Summarize with AI

Quick answer

Decline code 96 — “System Malfunction” — means the issuer’s or network’s authorization system hit an internal error or was temporarily unable to process the charge, rather than refusing the card. Under the ISO 8583 standard it’s a soft, transient processor-side condition, so a retry after a short delay usually clears it. It’s the same condition Stripe reports as processing_error and that Authorize.net returns as a top-level Error (response code 3). Recover it with a spaced retry, escalating to outreach only if it persists.

What code 96 means

Soft declineRetryable

A 96 is a system fault on the issuer or network side, not an issuer refusal — retry after a short delay (a few minutes to a few hours) once the fault clears. Don't re-fire back-to-back; space the attempts so you're not stacking failures during an outage.

Cross-processor equivalents

The same issuer decision surfaces under a different code on every processor. Here is how code 96 maps across the stacks Revatto recovers on.

ISO 8583
Code96
CalledSystem Malfunction
Stripe
Codeprocessing_error
CalledProcessing error
Braintree
Code3000
CalledProcessor Network Unavailable
Authorize.net
Code3
CalledProcessing errortop-level responseCode 3 (Error)
NMI
Code260
CalledProcessor error
Chargebee
Codepayment_processing_failed
CalledPayment processing failed
Recurly
Codeprocessing_error
CalledProcessing error
IxoPay
Code1000
CalledProcessor error1000-series + 3000/4000/8000-series
Shopify
CodePROCESSING_ERROR
CalledProcessing error
Whop
Codeprocessor_error
CalledProcessor errornormalized — no processor-specific code (free-text categorized)

Why it happens

  • A transient internal error or crash in the issuer’s authorization host while processing the request.
  • A network or switch fault between the acquirer, card network, and issuer that interrupted the authorization round trip.
  • Issuer-side maintenance or an overloaded host returning a system malfunction instead of an approve/decline decision.
  • A processor-side timeout where no decision came back from the issuer in time and the system reported a malfunction.
  • Intermittent connectivity that dropped the authorization message mid-route, surfacing as a generic system error.

How to recover it

  1. 1Don’t re-fire the same charge instantly — back-to-back retries during a system fault just stack failures and inflate your decline ratio.
  2. 2Wait out the malfunction — retry after a short delay (a few minutes to a few hours) once the issuer or network host is processing normally again; the card details are still valid.
  3. 3If the charge keeps failing past the outage window, reach the customer on a channel they answer — email and SMS — to confirm the card before the next attempt so the retry isn’t wasted.
  4. 4
    Timing the retry to when the system recovers and working the outreach when it doesn’t is exactly what Revatto does for you: AI times the re-attempt, with email, SMS, and human follow-up when it’s needed — fully done-for-you, and you only pay if it works (20% of the first recovered payment, $0 setup, $0 monthly, cancel anytime).See how Revatto recovers 96declines →

See what Revatto would recover for you

Failed payments recovered automatically — no engineering, no manual chasing. We do the work; you keep the revenue.

See Your Recovery Potential

Frequently asked questions