foxhound
Sign in

Decline code

Reenter Transaction

`reenter_transaction` is Stripe's decline code for a payment the issuer couldn't process for an unknown reason. Like other codes in this family, it carries no specific rejection reason such as insufficient funds, fraud, or an expired card. The name itself suggests the underlying signal from the card network: something about how the transaction was submitted or processed didn't go through cleanly on the issuer's end, and resubmitting it is the expected next step.

Back to decline codes
reenter_transactionRetries automatically
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

For recurring charges, this typically surfaces when the issuer's processing systems hit a snag handling the specific authorization request, without anything wrong with the card or account behind it. It can result from a momentary glitch in how the transaction data moved through the issuer's systems, a brief internal processing fault on their end, or a transient state that cleared shortly after. Subscription billing systems submit these charges without a human present to notice or immediately retry, so a code like this can sit unresolved until the merchant's own retry logic picks it up.

How to fix it

Yes. Both the code's name and Stripe's definition point toward a transient issue rather than a final rejection. Submitting the charge again, typically after a short wait, is the correct and expected response. Apply the same tiered retry timing used for other unknown-reason and technical declines: an initial retry a few hours after the failure, and a second one around 24 hours later if needed. Because the decline gives no indication of a card or account problem, avoid sending a payment update request to the customer until the retry attempts have run their course. Prematurely asking someone to change their card for an issue that was entirely on the processing side tends to generate confused replies rather than resolved payments.

How Foxhound recovers it

A Foxhound-scheduled silent retry runs first, timed for the specific decline pattern rather than an immediate repeat. If the retry succeeds, the customer never sees anything happened. If it does not, Foxhound moves to a dunning email sequence across the following weeks, written in the merchant's own brand voice, with a hosted card-update link on every email as a passive fallback channel.

Questions

  • The issuer's systems couldn't process the payment request as submitted, for reasons that aren't specified, and the expected fix is to submit the transaction again.

  • No. Stripe's definition attributes the failure to the issuer's inability to process the transaction, not to anything about the card's funds, validity, or standing.

  • Both are unknown-reason declines treated as transient, but `try_again_later` reads as a generic card decline while `reenter_transaction` points more specifically at a processing hiccup on the issuer's side during the transaction itself.

  • A few hours after the initial failure is a reasonable first attempt, with a second retry around the one day mark if the charge still hasn't gone through.

  • No. Since it's classified as a network decline, Foxhound retries automatically in the background first and only starts the merchant's email sequence if those retries don't succeed.

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