Why Stripe and Square's retries fall short

What dunning covers

Dunning is everything that happens after a payment fails before it's recovered. That includes the processor automatically trying the card again, an email telling the customer their payment didn't go through, a link to pay their overdue invoice and update their card, and, if none of that works, a person on your team stepping in.

Failed payments aren't rare. Around 8% of recurring card payments fail on a given attempt, more in some sectors, and a meaningful share of subscription cancellations happen due to failed payments. We've broken down the numbers in the section on involuntary churn.

Why subscription payments fail

Card declines fall into two broad categories.

Soft declines are temporary. The account was short on funds that day, the issuer's fraud filter flagged an unfamiliar charge, or the network returned a vague "try again" response. The processor will run the card again in a day or two and the payment often goes through.

Hard declines are permanent. The card expired, it was reported lost or stolen and cancelled, the account is closed, or the issuer is refusing the charge. Recovering the payment requires a new card or a person stepping in to sort it out.

Stripe and Square each handle the first category automatically, though in different ways. Neither was built to handle hard declines, and that gap is easy to miss if you assume your processor already has recovery covered.

Stripe's Smart Retries

Stripe's automatic recovery feature for subscriptions and invoices is called Smart Retries. Rather than retrying on a fixed schedule, it uses a model trained on payments across Stripe's network to pick the moments a retry is most likely to succeed.

By default it makes up to eight attempts over two weeks, and you can adjust the window in your Stripe dashboard, from one week up to two months. The system works, and it recovers a solid share of soft declines without any effort on your part.

There are two things it doesn't do. First, it's built around card payments; most non-card and bank-debit methods skip the retry logic entirely and go straight to whatever end action you've configured. Usually, this means the subscription is cancelled or paused. Second, once its retries are exhausted, Stripe's job is done. It cancels or pauses the subscription per your settings and stops there. Stripe won't keep following up or route the account to a person.

Stripe does offer a card updater for expired cards, but it only helps when the card network has newer details on file to hand over, which isn't true for every reissue and does nothing for a card that's simply been closed.

What Square does with a declined payment

Square's Subscriptions product handles a decline differently. Instead of quietly retrying the card in the background, Square emails the customer an invoice with a link to pay directly, and the subscription stays active while it waits. The customer must pay the invoice tied to the subscription in order to recover the payment and continue the subscription.

Square is also more limited than Stripe in two ways. Its own documentation notes that it doesn't always receive complete decline details back from card networks, which caps how targeted its messaging can be. And it has no equivalent of Stripe's card updater, so when a customer's card is reissued, that customer usually has to enter the new number themselves before another attempt can succeed.

Where Stripe and Square fall short

• Hard declines and expired cards. This is the revenue that goes uncollected, because retrying a dead card produces the same result every time.
• The built-in messaging is fixed and generic. You get one default email or invoice link, not a branded sequence you control, and there's no way to customize the timing or content for a specific account.
• There's no dashboard showing what's at risk. You'd have to go account by account in Stripe or Square to see who failed, why, and how much money is on the line.
• The merchant isn't notified when a payment fails. The customer gets an automatic email, but the merchant doesn't. Stripe's failed-payment alerts are a paid Premium or Enterprise feature, or something you build yourself with webhooks, and Square expects you to check a transaction status report in your dashboard. Neither pings you the moment it happens.
• Limited dunning sequences. Stripe cancels or pauses per your settings; Square leaves the subscription open with an unpaid invoice sitting in the customer's inbox, but nothing on Square's side is actively working to recover the payment.

What a complete dunning strategy adds

Recoura was built to close all of the gaps.

Recoura picks up only after your processor's own recovery sequence is complete. From there you get two modes, and you can use either or both. With automatic dunning, Recoura follows up on a cadence you set, sending up to five email reminders per account until the payment clears or the sequence ends. With manual recovery, higher-value accounts go to a person on your team, who receives a Slack or Teams ping the moment the failure happens, the full picture of who owes what, why it failed, and a payment request ready to send.

Every action, automatic or manual, first passes through what we call the Recovery Guard: a live check against your Stripe or Square data at the moment of sending. An account that already paid, is still mid-retry, or already has an open request never gets double-billed or double-messaged.

The bottom line

Stripe and Square's soft decline recovery works well, and there's no reason to duplicate their system. If you're interested in the process of connecting an account, we've written up how the Stripe and Square connections work, or you can see the two recovery modes in more detail on the Recovery page.