Payment Delay & Access Restriction

Restrictions that arrive without warning, so the customer first learns of them as a blocked account and a support ticket, make the case for this journey; so do paid accounts that stay blocked until the next scheduled check. Before you start, make sure the due date, grace-period end and payment-completed event come from one authoritative source per account, that the service terms say when and how access is restricted, and that email subscription and push permission are stored. If most delays come from declined cards or broken payment methods, look at payment recovery first; this journey manages grace period and access, not the failure.

Incremental payment completion rate vs control

The journey earns its place by how many more warned accounts settle the overdue payment than the control group that gets no warnings; an opened email or a tapped push wins nothing by itself.

How it is counted: Count every overdue payment assigned at entry to the journey group and the control group, and take the share completed within the same follow-up window from assignment; the gap between the two groups is the journey's effect. Whether a message was delivered or clicked does not change the denominator.

Also track

• Paid within the grace periodAmong assigned accounts, the share that pays before the grace period ends and restriction is applied; this is the intermediate step the journey aims at, and it shows the accounts that never meet the restriction.
• Restoration after restriction and its delayRestricted accounts whose payment arrives, and the time between payment completed and access restored, are two separate numbers to watch; a paid account should not stay blocked waiting for the next check.
• Unsubscribes, push opt-outs and support contactsWatch email unsubscribes, push opt-outs and restriction-related support contacts per channel; if support contacts rise after the restriction notice, the way back is not being explained clearly enough.

• Trigger and entryA payment that passes its due date and becomes overdue starts the journey. Split accounts at random into the journey group and a control group that receives none of the delay and restriction messages; the restriction rule itself applies to both groups alike.
• Who must not enterOne overdue payment and the access it can affect is one journey instance, so no second flow opens for the same payment. Accounts that have already paid, or whose access consequence is undefined, do not enter; payment recovery, which handles failures and payment methods, is a separate flow.
• Timing and channelsThe delay notice and grace-period end date go out by email immediately; 3 days before the grace period ends, a push warns of the coming restriction. If the grace period ends unpaid, access is restricted and the reason and the way back follow by email and push; payment is rechecked 2 to 3 days later.
• Exit and handoffOnce payment completes, pending delay and restriction messages stop: paid by the end of the grace period means access continues, paid after restriction means access is restored and the user is told. If the second check still finds no payment, access remains restricted; there is no handoff, the journey ends in these two exits.
• Frequency and consentAt most four touches per overdue payment: two warnings, the restriction notice and, if paid, the restoration notice. Email is used only with a subscription and push only with push permission; the restriction notice must spell out exactly how access is restored, and the restoration notice confirms it is back.

1. 1When warned accounts complete payment no more often than the control group, the warnings may only have pulled forward payments that would have arrived a few days later anyway; opens and taps do not make up for that. Weigh the payment gap between the two groups against the change in support contacts before you decide.
2. 2A result here describes this grace period, the 3-day warning lead and this channel order, nothing wider. Do not credit this journey with a payment that payment recovery handled because of a failed charge; read payment state from one source so the two flows never send conflicting messages to the same account.
3. 3With few overdue payments, the gap will swing from week to week; enter each group's accounts and completed payments into the A/B test significance calculator to see whether the difference is significant, and if it is not, extend the follow-up window to cover at least the post-restriction check before calling the journey a winner.