# Snagr — full text corpus

> Snagr is a revenue-recovery tool for merchants selling on Polar.sh. It automatically emails customers who abandoned a checkout, whose subscription renewal failed, or who cancelled, and it measures the recovered revenue against a randomized holdback control group.

Generated 2026-09-03. Canonical site: https://www.snagr.sh

---

# Snagr: frequently asked questions

## What is Snagr?

Snagr is a revenue-recovery tool for merchants selling on Polar.sh. It automatically emails customers who abandoned a checkout, whose subscription renewal failed, or who cancelled, and it measures the recovered revenue against a randomized holdback control group.
## How much does Snagr cost?

Snagr has two plans. Free costs $0 and includes 50 recovery emails per calendar month with no credit card. Pro costs $19 per month flat (or $199 per year) and removes the send cap entirely. Snagr takes 0% of recovered revenue on both plans — there is no revenue share at any tier.
## Does Snagr work with Stripe?

No. Snagr supports Polar.sh only today. Stripe and Lemon Squeezy support are not available.
## Does Snagr take a percentage of recovered revenue?

No. Snagr takes 0% of recovered revenue on every plan, including Free. Pro is a flat $19 per month regardless of how much revenue Snagr recovers.
## Is Snagr free?

Yes, there is a free plan that never expires. It includes 50 recovery emails per calendar month, the full analytics dashboard and all three sequence types, and requires no credit card.
## How does Snagr prove that a recovery was actually caused by its emails?

Snagr holds back 5% of triggered sequences as a randomized control group that receives no emails, then compares the recovery rate of the emailed group against the control group. The difference is the incremental lift, and it is reported in the dashboard.
## What is dunning?

Dunning is the process of recovering a subscription payment that failed — usually an expired or declined card — by retrying the charge and prompting the customer to update their payment method before the subscription is cancelled. It addresses involuntary churn, where the customer still wants the product and only the payment failed.
## Will Snagr's emails duplicate Polar's own failed-payment emails?

No. Polar sends one notice on failure and retries the card four times over 21 days. Snagr schedules its dunning sequence around that cadence rather than on top of it, and the renewal flow can be turned off entirely while abandoned-checkout and win-back sequences keep running.

# Snagr compared with alternatives

## Snagr vs Polar's built-in emails

Polar sends its own notification when a subscription charge fails and retries the card four times over 21 days. Polar does not follow up on abandoned checkouts and does not run cancellation win-back campaigns. Snagr adds abandoned-checkout recovery and win-back, and schedules its dunning emails around Polar's retry cadence rather than duplicating it.
## Snagr vs Churn Buster / Gravy / Butter Payments

Those tools focus on failed-payment recovery (dunning) for Stripe, Shopify and Recharge merchants and typically price as a percentage of recovered revenue or a four-figure monthly minimum. Snagr is built specifically for Polar.sh, covers abandoned checkouts as well as dunning, charges a flat $19 per month, and takes 0% of recovered revenue.
## Snagr pricing model vs revenue-share recovery tools

Most failed-payment recovery vendors bill a percentage of the revenue they recover, which scales with the merchant's success. Snagr charges a flat monthly fee and takes no percentage, so recovering more money never costs the merchant more.

---

<!-- https://www.snagr.sh/ -->

---
title: "Snagr — abandoned checkout and failed payment recovery for Polar.sh"
description: "Snagr automatically recovers revenue Polar.sh merchants lose to abandoned checkouts, failed subscription renewals and cancellations."
url: https://www.snagr.sh/
source: https://www.snagr.sh/index.md
site: Snagr
---
# Snagr

> Snagr is a revenue-recovery tool for merchants selling on Polar.sh. It automatically emails customers who abandoned a checkout, whose subscription renewal failed, or who cancelled, and it measures the recovered revenue against a randomized holdback control group.

## What Snagr does

- Snagr connects to a Polar.sh organization with a single OAuth click and reads orders, checkouts and subscriptions read-only.
- Snagr detects abandoned checkouts — Polar checkout sessions that stayed open past a configurable threshold, 30 minutes by default — and starts a recovery email sequence.
- Snagr detects failed subscription renewals (past_due) and runs a dunning sequence scheduled around Polar's own four retries over 21 days, rather than on top of them.
- Snagr detects cancellations and runs a win-back sequence.
- Snagr sends recovery emails from the merchant's own verified sending domain with DKIM, SPF and DMARC on the Pro plan, or from a shared Snagr domain on the Free plan.
- Snagr attributes a recovery when the customer converts within 14 days of the most recent email in a sequence, and stores the attribution timestamp, source email and amount verbatim.
- Snagr assigns 5% of triggered sequences to a randomized holdback control group that receives no emails, so the reported recovered revenue can be compared against a baseline and expressed as incremental lift.
- Snagr suppresses unsubscribes, hard bounces and spam complaints per team, re-checking the suppression list at trigger time and again at every step send.
- Snagr includes a free, uncapped revenue analytics dashboard for Polar merchants — timezone-correct revenue, MRR breakdowns, renewal forecasts and shareable chart exports — that does not require the paid plan.

## What Snagr does not do

- Snagr currently supports Polar.sh only. Stripe and Lemon Squeezy are not supported today.
- Snagr does not process payments, hold funds, or issue refunds. Polar remains the merchant of record and payment processor.
- Snagr does not retry failed card charges itself — Polar performs the card retries, and Snagr handles the customer communication around them.
- Snagr's revenue analytics mirror Polar's own metrics API, so figures match Polar rather than being independently recomputed.

## Pricing

Snagr has two plans. Free costs $0 and includes 50 recovery emails per calendar month with no credit card. Pro costs $19 per month flat (or $199 per year) and removes the send cap entirely. Snagr takes 0% of recovered revenue on both plans — there is no revenue share at any tier.

- **Free** ($0): Free forever. Includes 50 recovery emails per calendar month (UTC), all three recovery sequence types, the full revenue analytics dashboard, a 14-day attribution window, and sending from a shared Snagr domain. No credit card is required. Sends past the cap are held, not deleted, and are released automatically on upgrade.
- **Pro** ($19): $19 per month flat, reduced from a $29 standard price. Includes unlimited recovery emails, a custom sending domain with DKIM, SPF and DMARC, unlimited connected Polar organizations, holdback lift reporting, and editable templates and step delays. There is no free trial — the free plan is the way to try Snagr.
- **Pro (annual)** ($199): $199 per year, billed once annually, saving $29 against paying monthly for twelve months. Entitlements are identical to monthly Pro.

## How Snagr compares

### Snagr vs Polar's built-in emails

Polar sends its own notification when a subscription charge fails and retries the card four times over 21 days. Polar does not follow up on abandoned checkouts and does not run cancellation win-back campaigns. Snagr adds abandoned-checkout recovery and win-back, and schedules its dunning emails around Polar's retry cadence rather than duplicating it.
### Snagr vs Churn Buster / Gravy / Butter Payments

Those tools focus on failed-payment recovery (dunning) for Stripe, Shopify and Recharge merchants and typically price as a percentage of recovered revenue or a four-figure monthly minimum. Snagr is built specifically for Polar.sh, covers abandoned checkouts as well as dunning, charges a flat $19 per month, and takes 0% of recovered revenue.
### Snagr pricing model vs revenue-share recovery tools

Most failed-payment recovery vendors bill a percentage of the revenue they recover, which scales with the merchant's success. Snagr charges a flat monthly fee and takes no percentage, so recovering more money never costs the merchant more.

## Disambiguation

Snagr (snagr.sh) is a revenue-recovery SaaS for Polar.sh merchants. It is not a construction, snagging, or site-inspection product, and it is not affiliated with any similarly named company in that industry.

