Resources

Past-Due Access: When to Restrict a Subscriber

Every dunning sequence ends in a question most operators postpone until a subscriber forces it: what happens to access while a payment is past due, and what happens when the window closes? Answer it late and you answer it badly — either cutting off a loyal subscriber over a card that expired last week, which manufactures the churn you were trying to prevent, or leaving full access running for months of unpaid use, which trains subscribers that renewal dates are suggestions. A past-due access policy is the written answer, decided in advance: when access is untouched, when it is limited, when it ends, and how each step is communicated. This piece covers the restriction options, how to sequence them with grace periods and dunning, and how to communicate changes so they recover payments instead of ending relationships. It builds on our guide to subscription grace periods, which covers the timing window itself.

Start from the subscriber you are actually dealing with

Most past-due subscribers are not delinquent in any moral sense. According to Recurly research, 20–40% of subscriber churn is involuntary — expired cards, replaced cards, temporary shortfalls, bank flags on legitimate charges. The person behind your past-due account is usually a good customer with a broken payment method who may not even know yet. A smaller group knows and is deciding, using the failure as a pause to reconsider. A genuinely small group intends to extract free value for as long as access allows. Policy design fails when it is built for the third group and applied to the first. Restrictions exist to create clarity and urgency for the honest majority, with a firm end for the few who need one. Keep that ordering in mind through every choice below: inform first, limit second, end last — and never surprise anyone.

The restriction ladder

Full access, clearly flagged

During the early window, access continues unchanged while dunning and retries run. The subscriber sees the alerts, knows the state of the account, and keeps using the product — which is itself a recovery asset, because every session reminds them what the payment is for. This stage suits most products early on, especially where a retry is likely to clear the failure without any subscriber action at all.

Partial restriction

The middle stage limits the product without destroying its value: read-only instead of read-write, existing content available but no new usage, premium features paused while the core remains, exports or team additions blocked while work in progress stays safe. Partial restriction is the most underused tool in this policy area. It creates real, felt urgency — the subscriber encounters the limit in the flow of work — while preserving the thing they would lose, which is often what motivates the card update an hour later. Crucially, never restrict in a way that destroys subscriber data or work as a pressure tactic. Holding a person's data hostage converts a billing problem into a trust verdict they will repeat to others.

Full suspension

Access ends, the account and its data are preserved for a defined period, and the path back is a single payment. Suspension belongs at the end of the window, after the final notice date has passed, and it should be reversible instantly on payment — automatically, without a support ticket. A suspended subscriber who pays and waits two days for manual reactivation is a subscriber you saved and then lost to your own process.

Cancellation and data retention

The terminal state: the subscription ends, and separately, a data decision applies — how long work, content, and settings are retained before deletion, and what the subscriber can export in the meantime. State this retention period plainly. It matters for winback later, and subscribers deciding whether to return weigh whether their history survives. Whatever period you choose, honor it exactly.

Sequencing restriction with grace and dunning

Restriction stages should map to dunning stages, so the subscriber experiences one coherent process rather than two systems colliding. A workable sequence looks like this:

1. Failure day: dunning opens, retries begin, access continues in full, and the subscriber is told plainly what happened and what the timeline looks like.
2. Mid-window: if retries have not cleared and no update has arrived, partial restriction begins — announced in advance by at least one notice, never sprung mid-session without prior warning.
3. Final notice: the exact suspension date is stated, with the update path and any alternatives, such as pausing the subscription or speaking to support about a problem behind the failure.
4. Suspension date: the stated consequence happens, on the stated day, and payment restores access immediately.
5. After suspension: dunning stops, the cancellation and retention clock is communicated, and the door is left open through winback rather than further billing pressure.

Write your version of this sequence down as policy, not habit. The grace period policy template gives you a structure for the written document, including the internal version your support team applies when a subscriber asks for an exception — because exceptions will be asked for, and a policy with a humane, bounded exception path survives contact with real cases far better than improvisation.

Communicating restriction so it recovers instead of repels

Every restriction step needs its own notice, sent before the step takes effect, in the same voice as the rest of your dunning. The notice states three things: what changes, on what date, and the single action that prevents or reverses it. Inside the product, restricted states need the same clarity — a subscriber who hits a limit should see why, what state the account is in, and a working button that leads to the card update, not a generic error or a silent redirect to a pricing page. Tone matters most at the firm end of the ladder. "Your access pauses on June 14 unless the payment is updated — update takes about a minute, and everything in your account stays exactly as it is" recovers subscribers. Threatening or shaming language at the same moment pushes the deciders — the group still weighing whether to stay — toward cancelling to end an unpleasant interaction. And when circumstances behind the failure are human ones, give support a real offer to make: a pause, a plan change, a billing date move. Knowing where dunning ends and formal collections begin also keeps your language honest, a boundary we map in dunning vs collections. Dunning, including restriction, is a retention process. The moment it sounds like debt enforcement, it stops working as one.

Exceptions and edge cases worth deciding now

• Annual and high-value accounts. A longer runway, a personal outreach before any restriction, and a named human to talk to. The economics justify it, and enterprise-adjacent subscribers often need a procurement cycle, not a nudge.
• Accounts mid-dispute. If a subscriber has told you the charge itself is contested, restriction during a good-faith resolution reads as retaliation. Pause the ladder while support resolves it, and document the pause.
• Team accounts. Restricting a whole team for one billing contact's expired card punishes people who cannot fix it. Target notices at the payer, warn the team before limits land, and consider restricting administrative and expansion actions before end-user work.
• Products holding critical data. Finance, health-adjacent, and records products carry a higher duty of care. Longer retention, export access that survives suspension, and conservative restriction are not generosity there — they are the product's trust foundation.
• Regulated and essential services. Some categories carry legal or ethical constraints on cutting access. If that might describe you, your policy needs professional advice, not a template.

The bottom line

A past-due access policy is a promise made in both directions: subscribers in good faith get time, clarity, and an easy way back, and the business gets a firm, stated end that it actually enforces. Inform first, restrict partially before you restrict fully, suspend only on the date you named, restore instantly on payment, and preserve data on a published clock. Decided in advance and communicated at every step, restriction recovers payments. Improvised late and sprung without warning, it manufactures the churn your dunning worked to prevent.

Frequently asked questions

When should I restrict access for a past-due subscriber?

Partial restriction usually belongs mid-window, after early retries and notices have had a fair chance and before the final deadline. Full suspension belongs at the end of the window, on the exact date your final notice stated. The first days of a failure should keep full access, since many failures clear on retry without any subscriber action.

What is the difference between partial restriction and suspension?

Partial restriction limits the product while preserving its core value, such as read-only access or paused premium features, so the subscriber feels urgency without losing their work. Suspension ends access entirely while preserving the account and data for a defined period. Payment should reverse either state immediately and automatically.

Should subscribers be warned before access is restricted?

Always. Every restriction step should be announced before it takes effect, with the date, what changes, and the single action that prevents it. Surprise cutoffs destroy trust and generate disputes, while a warned deadline is one of the strongest recovery triggers in the whole dunning sequence.

How long should I keep data after cancelling a past-due account?

Choose a defined retention period, publish it to the subscriber, and honor it exactly. The right length depends on your product and any legal duties you carry, but the principle is constant: cancellation of billing should not mean instant destruction of work, and a surviving account history makes later winback far more effective.

Should long-standing subscribers get a longer grace runway?

Often yes, and annual or high-value accounts justify it on economics alone. A longer runway with personal outreach before any restriction reflects both the revenue at stake and the likelihood that the failure is administrative. Whatever exception path you allow, write it into the policy so support applies it consistently.