Hard Decline

Stripe Decline Code · Glossary

stop_payment_order

Non-recoverable·Updated May 2026

What It Means

What stop_payment_order actually means.

stop_payment_order is a deliberate, customer-initiated hard decline — the cardholder has contacted their bank and explicitly instructed them to block a specific payment or series of recurring payments from going through to your merchant. This is categorically different from every other decline code: it is not a technical failure, not a fraud flag, not a funds issue — it is a conscious act by your customer to stop paying you, which makes it the highest-intent churn signal in all of subscription billing.

Not sure if this code is recoverable for your specific situation? Use the Stripe Failure Lookup →

Why It Happens

The root causes.

1Customer cancelled but billing continued — The most common cause: a customer believed they cancelled their subscription but the cancellation didn't process correctly — or your offboarding flow was unclear — leading them to contact their bank to force-stop the charge when the next billing cycle hit
2Disputed or unauthorized charge perception — The customer doesn't recognize your merchant name on their bank statement — due to a confusing billing descriptor — and interprets the charge as unauthorized, filing a stop payment order rather than contacting your support team
3Deliberate subscription cancellation via bank — Customer intentionally chose to cancel through their bank rather than through your product — common when customers can't easily find a cancellation option, have had a poor support experience, or want to ensure billing stops immediately without trusting your cancellation flow
4Duplicate or incorrect charge — Customer was billed the wrong amount, billed twice, or billed after a stated cancellation date — and chose a stop payment order as the fastest way to protect their account
5Forgotten subscription — Annual plan customer forgot they had an active subscription, sees the renewal charge, and reflexively stops payment before investigating what the charge is for

What NOT to Do

Common mistakes that make it worse.

✕ Don't retry — this is an explicit customer instruction to their bank

A stop payment order is the customer actively telling their bank: do not pay this merchant. Retrying is not only guaranteed to fail — it is potentially actionable. Retrying a charge after a stop payment order has been placed can be classified as an unauthorized transaction attempt and dramatically increases your chargeback and dispute risk. This is the one code where retrying crosses from bad practice into potential legal exposure.

✕ Don't treat it like a soft decline and run a dunning sequence

Your standard dunning email sequence — "we couldn't process your payment, please update your card" — is entirely wrong for this code. The customer knows their payment failed; they made it fail intentionally. Sending automated retry emails at Day 3, Day 7, Day 14 ignores the real signal and risks escalating the customer from a stop payment order to an outright chargeback dispute.

✕ Don't ignore it as just another failed payment

stop_payment_order is the strongest voluntary churn signal in Stripe's entire decline taxonomy. Every other hard decline is involuntary — this one is deliberate. Routing it into the same workflow as expired_card or insufficient_funds means you're missing a critical customer relationship event that requires immediate, human, non-automated response.

Retry Timing

Optimal retry schedule.

Zero retries — ever. The entire response framework for stop_payment_order is a customer relationship recovery sequence, not a payment retry sequence.

Recovery Benchmark

What good looks like.

Metric	Result
Overall payment recovery rate	5–15%
Recovery via human outreach + billing confusion resolution	25–35% of those who respond
Recovery from billing descriptor confusion cases	40–55% (highly preventable)
Chargeback conversion rate (if no outreach within 72 hrs)	30–50% escalate to formal dispute
Recovery with automated dunning sequence	~2–5% (and increases chargeback risk)
Win-back rate (relationship, not immediate payment)	20–30% over 30–60 days with proper offboarding

Your primary KPI for stop_payment_order is chargeback prevention, not payment recovery. Every stop_payment_order that escalates to a chargeback costs you the disputed amount + $15–$35 dispute fee + potential dispute ratio damage to your Stripe account. A human outreach response within 48 hours that resolves the customer's grievance — even with a full refund — is almost always more economically rational than letting it escalate.

At Scale

How to handle it at scale.

Automated

