What Happens When a Polar.sh Payment Fails — and How to Recover the Revenue

If you sell subscriptions on 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.

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 $29/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.