Dunning

A subscriber’s annual renewal declines because the card on file expired. The subscription is not lost at the moment of the decline. The store retries the charge on its own schedule for a set window and emails the subscriber about the problem, and that whole sequence is dunning. Whether the subscription survives depends on whether anyone reaches the person before the window closes.

The retries are the store’s half. The messaging half is mostly unclaimed. Store dunning email goes to the address on the store account, which is often not an address the subscriber reads, and it lands next to every other receipt and promotion in the same inbox. Meanwhile the subscriber keeps opening the app, because access usually survives the retry window. That session is the highest-intent contact anyone is going to get with a lapsing subscriber, and it is the one most dunning programs skip.

Treating dunning as part of the journey rather than as an email schedule changes what gets built. A subscriber in retry sees a screen at session start that names the problem and routes to the store’s payment settings, and the app keeps serving access through the grace period instead of cutting it off and explaining afterward. Those screens, and the branching that decides who sees them, get built in Flows, which also means the recovery reads as a conversion path with a measurable outcome rather than as a billing chore nobody owns. The subscribers it saves are the ones who would otherwise show up in the involuntary churn number.