If you run subscriptions on Square and a renewal fails, you have probably asked the obvious question: does Square just handle this for me? Does it retry the card, chase the customer, recover the payment?
The honest answer is barely. Square has a Subscriptions API and will email a customer an invoice when a charge fails, but it does not run the kind of dunning machine you might expect from a billing platform. Here is exactly what Square does, the gap it leaves, what that gap costs, and three ways to close it.
First, what is dunning?
Dunning is the systematic process of recovering failed subscription payments: retrying declined cards on a smart schedule, emailing and messaging the customer to update their card, and escalating until the payment succeeds or the customer is genuinely gone. Done well, it recovers most failed payments, because most are involuntary, not customers choosing to leave.
What Square actually does on a failed subscription charge
According to Square's own subscription-billing documentation, when the card on file fails:
- Square emails the customer the invoice with a link to pay. That is the extent of the outreach.
- There is no automatic, scheduled retry engine that intelligently re-attempts the card the way Stripe Smart Retries does.
- There is no configurable multi-step dunning sequence with branded, escalating reminders.
- After repeated failures, the subscription becomes non-billable, and Square "might deactivate" it.
So Square does something, but it is the bare minimum: one invoice email, no retries, no sequence, no recovery analytics.
The gap, in detail
Three specific things are missing, and each one costs you recovered revenue:
1. No smart retries. Many declines are temporary (insufficient funds, a fraud hold) and succeed on a retry a day or two later. Square does not automatically retry on an optimized schedule, so those easy wins are lost unless you build the retry logic yourself.
2. No real dunning sequence. A single invoice email is easy to ignore. Recovery rates climb when you reach the customer more than once, across more than one channel, with the right message at the right time. Square gives you none of that out of the box.
3. No decline data and a webhook blind spot. The failed-charge webhook does not tell you why the card failed, and no webhook fires when an invoice reaches FAILED status. So you cannot easily classify failures or even reliably know when one has finally given up.
What the gap costs
This is not a rounding error. Involuntary churn is 20 to 40% of total SaaS churn, and it is the most recoverable kind because the customer never wanted to leave. For context, Stripe, which does run an automatic retry engine, says its users recover 55% of failed payments. Square sellers start from a much lower baseline because there is no engine doing that work.
Put a number on it: if even a few percent of your MRR fails each month and you recover almost none of it, that compounds fast. Our MRR-loss breakdown walks through the math.
Should you worry? A 30-second self-check
Square's dunning gap matters to you if you can say yes to these:
- You run recurring subscriptions on Square, not just one-off sales.
- Some share of renewals fail every month. For most subscription businesses this is 5 to 12% of charges.
- You are either chasing those failures by hand or, more likely, not chasing them at all.
If that is you, the failed payments are not edge cases, they are a predictable monthly leak. And because they are mostly involuntary, the customers behind them generally want to keep paying. They just need a nudge and a working card on file, which is exactly what Square does not provide automatically.
Three ways to close the gap
Option 1: Build it yourself. Listen for the invoice.scheduled_charge_failed webhook, track FAILED status yourself (since Square will not webhook it), schedule retries, send a multi-step email/SMS sequence, and build a card-update page using the Web Payments SDK plus Cards API to save a new card and re-charge via the Subscriptions and Payments APIs. Doable, but it is a real project to build and maintain.
Option 2: Switch providers. Moving to a platform with deeper built-in dunning, like Stripe Billing, is an option, but it is a heavy one. Migrating active subscriptions and stored cards means re-tokenizing payment methods (usually a coordinated card transfer between processors), re-pointing webhooks, and risking churn during the cutover. And even after all that work, Stripe's defaults still leave 45% or more of failed payments unrecovered, so you trade one gap for a smaller one rather than closing it.
Option 3: Layer a recovery tool on top. Keep Square and add a dedicated recovery layer that fills every gap above. Rebounce connects to Square via OAuth in about 30 seconds, detects failed subscription charges, retries soft declines on a smart schedule, runs multi-channel dunning across email, SMS, and WhatsApp, and hosts a branded card-update page that re-charges the subscription automatically. No migration, no code. If you want to weigh the options on the market first, our roundup of the best dunning tools for 2026 compares them side by side.
Square is a solid way to bill customers. It is just not a dunning platform, and for subscriptions it does not pretend to be one. If failed-payment recovery matters to your revenue, and at 20 to 40% of churn it should, you need to add that layer yourself. For the hands-on version, see how to recover failed payments on Square, and if you are comparing platforms, Square vs Stripe for SaaS.