Stripe Decline Code · Glossary
no_action_taken is a soft decline returned when the issuing bank received the authorization request but chose not to act on it — the bank neither approved nor explicitly refused the transaction, it simply let it lapse without processing.
What It Means
What It Means
no_action_taken is a soft decline returned when the issuing bank received the authorization request but chose not to act on it — the bank neither approved nor explicitly refused the transaction, it simply let it lapse without processing. It is one of the rarest and most misunderstood Stripe decline codes, essentially representing a bank-side timeout or passive refusal where the issuer's system didn't engage with the charge request at all.
Not sure if this code is recoverable for your specific situation? Use the Stripe Failure Lookup →
Why It Happens
Why It Happens
What NOT to Do
What NOT to Do
✕ Don't treat it as a hard decline and cancel customer access
no_action_taken is explicitly a soft decline — the bank didn't refuse the card, it simply didn't act. Cancelling access or requesting a new payment method on the first occurrence is the wrong response and creates entirely avoidable churn from customers whose cards are perfectly functional.
✕ Don't retry immediately in rapid succession
Because this code often originates from a bank system timeout or outage, retrying within minutes of the original failure will hit the same degraded system and generate the same non-response. Rapid successive retries during an issuer outage window also risk triggering velocity flags on the bank's side once their system comes back online.
✕ Don't send a customer-facing payment failure email on the first occurrence
Unlike insufficient_funds or expired_card, no_action_taken is highly likely to self-resolve on the next retry without any customer action required. Firing an alarm email to a customer over what is essentially a bank-side technical hiccup creates unnecessary anxiety and drives unneeded card update requests for a card that doesn't need replacing.
Retry Timing
Retry Timing
| Attempt | Timing | Rationale |
|---|---|---|
| Silent Retry 1 | 3–6 hours after failure | Background retry, no customer notification — highest success probability of any retry |
| Silent Retry 2 | 24 hours after failure | Second background retry — catches end-of-day bank system recovery |
| Retry 3 + Email trigger | Day 3 | If both silent retries fail, fire a soft customer notification and retry simultaneously |
| Alternate method prompt | Day 7 | If all retries fail, offer alternate payment method — card may be in persistent restricted state |
| Final action | Day 10–14 | Access restriction if no resolution |
Key timing principle: The first retry window of 3–6 hours is the highest-value action for no_action_taken — bank system outages and maintenance windows are typically resolved within hours, and a silent retry during this window succeeds at a significantly higher rate than any later attempt. This is the one code where a same-day retry is not only acceptable but optimal.
no_action_taken is one of the most retry-friendly codes in Stripe's taxonomy — because the underlying cause is typically transient, not structural.
Recovery Benchmark
Recovery Benchmark
| Metric | Result |
|---|---|
| Overall recovery rate (smart retries) | 40–60% |
| Recovery on first silent retry (3–6 hrs) | ~35–45% — highest single-retry success of soft declines |
| Recovery by Day 3 (3 retries total) | ~55–65% |
| Recovery with customer email + retry combined | +8–12% lift |
| Recovery with blind immediate retry | 10–15% (hits same degraded system) |
| Recovery with no action at all | ~5–10% passive self-resolution |
A 55%+ recovery rate on no_action_taken is achievable with a silent retry architecture — the key differentiator versus other soft declines is that customer communication is secondary, not primary. The retry itself does the heavy lifting here. Teams that front-load customer emails before attempting silent retries consistently underperform by 15–20% recovery compared to retry-first workflows.
At Scale
At Scale
Automated
Manual Escalation
FAQs
FAQs
What does the Stripe no_action_taken decline code mean?
no_action_taken means the issuing bank received the authorization request but did not process or respond to it — a passive non-decision rather than an active refusal. It is a soft decline most commonly caused by bank system timeouts, temporary issuer outages, or cross-border routing disruptions, and is highly recoverable with a silent retry within 3–6 hours.
What are the most common causes of a no_action_taken error in Stripe?
Common causes include bank authorization system timeouts during peak hours or maintenance windows, temporary partial issuer system outages, a card placed in a dormant or intermediate restricted state, and cross-border routing disruptions for international cards — particularly in markets like India, Brazil, and Southeast Asia.
Should I notify my customer when Stripe returns no_action_taken?
Not immediately. no_action_taken is typically a transient technical event that resolves on the next retry. Run two silent background retries — at 3–6 hours and 24 hours — before sending any customer-facing email. Alerting customers prematurely over a bank-side timeout creates unnecessary friction and card update requests for cards that need no changes.
How many times should I retry a no_action_taken payment?
Run up to 3 retries — a silent retry at 3–6 hours, a second silent retry at 24 hours, and a third retry on Day 3 alongside the first customer email. Schedule all retries during the customer's local business hours (9am–2pm) for best issuer authorization rates. If all three fail, pivot to an alternate payment method offer rather than additional retries.
What is the recovery rate for Stripe no_action_taken failures?
With a silent retry-first architecture, no_action_taken achieves 40–60% overall recovery. The first silent retry at 3–6 hours alone recovers 35–45% — the highest single-retry success rate of any Stripe soft decline code. Recovery drops to 10–15% when teams rely on immediate blind retries that hit the same degraded bank system.
What to do next
You are here
no_action_taken
Decline code reference
Check recoverability
Stripe Failure Lookup
See what's recoverable — and what isn't →
Then
Sign up for Recurflux
Automate recovery for every decline code →
Before you retry
Before you retry
Most no_action_taken failures are retried on the wrong schedule — which recovers the payment about 30% of the time. The other 70% leaves permanently. See what this code is actually costing at your MRR before deciding how to handle it.
Stop leaving revenue on the table
Recurflux handles code-specific retry scheduling, adaptive dunning, and dispute intelligence across all 30 Stripe decline codes. Connect in under 5 minutes.