Skip to content

Decline code 19: Re-enter Transaction

Calum EwingBy Calum Ewing · Head of FulfillmentReviewed by Jay StevensUpdated 3 min read
Summarize with AI

Quick answer

Decline code 19 — “Re-enter Transaction” — is an ISO 8583 response meaning the authorization didn't complete and should be submitted again: somewhere in the chain (acquirer, network, or issuer host) a timeout or system condition interrupted the round trip rather than the issuer refusing the card. It's a transient, soft condition, so a re-submitted charge after a short delay usually clears it. Stripe reports the equivalent as processing_error, and Authorize.net returns it as response code 3 (“Error”).

What code 19 means

Soft declineRetryable

A 19 is a transient processing fault, not an issuer refusal — the authorization didn't complete, so re-submitting the same charge after a short delay usually clears it. Don't fire it back-to-back; space the attempts out.

Cross-processor equivalents

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

ISO 8583
Code19
CalledRe-enter Transaction
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 timeout or system condition in the acquirer, network, or issuer host that interrupted the authorization before it completed.
  • Network connectivity or routing problems between the processor and the issuing bank that dropped the round trip mid-request.
  • Issuer-side maintenance or an overloaded host returning a re-enter instruction instead of an approve/decline decision.
  • A malformed or incomplete authorization message — a field the processor couldn't parse, prompting a re-submit rather than a hard decline.
  • A gateway or integration fault that the processor flags as a re-enter condition instead of a definitive card refusal.

How to recover it

  1. 1Re-submit the charge after a short delay (a few minutes to a few hours) rather than re-firing the identical request instantly — the fault is usually transient.
  2. 2Confirm the request itself is well-formed: a 19 that repeats on identical data points at a malformed field or integration bug, not the issuer.
  3. 3If re-submissions keep failing, stop treating it as transient — reach the customer on email and SMS and confirm the card and details are current before the next attempt.
  4. 4
    When a 19 won't clear on its own, a real person works the payment to completion. That AI-plus-human handoff is exactly what Revatto does for you: AI-timed retries where the processor's API supports them, plus email, SMS, and human outreach, fully done-for-you. You only pay if it works — 20% of the first recovered payment, $0 setup, $0 monthly, cancel anytime.See how Revatto recovers 19declines →

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