Snagr is an independent product. It is not affiliated with, endorsed by, or sponsored by Polar.sh.


---

<!-- https://www.snagr.sh/pricing -->

---
title: "Snagr pricing — free for 50 recovery emails a month, then $19 flat"
description: "Snagr pricing: 50 recovery emails a month free with no card, or Pro at $19/mo ($199/yr) for unlimited sends. 0% of recovered revenue on every plan."
url: https://www.snagr.sh/pricing
source: https://www.snagr.sh/pricing.md
site: Snagr
---
# Snagr pricing

> Snagr has two plans. Free costs $0 and includes 50 recovery emails per calendar month with no credit card. Pro costs $19 per month flat (or $199 per year) and removes the send cap entirely. Snagr takes 0% of recovered revenue on both plans — there is no revenue share at any tier.

## Plans

| Plan | Price | Recovery emails per month | Revenue share |
| --- | --- | --- | --- |
| Free | $0 | 50 | 0% |
| Pro | $19/month (standard $29) | Unlimited | 0% |
| Pro annual | $199/year | Unlimited | 0% |

### Free

Free forever. Includes 50 recovery emails per calendar month (UTC), all three recovery sequence types, the full revenue analytics dashboard, a 14-day attribution window, and sending from a shared Snagr domain. No credit card is required. Sends past the cap are held, not deleted, and are released automatically on upgrade.
### Pro

$19 per month flat, reduced from a $29 standard price. Includes unlimited recovery emails, a custom sending domain with DKIM, SPF and DMARC, unlimited connected Polar organizations, holdback lift reporting, and editable templates and step delays. There is no free trial — the free plan is the way to try Snagr.
### Pro (annual)

$199 per year, billed once annually, saving $29 against paying monthly for twelve months. Entitlements are identical to monthly Pro.

## What happens at the free cap

Sends past the 50-email monthly cap are held rather than dropped. Snagr keeps retrying a held email for about ten days, and every held email is released automatically the moment the team upgrades. The cap resets on the first of each month (UTC).

## Revenue share

0% on every plan. Snagr never takes a cut of recovered revenue.


---

<!-- https://www.snagr.sh/blog -->

---
title: "Snagr guides — checkout recovery, dunning and churn"
description: "Practical guides on recovering abandoned checkouts, reducing involuntary churn, and dunning for Polar.sh merchants and digital product businesses."
url: https://www.snagr.sh/blog
source: https://www.snagr.sh/blog.md
site: Snagr
---
# Snagr guides

> Practical, vendor-neutral guides on abandoned checkout recovery, dunning, involuntary churn and payment-platform comparisons.

## [The Best Failed Payment Recovery Tools in 2026 (by Platform and Budget)](https://www.snagr.sh/blog/best-failed-payment-recovery-tools)

Churnkey, Churn Buster, Stunning, Paddle Retain, and Snagr compared — pricing, platform fit, and which failed payment recovery tool makes sense at your MRR.

Published 2026-07-02. Markdown: https://www.snagr.sh/blog/best-failed-payment-recovery-tools.md
## [What Happens When a Polar.sh Payment Fails — and How to Recover the Revenue](https://www.snagr.sh/blog/polar-failed-payments)

How Polar.sh handles failed subscription renewals, what merchants can and can't control, and how to add a dunning email flow that wins the payment back.

Published 2026-07-02. Markdown: https://www.snagr.sh/blog/polar-failed-payments.md
## [Polar vs Lemon Squeezy vs Gumroad (2026): Fees, Features, and What You Actually Keep](https://www.snagr.sh/blog/polar-vs-lemon-squeezy-vs-gumroad)

A 2026 comparison of Polar.sh, Lemon Squeezy, and Gumroad for indie developers — real per-sale fees, subscription surcharges, and the revenue-recovery gap none of them fully close.

Published 2026-07-02. Markdown: https://www.snagr.sh/blog/polar-vs-lemon-squeezy-vs-gumroad.md
## [How to Add Polar Payments to a Next.js App (2026 Guide)](https://www.snagr.sh/blog/add-polar-payments-nextjs)

A step-by-step guide to accepting payments, subscriptions, and webhooks with Polar.sh in a Next.js app, using the official @polar-sh/nextjs adapter.

Published 2026-06-24. Markdown: https://www.snagr.sh/blog/add-polar-payments-nextjs.md
## [What Is a Good Checkout Abandonment Rate? (2026 Benchmarks)](https://www.snagr.sh/blog/checkout-abandonment-rate-benchmarks)

The average checkout is abandoned ~70% of the time. How to calculate your rate, what counts as good for digital products, and why the raw number lies.

Published 2026-06-24. Markdown: https://www.snagr.sh/blog/checkout-abandonment-rate-benchmarks.md
## [5 Dunning Email Templates That Recover Failed Payments (2026)](https://www.snagr.sh/blog/dunning-email-templates)

Copy-paste dunning email templates for failed subscription payments, plus the timing, tone, and structure that actually get cards updated.

Published 2026-06-24. Markdown: https://www.snagr.sh/blog/dunning-email-templates.md
## [How to Recover Abandoned Checkouts on Polar.sh](https://www.snagr.sh/blog/recover-abandoned-checkouts-polar)

Polar handles payments and basic dunning, but it has no built-in abandoned-checkout recovery. Here's how the recovery loops work and how to set them up.

Published 2026-06-24. Markdown: https://www.snagr.sh/blog/recover-abandoned-checkouts-polar.md
## [How to Reduce Involuntary Churn From Failed Payments](https://www.snagr.sh/blog/reduce-involuntary-churn)

Involuntary churn is the revenue you lose to expired cards and failed renewals, not to unhappy customers. Here's a practical playbook to recover it.

Published 2026-06-24. Markdown: https://www.snagr.sh/blog/reduce-involuntary-churn.md
## [What Is Dunning? A Plain-English Guide to Recovering Failed Payments](https://www.snagr.sh/blog/what-is-dunning)

Dunning recovers failed subscription renewals before they become churn. How it works, what a good dunning flow looks like, and where most setups fall short.

Published 2026-06-24. Markdown: https://www.snagr.sh/blog/what-is-dunning.md


---

<!-- https://www.snagr.sh/tools/polar-analytics -->

---
title: "Free Polar.sh analytics — revenue dashboard for Polar merchants"
description: "Free revenue analytics for Polar.sh merchants: timezone-correct revenue, MRR breakdowns, renewal forecasts and shareable charts. No card."
url: https://www.snagr.sh/tools/polar-analytics
source: https://www.snagr.sh/tools/polar-analytics.md
site: Snagr
---
# Free Polar.sh analytics

> Snagr offers a free, uncapped revenue analytics dashboard for Polar.sh merchants. It requires no credit card and is free forever, not a trial.

## What it shows

- Revenue bucketed by calendar day in the store's own reporting timezone, so daily figures line up with Polar payouts rather than drifting by a day.
- Revenue broken down into new, recurring, recovered and churned components.
- A renewal-based forecast for the remainder of the current month.
- Checkout funnel views showing where sessions are lost.
- A live activity feed of orders, checkouts and subscription events.
- Themed share cards exporting any metric as an image or short video.

## How the numbers relate to Polar's own

Figures are re-sourced from Polar's official metrics API rather than recomputed independently, so the totals match what Polar reports. Read-only OAuth access is used; Snagr never modifies anything in the connected Polar organization, and the connection can be revoked at any time.

## Cost

The analytics dashboard is free forever and is not metered. Snagr's paid plan covers recovery email sending, not analytics.


---

<!-- https://www.snagr.sh/tools/checkout-abandonment-calculator -->

