try_again_later: the Stripe string that is both a decline code and an advice code
lane: retry_aggressivetry_again_laterThe card was declined for an unknown reason. Stripe marks this decline code as deprecated, and its suggested next step is to ask the customer to attempt the payment again.
What it means
One string, two homes. try_again_later exists twice in Stripe's vocabulary: as a decline code, which Stripe marks deprecated and describes as a decline for an unknown reason whose next step is another attempt, and as an advice code on the outcome, where it means the issuer declined the transaction but permits a retry. The words are identical. What they are attached to is not, and the difference changes what a sensible retry looks like.
As a decline code it is the failure describing itself, or declining to. Stripe's entry commits to nothing about the cause and to one thing about the response: ask for the payment to be attempted again. It is also marked deprecated, so its remaining sources are older paths that haven't moved to more specific codes, and you should see it less over time. What survives is the shape: a decline whose documentation is a retry instruction.
As an advice code it is a comment on someone else's decline. The decline_code beside it says what went wrong, or that nothing usable was said, and the advice code adds the issuer's posture toward another attempt. Its companions in that field are do_not_try_again and confirm_card_data, which makes try_again_later the permissive corner of a three-value vocabulary. Permission is all it is; it carries no diagnosis.
The same words in the two fields mean different things. A decline calling itself temporary describes the failure. An issuer granting a retry describes the issuer, and the two earn different pacing.
Why it happens
A temporary condition upstream
This response family exists for states that refuse now without condemning the card: congestion, a wobble at the issuer or a processor, a moment that will pass. The entry commits to no specifics, and neither should you.
An older mapping still in use
Stripe marks the decline code deprecated, so what still produces it is a path that hasn't moved to more specific codes. Expect to see it less as those paths retire.
The same words in a different field
If the string turned up in advice_code rather than decline_code, you are not looking at this decline at all. You are looking at the issuer's comment on a different one, and the decline_code beside it is the thing to read.
Common mistakes
Reading the two fields as one
A decline_code of try_again_later and an advice_code of try_again_later on some other decline are different situations that deserve different handling. Logging or alerting on the string without recording the field collapses them, and a search for the words alone can't pull them back apart.
Obeying the words at full speed
The entry says to try again; it says nothing about pace. A burst of reattempts straight away can turn a temporary condition into a velocity problem, at which point the next decline is about your behaviour rather than the original cause.
Treating the advice as a diagnosis
Permission to retry carries no information about why the payment failed. The cause is whatever the decline_code says, or declines to say, and a retry made with permission into an unexplained failure is still a retry into an unexplained failure.
How Lirova handles it
try_again_later is the one string in this table that Lirova routes two ways, and the divergence is deliberate. As a decline code it goes to retry_aggressive, the lane for failures that are themselves transient: the entry's whole documented content is that no reason was given and another attempt is the next step, which reads as a failure about the moment rather than about the card. As an advice code attached to some other decline, it routes the case to retry_gentle instead, and the advice outranks whatever lane the underlying decline code would have chosen.
The reasoning for the split is that the two uses describe different things. A decline that calls itself temporary is a claim about the failure, and transient failures get the fast pattern. An issuer's advice code is a claim about the issuer's tolerance, and permission to retry says nothing about the cause, so the case gets the spaced pattern instead. The schedules themselves differ by decline reason and are not stated here.
FAQ
What does try_again_later mean as a Stripe decline code?
The card was declined for an unknown reason, and Stripe's suggested next step is to attempt the payment again. Stripe marks the decline code as deprecated in its current table, so it mostly arrives from older paths.
What does try_again_later mean as an advice code?
It is one of the values Stripe exposes in advice_code, alongside do_not_try_again and confirm_card_data, and it means the issuer declined the transaction but permits a retry. It comments on a decline rather than being one; the reason for the failure sits in the decline_code next to it.
Should I retry straight away when I see try_again_later?
Another attempt is the documented next step, and the pace is still your choice. When the string is the decline code itself, the failure reads as transient and a quick follow-up is reasonable. When it is the advice code on some other decline, the underlying reason should set the pace, and an unexplained reason argues for space.
Why does Lirova route the decline code and the advice code differently?
Because they describe different things. The decline code try_again_later presents the failure itself as momentary, so it goes to the fast lane for transient errors. The advice code only records that the issuer permits a retry, which says nothing about the cause, so a case carrying it goes to the spaced lane, and that advice outranks the lane of whichever decline code arrived with it.
Related codes
Updated 2026-09-01