Until last week, this is what happened when a PayGlue customer stopped paying: 30 days after the subscription ended, the account was deleted. Workspaces, connections, mappings, all of it gone.
I built that rule in July. It sounded responsible to me at the time. Nobody would be left with a zombie account, and we would never hold data longer than we needed it. Two months later I replaced the rule, and I want to explain both why it was wrong and how I found out.
The rule that sounded right
The reasoning in July went like this. An owner account is either paying or it is not. There is no free tier, and that was a decision, not an oversight. So an account that stopped paying is on its way out, and the kindest thing I could do was make that quick and predictable: 30 days of grace, three emails, then gone.
What that reasoning skipped is why people stop paying. Almost nobody decides to leave and then lets the card fail. Cards expire. Banks block a charge from a company they have never heard of. Somebody is on holiday when the renewal comes through, or in hospital, or just having a rough month.
For all of those people, deletion after 30 days is not a clean line. It is a customer coming back to nothing, with every paywall and button on their site now pointing at a workspace that does not exist any more.
The bug that made us look
I would like to say I reconsidered this on principle. I did not. I found it because of a bug.
The daily check that watches our own subscriptions only looked at accounts that had a subscription id stored. A first purchase never stored one. So no first-time customer was being watched at all. When the first real card failed, nothing happened. There was no email, the account never entered any phase, and no clock started. It just sat there on full access with a failing card, and I only noticed because I went looking for something else.
Fixing that meant rebuilding the whole process, and once I had it open on the table, the 30-day deletion looked exactly as wrong as it was.
What replaced it
The process now has four phases instead of a cliff.
The provider retries the card. You get one email saying the payment failed and asking you to check the card. Nothing else changes. Your workspaces keep running and your readers keep their access. If the retry goes through, that is the end of it.
The subscription ends. Either the provider gave up or you cancelled. Now a 30-day grace period starts, with full access throughout. You get an email on day one, a reminder on day 15 and a last note on day 29. Picking a plan at any point stops the clock.
Pause. After the 30 days, every workspace is paused. Paused means that purchases at your provider no longer unlock anything in Ghost, and the dashboard shows only the plans page and your account settings. Everything else stays exactly where it was: connections, mappings, paywalls, buttons. Picking a plan brings it all back, and the workspaces wake up in the order you created them.
Data hygiene, eventually. A paused account is kept for three months. After that it is fair to assume the data is no longer needed, and keeping it anyway is not a favour to anyone. You know the email I mean: a tool you forgot you ever signed up for writes to you a year later to say your account will be deleted unless you do something. That is the notice we send too, a week before the date, and only then is the account deleted, with a receipt. Payment records are not part of that. They live with the payment provider, who has to keep them for the statutory period, and the receipt says so.
Three things the deletion refuses to do
Because a deletion cannot be undone, I built the job that runs it to refuse rather than guess.
It will not delete an account that is flagged for a human to look at, which is what happens when a provider status cannot be read. It will not delete an account whose subscription was seen alive at the last check, even if the pause clock says otherwise. And it will not delete an account that did not get the week’s notice. If that notice could not be sent, the deletion waits, and the nightly log says why.
That last one is the one I care about most. A warning that fails silently, followed by a deletion that happens anyway, is the worst combination I can think of.
What I would tell you to check in your own product
If you run a subscription business, open the code that runs when a customer stops paying and ask what it assumes about why they stopped. If it assumes a decision, it is probably wrong most of the time.
Then ask what a customer finds when they come back. If the answer is “nothing”, you have a cliff, and you will find out about it from the first customer who falls off it. In my case nobody had fallen yet, which is luck, not design.