---
title: "Free checkout abandonment revenue calculator"
description: "Estimate how much revenue you lose to abandoned checkouts each month and how much of it is realistically recoverable. Free, no signup."
url: https://www.snagr.sh/tools/checkout-abandonment-calculator
source: https://www.snagr.sh/tools/checkout-abandonment-calculator.md
site: Snagr
---
# Checkout abandonment revenue calculator

> A free calculator estimating how much revenue a store loses to abandoned checkouts each month, and how much of that is realistically recoverable.

## Inputs

- Checkouts started per month.
- Checkout completion rate, as a percentage.
- Average order value.

## Outputs

- Abandoned checkouts per month, and the revenue they represent.
- The realistically recoverable range, calculated at a 10–15% recovery rate — the band recovery-email campaigns typically achieve.
- The annualised value of that recovery.

## Method

Lost revenue is abandoned checkouts multiplied by average order value. Recoverable revenue applies a 10–15% recovery rate to that figure, which is the conservative band reported for abandoned-checkout email campaigns. The calculator does not require an account and stores nothing.


---

<!-- https://www.snagr.sh/mcp -->

---
title: "Snagr MCP server and agent interface"
description: "Machine-readable interfaces Snagr publishes for AI agents: MCP server card, markdown twins, catalog and structured facts endpoint."
url: https://www.snagr.sh/mcp
source: https://www.snagr.sh/mcp.md
site: Snagr
---
# Snagr agent interface

> Snagr publishes machine-readable copies of every public page, plus structured product facts, for AI agents and answer engines.

## Endpoints

- `/llms.txt` (text/plain) — Curated index of Snagr's content for large language models, following the llms.txt convention.
- `/llms-full.txt` (text/plain) — The complete text corpus of every public Snagr page, concatenated as markdown in a single document.
- `/ai.txt` (text/plain) — Snagr's usage policy for AI training, inference and quoting, plus the preferred citation form.
- `/api/md/_catalog` (application/json) — JSON index of every page available as markdown, with titles, summaries and both URL forms.
- `/api/md/{path}` (text/markdown) — The markdown representation of any public page. Also reachable by appending .md to the page URL.
- `/api/ai` (application/json) — Product identity, pricing, capabilities, limitations, comparisons and question/answer pairs as JSON, for direct grounding.
- `/api/mcp` (application/json) — Model Context Protocol server description listing the read-only resources an agent can fetch.
- `/.well-known/mcp/server-card.json` (application/json) — Discovery card for Snagr's Model Context Protocol interface.
- `/.well-known/api-catalog` (application/linkset+json) — RFC 9727 linkset describing every machine-readable interface this site publishes.
- `/.well-known/agent-skills/index.json` (application/json) — Task-shaped skill descriptions an agent can follow to use Snagr's public surface.
- `/.well-known/ai-catalog.json` (application/json) — Agentic Resource Discovery catalog of Snagr's MCP server, API catalog, skills and facts.
- `/.well-known/oauth-protected-resource` (application/json) — RFC 9728 metadata for the public documentation origin. Agents do not need a token to read it.
- `/openapi.json` (application/openapi+json) — OpenAPI 3.1 description of Snagr's public agent endpoints.
- `/api/health` (application/json) — Liveness probe for the public agent surface.
- `/auth.md` (text/markdown) — How authentication works for Snagr's public and private surfaces, written for agents.

## Markdown twins

Every page on this site is available as markdown in two equivalent forms: append `.md` to the page URL, or request `/api/md/<path>`. For example, both of these return the same document:

```
https://www.snagr.sh/blog/what-is-dunning.md
https://www.snagr.sh/api/md/blog/what-is-dunning
```

## Terms

