Dunning emails and the law: what you can actually do

There's a quiet anxiety that sits under most failed-payment programs: how far can I go before this stops being normal billing and becomes something regulated? The question gets asked a lot, and the honest answer is more reassuring than the fear suggests. Chasing a payment from your own subscriber is standard business, not debt collection, and the rules that actually bind you are mostly ones you're already half-following.

What follows is not legal advice, and the specifics genuinely vary by jurisdiction and by who your customers are. It's a map of where the rules actually sit, so you know which parts of a dunning program deserve scrutiny and which parts are fine.

First: this is usually not debt collection

The fear most people have is that a failed-payment sequence turns them into a debt collector, with all the licensing and compliance that implies. That's almost always wrong. You are billing a customer who owes you money for a service they received — and critically, you are trying to retain a customer, not hound a stranger. Dunning is account management. It's the same category as a gym texting a member whose card declined, not the category of a collection agency buying an overdue account.

Specialist debt-collection regimes in places like the US (the FDCPA) are written for people and firms whose business is collecting other people's debts. They generally don't apply to a business emailing its own subscribers about its own invoices. That line is worth holding onto, because a lot of the anxiety dissolves once you see your program on the account-management side of it.

Email law applies to you, and it's the same for everyone

Where you are unmistakably regulated is in the emails themselves, because dunning emails are commercial email. In the US that means CAN-SPAM: a truthful subject line, a physical address in the message, a working unsubscribe mechanism, and honoring opt-outs within the window the law allows. None of that is dunning-specific — it's the same rule set as your marketing email, and it's not onerous.

The meaningful implication for dunning is the unsubscribe itself. A customer who hits unsubscribe on a payment-failed email must stop getting that sequence, even though you still need to reach them about the actual debt. The clean way to hold both: remove them from the marketing-style flow, and keep only the genuinely necessary account notices coming. Courts and regulators are broadly tolerant of transactional messages needed to resolve a payment; they're not tolerant of using "it's about your bill" as a license to keep marketing.

Privacy law shapes how much you can say

If you have customers in the EU or UK, GDPR (and the UK's equivalent) governs how you process personal data, and that touches dunning in two specific places.

• Lawful basis: emailing a customer about a failed payment rests on the contract you have with them, not on marketing consent. You don't need a fresh opt-in to send an account notice about a payment that didn't go through. What you can't do is fold dunning into a consent-based marketing list and treat it the same way.
• What you say about them: payment-failure messages describe the customer's financial situation, which is sensitive-ish data territory. Keep the content to what's needed to fix the payment, don't share failure details with third parties unnecessarily, and don't include other customers' information. The shorter and more task-focused the message, the less privacy surface it has.

Payment network rules, not law, set the real boundaries

The constraints that actually shape most dunning programs aren't statutes at all, they're the rules of the card networks and the preferences of the processors you use. Card networks care about chargebacks, disputes, and how often charges are retried without authorization. Over-aggressive retry loops, or a sequence that reads as high-pressure, can push a customer toward a dispute — and disputes are more damaging to a small business than the recovered revenue is worth.

This is the layer worth designing for: a dunning program that is transparent, gives the customer an obvious way to fix the problem, and stops when asked is the one that keeps disputes low and the networks happy. A program that hides the reason for the email, retries rapidly, and makes it hard to escape is where the real operational risk lives.

The practical shape of a defensible program

Putting it together, a dunning sequence that stays comfortably inside every layer looks like this:

• Clear subject lines that say a payment failed, not a bait headline that hides it.
• A physical address and a working one-click unsubscribe in every email, with opt-outs honored promptly.
• Content limited to fixing the payment — what failed, how to update the card, when the next attempt happens — not cross-sells dressed up as account notices.
• Reasonable spacing between attempts, and a hard stop after a sensible number. You want to give people room to fix it, not corner them.
• A distinction between the dunning flow and your marketing list, so unsubscribing from marketing doesn't strand an unpaid invoice, and unsubscribing from dunning actually stops the dunning.
• Careful treatment of any customer in a genuine hardship conversation, and a willingness to talk to them as a person rather than running the same script.

None of this is exotic. It's the same discipline as writing decent, honest billing emails — which is exactly the point. The rules that bind dunning are mostly the rules that bind ordinary commercial email, and the riskiest thing you can do is not aggressive recovery but a program that hides what it is.

If you want to see what a real, defensible dunning sequence looks like against your own payment data — what failed, what's recoverable, and how you'd reach the people who can fix it — Recoupe's free audit runs against your actual Stripe history and shows you the shape of the problem before you build anything.

Run a free 90-day audit of your failed payments