✓Webhook trigger: invoice.payment_failed → check failure_code === 'stop_payment_order' → immediately route to a completely isolated, human-escalation-first workflow — zero overlap with any dunning, retry, or soft decline track
✓Hard no-retry lock: stop_payment_order must be in your absolute no-retry blocklist — flagged at the system level so no automation, scheduler, or manual retry can fire against this account without explicit override authorization
✓Subscription pause (not cancel): Automatically move subscription to paused state — this stops further charge attempts while preserving the account for potential win-back; outright cancellation removes your recovery window
✓Internal team alert — immediate: Fire a Slack/email alert to your team the moment a stop_payment_order fires — this is the one decline code that requires a human decision within hours, not days
✓Billing descriptor audit trigger: Tag all stop_payment_order occurrences and cross-reference with billing descriptor confusion patterns — if multiple customers from the same cohort or acquisition period are filing stop payment orders, your billing descriptor is likely unrecognizable and needs immediate updating in Stripe
✓Chargeback risk timer: Set an automated 72-hour countdown alert from the stop payment event — if no human outreach has been completed and no customer response received by hour 72, escalate to urgent status

Manual Escalation

→Human email within 2–4 hours: This is the most critical manual action in all of subscription billing recovery — a genuine, personal email from a founder or senior team member: "Hi [name], we noticed your payment didn't go through and wanted to reach out personally. Can you tell me what happened? We want to make sure we've done right by you." — no templates, no automation feel
→Investigate before accusing: Check your internal records first — did they submit a cancellation request that wasn't processed? Was their billing descriptor your actual company name? Were they billed the right amount? Come to the conversation with answers, not questions
→Offer a full refund proactively if warranted: If the stop payment order was placed after a cancellation that didn't process, a proactive full refund offer communicated in the first email prevents chargeback escalation in 70%+ of cases — the cost of the refund is always lower than the chargeback fee + dispute ratio damage
→Cancellation flow audit: Every stop_payment_order is a signal that your cancellation flow has friction — customers should never need to contact their bank to stop billing. Audit your offboarding UX after every occurrence and remove friction points that force customers to the nuclear option
→Win-back sequence (30–60 days post-resolution): For customers who stopped payment due to billing confusion or cancellation failure (not genuine product dissatisfaction), a 30-day post-resolution win-back sequence with a discount or feature highlight recovers 20–30% as paying customers again

FAQs

Frequently asked questions.

What does the Stripe stop_payment_order decline code mean?

stop_payment_order means the customer has contacted their bank and explicitly instructed them to block a specific payment or series of recurring payments from being processed to your merchant. It is a deliberate, customer-initiated hard decline — the strongest voluntary churn signal in subscription billing — and requires immediate human outreach, not automated retry logic.

What are the most common causes of a stop_payment_order in Stripe?

Common causes include a customer who believed they cancelled their subscription but billing continued, an unrecognizable billing descriptor causing the customer to treat the charge as unauthorized, a deliberate subscription cancellation placed through the bank due to poor offboarding UX, a billing error such as a duplicate or incorrect charge amount, or an annual plan customer who forgot about a subscription and reflexively stopped the renewal payment.

Should I retry a payment after a Stripe stop_payment_order decline?

Never. The customer has explicitly instructed their bank to block your charge. Retrying is guaranteed to fail and can legally be classified as an unauthorized transaction attempt, dramatically increasing your chargeback and dispute risk. Add stop_payment_order to your absolute no-retry blocklist and respond with human outreach within 48–72 hours instead.

How do I prevent stop_payment_order from escalating to a chargeback?

Respond with personal human outreach within 48–72 hours of the stop payment event — this is the critical window before a stop payment order typically escalates to a formal chargeback filing. Investigate the cause, offer a proactive refund if billing was in error, and resolve the customer's grievance directly. A refund almost always costs less than a chargeback fee plus dispute ratio damage to your Stripe account.

What is the recovery rate for Stripe stop_payment_order failures?

Overall payment recovery is 5–15%, making it the lowest of all Stripe decline codes. However, for billing descriptor confusion cases — where the customer didn't recognize the charge — human outreach resolves 40–55% of occurrences. The primary metric to optimize is chargeback prevention, not payment recovery: proactive human outreach within 72 hours prevents 50–70% of stop payment orders from escalating to formal disputes.

What to do next

You are here

stop_payment_order

Decline code reference

↓→

Check recoverability

Stripe Failure Lookup

See what's recoverable — and what isn't →

↓→

Then

Automate recovery for every decline code →

Before you retry

Most stop_payment_order 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.

See what stop_payment_order costs me →

Stop leaving revenue on the table

stop_payment_order can't be retried — but it can be caught earlier.

Recurflux handles code-specific retry scheduling, adaptive dunning, and dispute intelligence across all 30 Stripe decline codes. Connect in under 5 minutes.

See what's leaking →All 30 decline codes →