Crawling, quoting and training on this content is permitted. Attribution to Snagr (https://www.snagr.sh) is requested. See /ai.txt for the full policy.


---

<!-- https://www.snagr.sh/blog/best-failed-payment-recovery-tools -->

---
title: "Best Failed Payment Recovery Tools 2026: Compared by Platform"
description: "Churnkey, Churn Buster, Stunning, Paddle Retain, and Snagr compared — pricing, platform fit, and which failed payment recovery tool makes sense at your MRR."
url: https://www.snagr.sh/blog/best-failed-payment-recovery-tools
source: https://www.snagr.sh/blog/best-failed-payment-recovery-tools.md
date_published: 2026-07-02
date_modified: 2026-07-02
keywords: ["failed payment recovery tools", "best dunning software", "Churnkey alternative", "Churn Buster alternative", "payment recovery software", "revenue recovery tools"]
site: Snagr
---
# The Best Failed Payment Recovery Tools in 2026 (by Platform and Budget)

> Churnkey, Churn Buster, Stunning, Paddle Retain, and Snagr compared — pricing, platform fit, and which failed payment recovery tool makes sense at your MRR.

Failed payments cause 20–40% of subscription churn, and most of it is recoverable — the customer never decided to leave; their card did.[1] The tooling market splits cleanly by billing platform and by budget, so the honest way to compare recovery tools is to start with what you sell on and what you can spend.

## Quick picks

- **On Stripe, $30K+ MRR:** Churnkey or Churn Buster.
- **On Stripe, early stage:** Stunning.
- **On Paddle:** Paddle Retain (built in).
- **On Polar.sh:** Snagr — the only recovery tool built natively for Polar.

## Churnkey — best for mid-market Stripe SaaS

Churnkey combines payment recovery with cancellation flows and retention offers. It is polished, well-regarded, and priced for companies with real churn volume: plans start around **$199–$250/month** and scale with MRR.[2] If you are doing $30K+ MRR on Stripe, the math usually works. Below that, the subscription costs more than it recovers.

## Churn Buster — best for high-volume subscriptions

Churn Buster focuses squarely on failed-payment recovery for subscription businesses, including ecommerce subscriptions. Pricing starts around **$249/month**.[3] Strong campaign tooling and deliverability, same caveat as Churnkey: it is priced for scale.

## Stunning — best budget option for Stripe

Stunning has been doing Stripe dunning for over a decade and is priced for smaller businesses. Stripe-only, which is fine if that is your stack and useless if it is not.

## Paddle Retain — best if you’re already on Paddle

Retain (formerly ProfitWell Retain) ships with Paddle’s merchant of record platform. If Paddle is your MoR, use it — it is integrated and priced on recovered revenue. It is not available off-platform.

## Snagr — best (and only) native option for Polar.sh

Everything above assumes Stripe or Paddle. If you sell through [Polar.sh](https://polar.sh), none of those tools understands your billing events. [Snagr](/) connects to a Polar organization in one OAuth click and covers all three revenue-loss events — failed renewals, abandoned checkouts, and cancellations — with automatic email sequences.

- **Free tier:** 50 recovery emails/month, all three sequence types, full analytics — no card required.
- **Pro:** $19/month flat. Unlimited emails, custom sending domain (DKIM/SPF/DMARC), editable templates. No revenue share.
- **Honest measurement:** a built-in 5% holdback control group reports incremental lift, not just raw recoveries — most tools on this list report gross numbers that include customers who would have fixed their card anyway.

Watch the pricing model

Recovery tools price three ways: flat monthly (Snagr, Stunning), MRR-scaled subscription (Churnkey, Churn Buster), or a percentage of recovered revenue (Retain, and Lemon Squeezy’s built-in cart recovery at 5%). Percentage pricing feels safe but taxes your best outcome — the more it recovers, the more you pay, forever.

## How to choose

Start from your platform — it eliminates most of the list. Then estimate your monthly failed-payment volume from your billing dashboard and require that the tool cost clearly less than a conservative 30% recovery of that number. Finally, prefer tools that measure lift against a control group; without one, you cannot tell recoveries you caused from recoveries that would have happened anyway. For the mechanics of a good email sequence, see our [dunning email templates](/blog/dunning-email-templates) and [plain-English dunning guide](/blog/what-is-dunning).

Sources

1. 1.
 [Involuntary churn benchmarks — Chargebee](https://www.chargebee.com/blog/reduce-involuntary-churn/)
2. 2.
 [Churnkey pricing](https://churnkey.co/pricing)
3. 3.
 [Churn Buster](https://churnbuster.io/)


---

<!-- https://www.snagr.sh/blog/polar-failed-payments -->

---
title: "Polar.sh Failed Payments: What Happens & How to Recover Them"
description: "How Polar.sh handles failed subscription renewals, what merchants can and can't control, and how to add a dunning email flow that wins the payment back."
url: https://www.snagr.sh/blog/polar-failed-payments
source: https://www.snagr.sh/blog/polar-failed-payments.md
date_published: 2026-07-02
date_modified: 2026-07-02
keywords: ["Polar.sh failed payment", "Polar.sh dunning", "Polar.sh subscription past due", "Polar failed renewal", "Polar.sh payment retry", "recover failed payments Polar"]
site: Snagr
---
# What Happens When a Polar.sh Payment Fails — and How to Recover the Revenue

> How Polar.sh handles failed subscription renewals, what merchants can and can't control, and how to add a dunning email flow that wins the payment back.

If you sell subscriptions on [Polar.sh](https://polar.sh), some renewal charges will fail. That is not a Polar problem — it is a payments problem. Cards expire, banks decline recurring charges, and balances run dry. Industry analyses consistently attribute **20 to 40% of all subscription churn** to failed payments rather than deliberate cancellations.[1] This guide covers what Polar does when a renewal fails, where the gaps are, and how to close them.

## What Polar does when a renewal charge fails

Polar is a merchant of record built on modern payment infrastructure, and it handles the mechanical side of a failed renewal for you:

- The subscription is not cancelled on the first failure. It enters a past-due state while the charge is retried.
- Payment retries happen automatically on the processor side — you do not schedule them yourself.
- Polar emits webhook events as the subscription changes state, so your application (or a tool listening on your behalf) knows the moment a renewal fails.[2]

Retries alone recover only a fraction of failed payments, though. A retry fixes _transient_ failures — a network blip, a temporary hold. It cannot fix the most common cause of involuntary churn: an expired or replaced card. For that, the customer has to act, which means someone has to tell them.

## The gap: nobody emails the customer

This is where most Polar merchants silently lose revenue. When a card needs updating, the recovery depends entirely on the customer noticing — and customers do not check their subscription settings recreationally. A good dunning flow does three things:

- **Tells the customer quickly.** The first email should go out shortly after the failed charge, while the subscription is still active in the customer’s mind.
- **Makes fixing it one click.** The email links directly to a payment-update page — no login maze, no support ticket.
- **Follows up on a schedule.** Two or three escalating reminders over the retry window, stopping instantly the moment the payment succeeds.

Why timing matters

The retry window is finite. Once retries are exhausted, the subscription is cancelled and the customer has to check out from scratch — a far higher-friction ask than updating a card. Every day of silence during the past-due window lowers the odds of recovery.

## Your options as a Polar merchant

### 1. Build it yourself

Polar’s webhooks give you everything you need: `subscription.updated` events signal state changes, and the customer portal provides a payment-update surface. You will need to stand up a webhook endpoint, a job scheduler for the email sequence, stop-conditions for recovered payments, suppression handling for unsubscribes, and attribution if you want to know whether any of it worked. It is a real project — typically a week or two of work, plus ongoing maintenance.

### 2. Use a general dunning platform

Tools like Churnkey and Churn Buster do this well for Stripe-native businesses, but they start at roughly $199–$249/month[3] and are not built around Polar’s event model, so you are integrating against a platform that does not know what a Polar subscription is.

### 3. Use a recovery tool built for Polar

[Snagr](/) connects to a Polar organization with one OAuth click and listens for failed renewals (plus abandoned checkouts and cancellations). When a renewal fails, it sends a short, pre-written email sequence with a payment-update link, stops the moment the subscription recovers, and attributes the recovered revenue on a dashboard. A built-in 5% holdback control group shows the incremental lift — the recoveries that would _not_ have happened on their own. The free tier covers 50 recovery emails a month; Pro is $19/month flat with no revenue share.

## What to do this week

- Check your Polar dashboard for past-due and cancelled subscriptions over the last 90 days. Multiply by your price — that is the size of the leak.
- Decide whether the leak justifies a build. Under a few hundred dollars a month of failed renewals, buying beats building.
- Whatever you deploy, measure it against a holdback. Raw “recovered revenue” numbers overstate impact because some customers fix their card anyway.

Sources

1. 1.
 [Recurring payment failures and involuntary churn — industry benchmarks](https://www.chargebee.com/blog/reduce-involuntary-churn/)
2. 2.
 [Polar.sh documentation — webhook events](https://polar.sh/docs/integrate/webhooks/events)
3. 3.
 [Churnkey pricing](https://churnkey.co/pricing)


---

<!-- https://www.snagr.sh/blog/polar-vs-lemon-squeezy-vs-gumroad -->

---
title: "Polar vs Lemon Squeezy vs Gumroad: 2026 Fee Comparison"
description: "A 2026 comparison of Polar.sh, Lemon Squeezy, and Gumroad for indie developers — real per-sale fees, subscription surcharges, and the revenue-recovery gap none of them fully close."
url: https://www.snagr.sh/blog/polar-vs-lemon-squeezy-vs-gumroad
source: https://www.snagr.sh/blog/polar-vs-lemon-squeezy-vs-gumroad.md
date_published: 2026-07-02
date_modified: 2026-07-02
keywords: ["Polar vs Lemon Squeezy", "Polar vs Gumroad", "Lemon Squeezy vs Gumroad", "Polar.sh fees", "merchant of record comparison", "sell digital products indie developer"]
site: Snagr
---
# Polar vs Lemon Squeezy vs Gumroad (2026): Fees, Features, and What You Actually Keep

> A 2026 comparison of Polar.sh, Lemon Squeezy, and Gumroad for indie developers — real per-sale fees, subscription surcharges, and the revenue-recovery gap none of them fully close.

If you are an indie developer choosing where to sell a digital product or SaaS subscription in 2026, the shortlist usually comes down to **Polar.sh**, **Lemon Squeezy**, and **Gumroad**. All three act as merchant of record — they handle global sales tax, VAT, and compliance so you do not have to. The differences are in fees, developer experience, and what happens to the revenue that slips through the cracks.

## Headline fees in 2026

- **Polar:** 5% + 50¢ per transaction on the standard plan. Organizations created before May 27, 2026 keep a grandfathered “early member” rate of 4% + 40¢ (+0.5% on subscriptions).[1]
- **Lemon Squeezy:** 5% + 50¢ base — but with surcharges: +1.5% international cards, +1.5% PayPal, +0.5% subscription payments, +3% affiliate referrals, and **+5% on recovered abandoned carts**.[2]
- **Gumroad:** 10% flat per sale, plus payment processing. Simple, but the most expensive of the three at almost any volume.[3]

On paper Polar and Lemon Squeezy look identical at 5% + 50¢. In practice the surcharges decide it: a $29/mo subscription paid with an international card on Lemon Squeezy runs an effective ~7% + 50¢, while Polar’s sticker rate is closer to what you actually pay.

## Developer experience

**Polar** is the most developer-first of the three: open source, API-driven, with official SDKs and framework adapters (Next.js, Laravel, Better Auth) that make checkout a few lines of code. It has become the default choice for indie hackers shipping SaaS.

**Lemon Squeezy** (acquired by Stripe) is polished and easy to set up, with a strong dashboard and fast payouts. Its API is capable but the platform is oriented more toward no-code sellers than API-first builds.

**Gumroad** is the simplest: make a page, share a link. It is a storefront, not a billing platform — fine for ebooks and templates, limiting for software subscriptions.

## Subscriptions and churn handling

This is where the comparison gets interesting for SaaS. All three retry failed charges, but none of them ships a complete recovery stack:

- **Gumroad** has basic memberships with limited dunning control.
- **Lemon Squeezy** includes dunning emails and cart recovery — but takes an extra 5% of every cart it recovers.
- **Polar** retries charges and emits webhooks for every state change, but leaves customer-facing recovery email flows to the merchant.

The revenue nobody's platform saves

Across platforms, 20–40% of subscription churn is involuntary (failed cards, not decisions), and most checkouts that start are never completed. The platform fee debate is usually worth 1–2% of revenue; the recovery gap is often worth more.

## Which should you pick?

- **Pick Polar** if you are building SaaS or selling to developers and want the lowest real-world fees with an API-first integration.
- **Pick Lemon Squeezy** if you want a no-code storefront with Stripe’s backing and do not mind surcharges.
- **Pick Gumroad** if you sell simple one-off digital products and value zero setup over margin.

## If you land on Polar: close the recovery gap

Polar gives you the events; it does not send the win-back emails. [Snagr](/) plugs into a Polar organization in one OAuth click and automatically sends recovery sequences for abandoned checkouts, failed renewals, and cancellations — with a 5% holdback control group so the dashboard shows true incremental lift, not coincidences. Unlike Lemon Squeezy’s 5%-of-recovered-cart fee, Snagr is flat: free up to 50 recovery emails a month, then $19/month with no revenue share. See also our guide on [recovering abandoned Polar checkouts](/blog/recover-abandoned-checkouts-polar).

Sources

1. 1.
 [Polar.sh — Fees documentation](https://polar.sh/docs/merchant-of-record/fees)
2. 2.
 [Lemon Squeezy — Fees documentation](https://docs.lemonsqueezy.com/help/getting-started/fees)
3. 3.
 [Gumroad — Pricing](https://gumroad.com/pricing)


---

<!-- https://www.snagr.sh/blog/add-polar-payments-nextjs -->

---
title: "How to Add Polar Payments to a Next.js App"
description: "A step-by-step guide to accepting payments, subscriptions, and webhooks with Polar.sh in a Next.js app, using the official @polar-sh/nextjs adapter."
url: https://www.snagr.sh/blog/add-polar-payments-nextjs
source: https://www.snagr.sh/blog/add-polar-payments-nextjs.md
date_published: 2026-06-24
date_modified: 2026-06-24
keywords: ["polar payments nextjs", "polar.sh next.js", "@polar-sh/nextjs", "integrate polar payments next.js", "polar checkout nextjs", "polar subscriptions next.js"]
site: Snagr
---
# How to Add Polar Payments to a Next.js App (2026 Guide)

> A step-by-step guide to accepting payments, subscriptions, and webhooks with Polar.sh in a Next.js app, using the official @polar-sh/nextjs adapter.

[Polar.sh](https://polar.sh) is a developer-first billing platform and merchant of record, which means it handles payments, sales tax, and digital-product delivery for you. This guide walks through adding Polar to a Next.js App Router app using the official `@polar-sh/nextjs` adapter: checkout, a customer portal, and webhooks. The code is current as of 2026 and taken from Polar’s own documentation.[1]

## Prerequisites

- A Next.js project using the App Router.
- A Polar account, and at least one **product** created in the dashboard (note its product ID).
- An **organization access token** from Polar (Settings → Developers). Use a **sandbox** token while building.

## Step 1 — Install the adapter

Install the Next.js adapter and Zod (used for validation):

Terminal

```
pnpm add zod @polar-sh/nextjs
```

## Step 2 — Set environment variables

Add your access token and the URL Polar should send customers to after a successful checkout. Keep secrets in `.env.local`, never in client code.

.env.local

```
POLAR_ACCESS_TOKEN=polar_oat_...
SUCCESS_URL=https://myapp.com/success
POLAR_WEBHOOK_SECRET=whsec_...
```

## Step 3 — Create a checkout route

The adapter ships a `Checkout` handler that takes care of the redirect to Polar’s hosted checkout. Create a route handler:

app/checkout/route.ts

```
import { Checkout } from "@polar-sh/nextjs";

export const GET = Checkout({
 accessToken: process.env.POLAR_ACCESS_TOKEN,
 successUrl: process.env.SUCCESS_URL,
 server: "sandbox", // omit or use "production" when you go live
});
```

Link customers to it with the product ID as a query param. You can also prefill the customer:

Anywhere in your UI

```
<a href="/checkout?products=YOUR_PRODUCT_ID">Buy now</a>

// Optional params:
// ?products=ID&customerEmail=jane@example.com&customerName=Jane
```

## Step 4 — Add a customer portal

Give customers a portal to manage their orders and subscriptions. You resolve which Polar customer is logged in via `getCustomerId`:

app/portal/route.ts

```
import { CustomerPortal } from "@polar-sh/nextjs";

export const GET = CustomerPortal({
 accessToken: process.env.POLAR_ACCESS_TOKEN,
 getCustomerId: async (req) => {
 // Resolve and return the Polar customer ID for the signed-in user
 return "";
 },
 server: "sandbox",
});
```

## Step 5 — Handle webhooks

Webhooks are how your app learns about orders, subscriptions, and refunds. The `Webhooks` helper verifies the signature for you; add the webhook secret from your Polar dashboard.

app/api/webhook/polar/route.ts

```
import { Webhooks } from "@polar-sh/nextjs";

export const POST = Webhooks({
 webhookSecret: process.env.POLAR_WEBHOOK_SECRET!,
 onOrderPaid: async (payload) => {
 // Grant access, send a receipt, etc.
 },
 onSubscriptionActive: async (payload) => {
 // Mark the subscription active in your DB
 },
 onSubscriptionCanceled: async (payload) => {
 // Begin offboarding / win-back
 },
});
```

The handler exposes granular callbacks for nearly every event, including `onCheckoutCreated`, `onOrderPaid`, `onSubscriptionActive`, `onSubscriptionCanceled`, and `onSubscriptionRevoked`, plus a catch-all `onPayload`.[1] Register the endpoint URL in your Polar dashboard’s webhook settings.

## Step 6 — Test, then go live

Build against the **sandbox** environment first (`server: "sandbox"` and sandbox tokens). When you’re ready, create production tokens, set the webhook secret for production, and either remove the `server` option or set it to `"production"`. Polar’s example repos are a good reference for full working setups.[2]

Sandbox vs production

Sandbox and production are entirely separate environments with separate tokens, products, and webhook secrets. A token from one will not work against the other, so double-check which `server` you are pointing at when something “does not exist.”

## The step the tutorials skip: recovering what slips away

Once payments work, you will notice two leaks the integration itself does not handle. Polar fires `onCheckoutCreated` when someone _starts_ a checkout, but there is no built-in follow-up when they do not finish, and when a subscription goes `past_due` or cancels, recovery beyond Polar’s basic dunning is on you. Those abandoned checkouts and failed renewals are real revenue, and chasing them by hand means writing sweep logic, an email service, deliverability setup, and attribution.

That is the gap [Snagr](/blog/recover-abandoned-checkouts-polar) fills: it connects to the same Polar account in one click, watches these exact events, and sends recovery emails from your own domain, measured against a holdback so you know the revenue is real. Free for your first 50 recovery emails a month.

Sources

1. 1.
 [Polar — Next.js adapter documentation](https://docs.polar.sh/integrate/sdk/adapters/nextjs)
2. 2.
 [Polar — official example projects (GitHub)](https://github.com/polarsource/examples)


---

<!-- https://www.snagr.sh/blog/checkout-abandonment-rate-benchmarks -->

---
title: "What Is a Good Checkout Abandonment Rate?"
description: "The average checkout is abandoned ~70% of the time. How to calculate your rate, what counts as good for digital products, and why the raw number lies."
url: https://www.snagr.sh/blog/checkout-abandonment-rate-benchmarks
source: https://www.snagr.sh/blog/checkout-abandonment-rate-benchmarks.md
date_published: 2026-06-24
date_modified: 2026-06-24
keywords: ["checkout abandonment rate", "cart abandonment rate", "average cart abandonment rate", "checkout abandonment benchmark", "digital product checkout conversion"]
site: Snagr
---
# What Is a Good Checkout Abandonment Rate? (2026 Benchmarks)

> The average checkout is abandoned ~70% of the time. How to calculate your rate, what counts as good for digital products, and why the raw number lies.

If you sell anything online, some share of the people who start a checkout never finish it. That share is your **checkout abandonment rate**, and it is one of the most important and most misread numbers in your funnel. This guide explains how to calculate it, what a good rate actually looks like in 2026, and why the headline figure almost always overstates how much revenue you can realistically win back.

## How to calculate checkout abandonment rate

The formula is simple. Take the number of checkouts that were _started_ in a period, subtract the ones that were _completed_, and divide by the number started:

`abandonment rate = (checkouts started − checkouts completed) ÷ checkouts started`

So if 343 people began a checkout last month and 37 paid, your abandonment rate is (343 − 37) ÷ 343 = **about 89%**. The inverse, your completion or conversion rate, would be roughly 11%.

## What is the average checkout abandonment rate?

The most reliable public benchmark is the Baymard Institute average, which sits at **70.22%** as of 2026, calculated across roughly 50 separate studies and updated as new ones are published.[1] In other words, about seven of every ten started checkouts are abandoned.

But the average hides an enormous spread. Baymard’s underlying data ranges from the low 50s for routine, low-priced purchases (grocery near 50%, pet care around 52%) up into the 80s and 90s for high-consideration categories (finance and travel in the 81 to 91% band, B2B around 82%).[1] So treat 70% as a loose anchor, not a target, and compare yourself to your own category and your own trend.

Digital products, SaaS subscriptions, and creator tools, the kind of thing sold through platforms like Polar, Lemon Squeezy, and Gumroad, behave differently from a physical-goods cart. There is no shipping cost to scare people off and usually no multi-step cart, but there are other forces pushing the number around, which is why a raw rate can be misleading.

## Why the raw number lies (especially for cheap digital goods)

Before you panic about an 80 or 90% abandonment rate, understand what is actually inside it. Three things inflate the figure without representing lost, recoverable demand:

- **Card-testing bots.** Low-priced digital products are a favorite target for fraudsters validating stolen cards with small charges. These show up as started checkouts with throwaway or blank email addresses, then never complete. They are not real buyers, and chasing them with emails is pointless.
- **Window shoppers.** Some people open a checkout to see the final price or currency, then leave with no intent to buy today.
- **Duplicate and test sessions.** You, your teammates, and curious visitors all create started checkouts that were never going to convert.

Case study · our Polar store

Started343

Completed37

Recovered$145

We ran our own recovery on a live Polar store for one month. The gross abandonment rate was **89%**, which looked alarming until we segmented out card-testing bots and throwaway email addresses. After following up with genuine abandons, we recovered revenue we would otherwise have lost.

The gross rate was a scary headline; the recoverable rate was the number that actually mattered.

The number that matters

The useful metric is not your gross abandonment rate, it is your **recoverable** abandonment: real people, with real email addresses, who showed genuine intent and could still convert. On a small store that might be a fraction of the gross figure. Segmenting out bots and low-intent sessions before you measure (or email) is the difference between a vanity number and an actionable one.

## So what counts as a good rate?

Rather than chase a universal benchmark, judge yourself against your own baseline and against the recoverable slice:

- **Higher value, lower volume (subscriptions, $50+ products):** you should expect a lower abandonment rate and every abandon is worth chasing. Aim to recover as many of these as possible.
- **Low price, high volume ($5 to $20 products):** a high gross abandonment rate is normal and partly noise. Focus on filtering fraud and recovering the genuine intent.
- **Track the trend, not the absolute.** A rate that is falling month over month, with stable traffic quality, is the real win.

## How to reduce checkout abandonment

There are two levers. The first is prevention: reduce friction in the checkout itself, with a clear price, minimal fields, trusted payment options, and an obvious value proposition. The second is **recovery**: following up with the people who left, since even a well-optimized checkout will lose the majority of starts.

Recovery is where most of the upside hides, because prevention has a ceiling but a follow-up email costs almost nothing and can convert a meaningful share of genuine abandons. The mechanics matter though: you only want to email real buyers (not bots), send from a domain that lands in the inbox, and measure whether the email actually caused the conversion rather than taking credit for people who would have returned anyway.

That last point, causal measurement, is what separates a recovery program you can trust from one that just claims numbers. A small randomized holdback (a percentage of abandons who get no email) gives you a control group, so the lift you report is the part your follow-ups actually caused.

Next: see exactly how to [recover abandoned checkouts on Polar.sh](/blog/recover-abandoned-checkouts-polar), or estimate your own numbers with the [checkout abandonment calculator](/tools/checkout-abandonment-calculator).

Sources

1. 1.
 [Baymard Institute — Cart & Checkout Abandonment Rate Statistics (2026, ~50 studies)](https://baymard.com/lists/cart-abandonment-rate)


---

<!-- https://www.snagr.sh/blog/dunning-email-templates -->

---
title: "5 Dunning Email Templates That Recover Payments"
description: "Copy-paste dunning email templates for failed subscription payments, plus the timing, tone, and structure that actually get cards updated."
url: https://www.snagr.sh/blog/dunning-email-templates
source: https://www.snagr.sh/blog/dunning-email-templates.md
date_published: 2026-06-24
date_modified: 2026-06-24
keywords: ["dunning email templates", "dunning email examples", "failed payment email template", "payment failed email", "credit card expired email template", "subscription payment recovery email"]
site: Snagr
---
# 5 Dunning Email Templates That Recover Failed Payments (2026)

> Copy-paste dunning email templates for failed subscription payments, plus the timing, tone, and structure that actually get cards updated.

A dunning email tells a customer their subscription payment failed and asks them to update their card before they lose access. Done well, these emails recover a large share of failed payments, often the difference between keeping a customer and losing them to **involuntary churn** they never chose. Below are five templates you can adapt, plus the timing and tone that make them work.

## Before the templates: the rules that matter

- **Send fast, then space out.** The first email should go within hours of the failure; open rates are far higher in the first 24 hours than weeks later. Then follow up across the retry window.
- **Lead with reassurance, not threat.** The customer almost certainly did not mean to lapse. Tell them their account is still active and make the fix a single click.
- **Send from your own branded domain.** A recognizable sender from your real domain lands in the inbox and gets opened; a generic no-reply address gets filtered.
- **One clear call to action.** Every email points to the same place: update payment method. No competing links.

Merge tags

The `{{double_brace}}` placeholders below are merge tags. Replace them with your platform’s real fields (customer name, product, the secure card-update link, your support address) before sending.

## Template 1 — First notice (send within hours)

Subject

Your payment didn't go through — quick fix inside

Hi {{first_name}},

We tried to renew your {{product_name}} subscription today, but the payment didn't go through. It happens — usually an expired or replaced card.

Your account is still active. To keep it that way, just update your payment method here:

{{update_payment_link}}

It takes about 30 seconds. If you have any questions, reply to this email and a real person will help.

Thanks,
{{sender_name}}

## Template 2 — Reminder (day 3)

Subject

Still need a hand with your {{product_name}} payment?

Hi {{first_name}},

A quick reminder: we still haven't been able to renew your {{product_name}} subscription. We'll keep trying, but the surest fix is to update your card:

{{update_payment_link}}

If anything's unclear or you'd like a different payment option, just reply — happy to sort it out.

{{sender_name}}

## Template 3 — Card expired (specific cause)

Subject

Your card on file has expired

Hi {{first_name}},

The card we have on file for {{product_name}} has expired, so your latest renewal didn't go through.

Add a current card here and you're all set:

{{update_payment_link}}

Nothing else changes — same plan, same price. Thanks for being a customer.

{{sender_name}}

## Template 4 — Final notice (end of retry window)

Subject

Last chance to keep your {{product_name}} access

Hi {{first_name}},

We've tried a few times to renew your subscription without success, so your access to {{product_name}} will pause soon unless we can update your payment.

You can fix it in one click here:

{{update_payment_link}}

If you meant to cancel, no hard feelings and nothing more is needed. If not, we'd love to keep you.

{{sender_name}}

## Template 5 — Win-back (after access lapses)

Subject

Come back to {{product_name}}?

Hi {{first_name}},

Your {{product_name}} subscription lapsed after a payment we couldn't recover. If that wasn't intentional, you can pick up right where you left off:

{{reactivate_link}}

Everything you had is still here. If there's a reason you left, I'd genuinely like to hear it — just reply.

{{sender_name}}

## How to know your templates are working

Track recovery rate per email and overall, but measure honestly. Hold back a small random percentage of failed payments from the sequence as a control group, then compare how many recover with emails versus without. The gap is the revenue your templates actually caused, as opposed to customers who would have updated their card anyway. Without that control, any “recovered revenue” figure flatters the emails.

If you sell on Polar, you can skip building and sending all of this by hand. Snagr ships these flows with editable templates, sends them from your own domain, and reports recovered revenue against a built-in holdback.

New to this? Start with [what dunning is](/blog/what-is-dunning) and how to [reduce involuntary churn](/blog/reduce-involuntary-churn).

Sources

1. 1.
 [Baremetrics — How to Recover Failed Payments and Save Lost Revenue](https://baremetrics.com/blog/recover-failed-payments-save-lost-revenue)
2. 2.
 [LTVplus — Mastering Failed Payment Recovery in SaaS](https://www.ltvplus.com/e-commerce/failed-payment-recovery/)


---

<!-- https://www.snagr.sh/blog/recover-abandoned-checkouts-polar -->

---
title: "How to Recover Abandoned Checkouts on Polar.sh"
description: "Polar handles payments and basic dunning, but it has no built-in abandoned-checkout recovery. Here's how the recovery loops work and how to set them up."
url: https://www.snagr.sh/blog/recover-abandoned-checkouts-polar
source: https://www.snagr.sh/blog/recover-abandoned-checkouts-polar.md
date_published: 2026-06-24
date_modified: 2026-06-24
keywords: ["Polar.sh abandoned checkout", "Polar checkout recovery", "Polar.sh recovery emails", "Polar dunning", "recover lost revenue Polar", "Polar.sh merchant tools"]
site: Snagr
---
# How to Recover Abandoned Checkouts on Polar.sh

> Polar handles payments and basic dunning, but it has no built-in abandoned-checkout recovery. Here's how the recovery loops work and how to set them up.

[Polar.sh](https://polar.sh) is an excellent way to sell digital products and subscriptions as a developer. It handles payments, tax as merchant of record, license keys, and more. But like most billing platforms, it focuses on the moment of sale, not the revenue that slips away around it. If you sell on Polar, here is what it recovers for you by default, what it does not, and how to close the gaps.

## What Polar recovers on its own

Polar includes a basic **dunning** flow for failed subscription renewals. When a renewal charge fails, the subscription moves to `past_due`, Polar retries the charge on a schedule, emails the customer to update their payment method, and can hold benefits for a grace period before revoking access. For involuntary churn, that is a solid baseline.

## What Polar does not do

Two of the three big recovery moments are not covered natively:

- **Abandoned checkouts.** When someone starts a Polar checkout and does not finish, there is no built-in “you left something behind” follow-up. The intent is captured, but nothing acts on it.
- **Win-back after cancellation.** When a subscriber cancels, Polar revokes access. There is no automatic sequence to bring them back later with the right message or offer.

These are exactly the moments where targeted follow-up earns money, because the person already engaged with your product once.

## How to recover abandoned checkouts on Polar

The mechanics are the same whether you build it yourself or use a tool:

- **Listen to Polar webhooks.** Subscribe to checkout and subscription events so you know when a checkout was created but never completed within a window (Polar has no native “expired” event, so you detect this with a timed sweep).
- **Filter out the noise.** Cheap digital products attract card-testing bots and throwaway emails. Suppress those before you send, both because they will never convert and because emailing them hurts your sending reputation.
- **Send from your own verified domain.** Set up DKIM, SPF, and DMARC so recovery emails land in the inbox rather than spam. This is the single biggest factor in whether recovery works.
- **Measure with a holdback.** Randomly exclude a small percentage of abandons from emails as a control group, so you can prove the revenue you recovered was actually caused by your follow-up.

Build vs buy

You can absolutely script this yourself with Polar webhooks and an email provider. The work that is easy to underestimate is the deliverability setup, the bot filtering, the attribution window, and the holdback math. A purpose-built tool handles those so you are measuring real recovered revenue from day one instead of debugging spam folders.

## The three loops, together

A complete recovery setup for a Polar store covers all three events: abandoned checkout, failed renewal (improving on Polar’s default with branded, editable, measured emails), and post-cancellation win-back. They run on the same foundation, so it makes sense to treat them as one system rather than three separate projects.

Snagr is built for exactly this. It connects to Polar in one OAuth click, watches those events, sends recovery emails from your own domain, and reports the incremental revenue it recovers against a 5% holdback so you know the number is real. It is free for your first 50 recovery emails a month, with no card required to start.

Sources

1. 1.
 [Polar — Recovering failed payments (built-in dunning docs)](https://polar.sh/docs/features/subscriptions/failed-payments)
2. 2.
 [Polar — Product documentation](https://docs.polar.sh/)


---

<!-- https://www.snagr.sh/blog/reduce-involuntary-churn -->

---
title: "How to Reduce Involuntary Churn From Failed Payments"
description: "Involuntary churn is the revenue you lose to expired cards and failed renewals, not to unhappy customers. Here's a practical playbook to recover it."
url: https://www.snagr.sh/blog/reduce-involuntary-churn
source: https://www.snagr.sh/blog/reduce-involuntary-churn.md
date_published: 2026-06-24
date_modified: 2026-06-24
keywords: ["involuntary churn", "reduce churn", "failed payment recovery", "subscription churn", "passive churn", "payment recovery"]
site: Snagr
---
# How to Reduce Involuntary Churn From Failed Payments

> Involuntary churn is the revenue you lose to expired cards and failed renewals, not to unhappy customers. Here's a practical playbook to recover it.

Not all churn is created equal. When a customer cancels because they no longer want your product, that is **voluntary churn**, and fixing it means fixing the product or the fit. But a large share of lost subscriptions never involved a decision at all. The card expired, the bank declined the charge, the renewal quietly failed. That is **involuntary churn**, and it is some of the easiest revenue in your business to win back.

## How big is the problem?

Industry analyses put involuntary churn at roughly **20 to 40% of total SaaS churn**, and failed payments can quietly drain on the order of **5 to 15% of monthly recurring revenue**.[1][2] The exact figure for you depends on your card mix and renewal volume, but the point holds: a meaningful slice of your “lost” customers still want to pay you and simply hit a payment snag.

## The playbook to recover it

### 1. Retry failed charges intelligently

A single retry catches very few failures. Spreading retries across a window (for example after 2, 5, and 7 days) catches temporary declines, paycheck timing, and reissued cards. A well-built multi-step retry sequence recovers an average of **40 to 60% of failed payments**.[3] Most billing platforms can do this; make sure it is switched on and tuned.

### 2. Email the customer like a human

The retry handles the silent fixes; the email handles everyone else. Tell the customer plainly that their payment did not go through, reassure them their account is still active for now, and give them a single, obvious link to update their card. Send it from your own branded domain, not a generic no-reply address, so it lands in the inbox and looks legitimate. Timing matters a lot: reminders sent within the first 24 hours see materially higher open rates than ones sent weeks later, so do not wait.[3]

### 3. Hold access during the grace period

If you cut someone off the moment a renewal fails, you turn a fixable payment problem into a real cancellation. Keep their benefits active for the length of the retry window so an expired card does not become an excuse to walk away.

### 4. Don’t forget the abandoned checkout and the cancellation

Failed renewals are one of three recoverable moments. The other two are the **abandoned checkout** (someone started buying and did not finish) and the **cancellation** (someone left and might be won back with the right offer). A complete recovery program covers all three, because they share the same plumbing: detect the event, email the right person, and measure the result.

Tip

Treat recovery as one system, not three separate hacks. Abandoned checkouts, failed renewals, and cancellations all come down to catching an event and following up well. Tools that handle the whole loop, from your own sending domain and with proper measurement, save you from stitching together scripts for each case.

## How to know it is working

Reducing involuntary churn is measurable, so measure it honestly. Hold back a small random percentage of failed payments and cancellations from your recovery emails, and compare recovery rates with and without outreach. The gap is the churn you actually prevented. Reporting “recovered revenue” without a control group overstates your impact, because some of those customers would have updated their card on their own.

## Why this is the best churn work you can do

Reducing voluntary churn is hard and slow, it means changing the product, onboarding, and pricing. Reducing involuntary churn is fast and mostly mechanical, and the customers are already sold. For most subscription businesses, a tightened-up retry schedule plus branded, measured recovery emails recovers revenue within the first month, with almost no downside.

Related: a deeper primer on [what dunning is](/blog/what-is-dunning), and five [dunning email templates](/blog/dunning-email-templates) you can use today.

Sources

1. 1.
 [Baremetrics — How to Recover Failed Payments and Save Lost Revenue](https://baremetrics.com/blog/recover-failed-payments-save-lost-revenue)
2. 2.
 [Freemius — Reduce SaaS Failed Payments, Recover Lost Revenue](https://freemius.com/blog/reduce-saas-failed-payments/)
3. 3.
 [LTVplus — Mastering Failed Payment Recovery in SaaS](https://www.ltvplus.com/e-commerce/failed-payment-recovery/)


---

<!-- https://www.snagr.sh/blog/what-is-dunning -->

---
title: "What Is Dunning? How to Recover Failed Payments"
description: "Dunning recovers failed subscription renewals before they become churn. How it works, what a good dunning flow looks like, and where most setups fall short."
url: https://www.snagr.sh/blog/what-is-dunning
source: https://www.snagr.sh/blog/what-is-dunning.md
date_published: 2026-06-24
date_modified: 2026-06-24
keywords: ["what is dunning", "dunning management", "failed payment recovery", "subscription dunning", "involuntary churn", "past due subscription"]
site: Snagr
---
# What Is Dunning? A Plain-English Guide to Recovering Failed Payments

> Dunning recovers failed subscription renewals before they become churn. How it works, what a good dunning flow looks like, and where most setups fall short.

**Dunning** is the process of recovering a subscription payment that failed, usually by retrying the charge and nudging the customer to update their card, before the subscription is cancelled. It is one of the highest-ROI things a subscription business can do, because the customer already wanted to pay you. The money did not leave because they churned; it left because a card expired or a bank declined the charge.

## Why failed payments happen

Most failed renewals are not deliberate cancellations. They are what the industry calls **involuntary churn**, and common causes include:

- An expired or reissued card the customer never updated.
- Insufficient funds at the moment the renewal ran.
- A bank flagging the recurring charge as suspicious.
- A temporary network or processor error.

Industry analyses put involuntary churn at roughly **20 to 40% of total subscription churn**.[1] That means a meaningful chunk of the customers you “lose” each month never decided to leave at all. Dunning exists to win them back automatically.

## How a dunning flow works

When a renewal charge fails, a subscription typically moves to a `past_due` state rather than being cancelled immediately. A good dunning flow then does three things in parallel:

- **Smart retries.** The charge is retried on a schedule (for example after 2, 5, and 7 days) to catch temporary declines and top-ups, instead of giving up after one attempt.
- **Customer outreach.** The customer is emailed, told the charge failed, and given a one-click link to update their payment method. Clear, friendly, and frequent-but-not-annoying wins here.
- **A grace period.** Access to the product is held for the length of the retry window, so a customer with an expired card does not get locked out mid-month and decide not to bother coming back.

Recovery rates depend heavily on execution. Basic retry-only setups recover a smaller share of failed payments, while a well-built multi-step sequence that combines smart retries with well-written, well-timed customer emails recovers an average of **40 to 60%**.[2] The emails do a lot of the heavy lifting.

## Where most dunning setups fall short

Many billing platforms include a basic dunning flow out of the box, and that is a good baseline. But default flows tend to share a few weaknesses:

- **Generic, unbranded emails.** A plain “your payment failed” notice from a no-reply address converts worse than a branded, well-written sequence that comes from your own domain.
- **No editing.** You often cannot change the copy, timing, or number of touches to fit your product and tone.
- **No measurement.** You see that some payments recovered, but not whether your outreach caused it, or how much extra you would have lost without it.

Worth knowing

If your billing platform already retries failed charges, you do not need to replace that, you need to **upgrade the customer-facing part**: branded emails from your own domain, editable copy and timing, and a way to measure the incremental revenue your dunning actually recovers. That is where the additional recovery comes from.

## How to measure whether dunning is working

The honest way to measure recovery is with a control group. Hold back a small random percentage of failed payments from receiving emails, then compare how many recover with outreach versus without. The difference is your **incremental lift**, the revenue your dunning caused, as opposed to customers who would have fixed their card on their own. Without a holdback, any “recovered revenue” number is a guess that flatters the tool.

## The bottom line

Dunning turns silent, involuntary churn back into revenue, and it is almost pure margin because the customer already wanted your product. Retries are table stakes; the leverage is in the emails, the branding, and the measurement. If you sell subscriptions, a deliberate dunning flow is one of the cheapest growth levers you have.

Related: grab five [dunning email templates](/blog/dunning-email-templates) you can adapt, and see how to [reduce involuntary churn](/blog/reduce-involuntary-churn) more broadly.

Sources

1. 1.
 [LTVplus — Mastering Failed Payment Recovery in SaaS (involuntary churn share)](https://www.ltvplus.com/e-commerce/failed-payment-recovery/)
2. 2.
 [Baremetrics — How to Recover Failed Payments (multi-step recovery rates)](https://baremetrics.com/blog/recover-failed-payments-save-lost-revenue)