RecoverGuide
Stripe's dunning emails: what you control and what you do not
Last updated 28 July 2026 · written by Bruce McGinley, who builds RecoverFlow
Stripe will email your customers about failed payments for free. You control your branding, and you control which of the emails are switched on.
You do not meaningfully control the wording, the sending schedule, or the fact that they come from Stripe's infrastructure rather than from you. Stripe also keeps its email logs for 60 days, which sets a floor on how far back you can audit what your customers were told.
For a lot of businesses that is a perfectly acceptable trade. Switch them on before you evaluate anything paid.
On this page
What Stripe will send
Three things matter here, all configurable in your Billing settings.
- Failed payment notifications. Sent when a subscription payment fails, telling the customer and pointing them at a way to fix it.
- Unpaid invoice reminders. Follow ups on invoices that remain open.
- Card expiry notices. Sent roughly a month before a saved card expires. This one is preventative and is the most underused of the three.
All of them carry your branding: your logo, your colours, your business name. To the customer they read as coming from you, which is the correct design.
What you actually control
| Thing | Can you control it? |
|---|---|
| Whether each email sends | Yes, per email type |
| Logo, colours, business name | Yes, through Branding settings |
| The wording of the email | No, beyond branding and locale |
| How many go out and when | Not independently of Stripe's schedule |
| The sending domain and reply address | Not in the way a marketing tool lets you |
| Different copy per decline reason | No |
| How long the send log is kept | No. Stripe retains email logs for 60 days |
The row that catches people out is the last one. If someone asks in October what a customer was told in July, and you were relying entirely on Stripe's logs, you cannot answer. That matters more for disputes and compliance questions than for revenue, but it matters.
When this is enough
Genuinely, often. If your failed payments are mostly insufficient funds and expired cards, if your customers are consumers who recognise your brand, and if you are not trying to run different messaging for different failure reasons, Stripe's emails plus Smart Retries will do most of the available work for zero extra cost and zero extra vendor.
The bar for adding anything on top should be that you can name the specific thing you want that Stripe does not do. If you cannot name it, you do not need it yet.
When it stops being enough
Four situations where people outgrow it, in rough order of how often they come up.
You want the message to match the reason. A customer whose card was reported lost needs a different email from one whose payment needs SCA authentication, which needs a different email again from someone who is simply short of money this week. One generic template addresses all three adequately and none of them well.
You want it to come from a person. Especially in B2B, an email from a named human at your company gets replies that a system notification does not. Stripe's emails are branded but they are not from anyone.
You want to know what worked. Attribution here is genuinely hard. A payment succeeds and something caused it, but distinguishing "our email prompted a card update" from "Stripe's retry happened to land after payday" needs the sequence of events, not just the outcome. Stripe reports the outcome.
You want to look back further than 60 days. Self explanatory, and only a problem once someone asks.
If you are building your own
Two things are easy to get wrong and worth stating.
First, do not tell customers the decline reason for lost_card, pickup_card, stolen_card or highest_risk_level. Stripe's guidance is explicit that revealing these gives useful information to someone using a card they should not have. Write the generic version.
Second, if you send your own emails you become responsible for their deliverability, their unsubscribe behaviour and their data handling. Stripe was absorbing all three for you. Transactional billing email is a legitimate category, but sending it badly from a domain you also use for marketing is how you end up in spam folders for both.
Questions people actually ask
Does Stripe send dunning emails automatically?
Yes, if you enable them. Stripe can send failed payment notifications, unpaid invoice reminders and card expiry notices, all carrying your branding, at no additional cost.
Can I customise the text of Stripe's dunning emails?
Not beyond branding and language. You control the logo, colours and business name, and whether each email type sends at all. The copy itself is Stripe's.
How long does Stripe keep email logs?
60 days. If you need a record of what a customer was told further back than that, you need to keep it somewhere yourself.
Do Stripe's emails come from my domain?
They carry your branding and read as coming from your business, but they are sent by Stripe's infrastructure. You do not get the sender control you would have with your own email system.
Should I turn Stripe's emails off if I use a third party tool?
Usually yes, or you will send two sets of emails about the same failed payment, which is worse than either alone. Decide which system owns the conversation and switch the other one off.
Where this came from
Checked against primary sources on 28 July 2026. If Stripe changes something and this page has not caught up, tell us and it gets fixed.
- Stripe: Customer emails
- Stripe: Smart Retries — the source for the 8 tries in 2 weeks default, the configurable window, and the nine code list.
- Stripe: Decline codes reference
If you would rather not build this yourself
RecoverFlow watches your Stripe account for failed subscription payments, stops retrying the ones that cannot succeed, and emails the customers whose card simply needs replacing. It charges 25% of what it actually recovers, with a $29 monthly floor, and nothing at all if it recovers nothing.
It is early. It is run by one person. If Stripe's own free retry settings are enough for you, use those instead, and there is a page on this site that says exactly when that is the right call.
See how the pricing works