One of your Square subscriptions just failed to charge. The customer is still using your product, the renewal did not go through, and Square did not fix it for you. Now what?
This is one of the most under-handled problems for businesses running recurring billing on Square. Unlike a full subscription platform, Square does not run an automatic retry-and-recover engine on failed subscription charges. If you do nothing, that revenue quietly churns. This guide shows you exactly where to find failed payments in Square, why they failed, what Square does and does not do automatically, and the step-by-step playbook to recover the money.
Where to find failed payments in Square
A failed recurring charge shows up in two places:
- Square Dashboard, Invoices. Each subscription cycle generates an invoice. A failed charge leaves the invoice unpaid, with the card decline noted on it.
- Square Dashboard, Subscriptions. The subscription shows its own status. After repeated failed charges, Square flags it as non-billable.
If you are pulling this programmatically, the signal is the invoice.scheduled_charge_failed webhook, which fires when an automatic scheduled invoice payment fails. Two gotchas every developer hits here, both documented by Square:
- The webhook payload does not include the decline reason. You only learn that it failed, not why.
- When an invoice finally exhausts attempts and moves to FAILED status, no webhook is emitted for that transition. You have to track it yourself.
Why the charge failed
Most failed subscription charges are not fraud or angry customers cancelling. They are involuntary: the customer wants to keep paying, but the card did not go through. The usual culprits:
- Insufficient funds, often temporary and very recoverable on a retry a day or two later.
- Expired card, where the card on file aged out and the customer needs to enter a new one.
- Card replaced or reissued, leaving a dead card on file after a lost, stolen, or bank-reissued card.
- Bank declines or fraud holds, which the issuing bank often clears on a later attempt.
Square itself notes it "doesn't receive complete information from credit card providers about why payments fail." That is why the decline reason is missing from the webhook, and why a blind manual approach is hard.
Soft declines vs hard declines
Not every failed charge should be handled the same way, and knowing the difference is what separates a good recovery rate from a bad one.
- Soft declines are temporary: insufficient funds, a processing error, a momentary fraud hold. The card itself is still good. The right move is to retry on a smart schedule, because a charge that fails today often clears in two or three days once funds land or the hold lifts.
- Hard declines are permanent for that card: expired, cancelled, stolen, or reported lost. Retrying the same card will never work. The only path is to get the customer to enter a new one.
The problem on Square is that the failed-charge webhook does not tell you which kind you are dealing with, so you cannot route automatically. A blind "email once and hope" approach treats a recoverable soft decline the same as a dead card, and loses both. A real recovery system retries soft declines and immediately asks for a new card on hard ones. For the full taxonomy, see our breakdown of what each decline code means - the categories map closely across processors.
What Square does (and does not do) automatically
This is the part most people get wrong. Coming from Stripe, founders assume there is a retry engine quietly working in the background. On Square, there mostly is not.
| On a failed subscription charge | Square |
|---|---|
| Scheduled, optimized card retries | No automatic retry engine |
| Emails the customer a payment link | Yes, sends the invoice with a pay link |
| Multi-step branded dunning sequence | No |
| Hosted, embeddable card-update recovery flow | No |
| After repeated failures | Subscription becomes non-billable; Square may deactivate it |
So Square will email the customer an invoice link, but there is no smart retry cadence, no escalating reminder sequence, and no recovery page you can drop into your own product. Dunning, the systematic process of recovering failed payments, is left almost entirely to you.
Recovery on Square comes down to getting an updated card and re-charging it, work Square does not automate for subscriptions.
The manual recovery playbook
If you are recovering by hand, this is the sequence that actually works:
- Catch the failure fast. Watch the invoice.scheduled_charge_failed webhook, or check Invoices daily. Speed matters: the longer a customer uses your product unpaid, the more it feels like a bill they would rather skip.
- Reach out on the right channel. A plain emailed invoice link is the bare minimum and is easy to ignore. A short, friendly "your card did not go through, update it here" message, ideally across email plus one more channel, recovers far more.
- Collect a new card. Send the customer to a secure card form built with the Square Web Payments SDK, which tokenizes the card in the browser into a one-time source_id.
- Save the card on file. Pass that token to the Cards API CreateCard to store it and get a durable card_id. This requires explicit customer consent.
- Point the subscription at the new card and re-charge. Update the subscription's card_id via the Subscriptions API so future cycles bill the good card, and charge the outstanding cycle now with the Payments API, because Square will not auto-retry it for you.
Why manual recovery does not scale
The playbook above works for a handful of failures. At any real volume it falls apart:
- You are checking invoices by hand, or building and maintaining webhook, card-update, and re-charge code yourself.
- A single email is not enough. Recovery climbs sharply when you add timing, retries on soft declines, and a second channel like SMS.
- You have no decline-reason data from Square, so you cannot tell a "retry in two days" insufficient-funds failure from a "must get a new card" expired-card failure.
For comparison, Stripe, which does run an automatic retry engine, claims its users recover 55% of failed payments, and independent audits put its real-world B2C recovery at 25-35%. Square sellers start from a lower baseline because there is no retry engine at all. That gap is recoverable revenue sitting on the table. See how much MRR you are losing to failed payments to size it for your own numbers.
Automating recovery on Square
The scalable answer is to put a recovery layer on top of Square that does what Square does not: detect every failed charge, classify it, retry on the right schedule, reach the customer across email, SMS, and WhatsApp, and host the branded card-update page that re-charges the subscription automatically.
That is exactly what Rebounce does. It connects to Square in about 30 seconds over OAuth, listens for failed subscription charges, and runs the full recovery sequence on autopilot, with no code and no manual invoice-chasing. For a deeper look at where Square leaves you exposed, read does Square have dunning, and if you are still weighing platforms, Square vs Stripe for SaaS.
Square is a great way to bill, but it leaves failed-payment recovery almost entirely up to you. Whether you build it or layer a tool on top, the one thing that does not work is leaving it to Square's defaults, because for subscriptions, there barely are any.