The payment failed. Access did not stop immediately.
July 13, 2026
The SAR 499 renewal failed on Monday morning. Payment recovery has started, but the customer’s team is already inside the product creating reports.
Should everything stop now? Should they keep full access for a week? And if payment still has not arrived, what changes first?
The grace period answers those questions before a failed payment forces support to improvise.
Start with the work you are protecting
A grace period is the time between a failed renewal and a change in service. Its purpose is to give a willing customer enough time to fix payment without exposing your business to unlimited cost.
The right policy depends on what interruption does to the customer.
If a design tool pauses new exports, completed files still exist. If an API stops immediately, the customer’s production system may fail. If an AI product keeps generating without payment, your cost continues with every request.
So the first question is not “three days or seven?” It is: which customer work must remain safe while payment is unresolved?
Change access in stages
For the report product in this series, the team chooses a seven-day policy:
- full service continues while payment recovery runs;
- reminders explain the deadline;
- after day seven, existing reports remain available but new report generation pauses;
- successful payment restores full service immediately.
Payment is unresolved; access changes in stages
This policy protects completed work and avoids a sudden first-day shutdown. It also stops new AI cost after the deadline.
The timeline is part of the commercial policy. Product, billing, support, and the customer message should all describe the same dates and access state.
Decide what remains available
“Grace period: seven days” is incomplete. The customer needs to know what seven days means inside the product.
| Product capability | During the seven days | After the deadline |
|---|---|---|
| View completed reports | Available | Available |
| Download existing reports | Available | Available |
| Generate a new report | Available | Paused |
| Invite new team members | Available | Paused |
| Update payment method | Available | Available |
Read-only access is often a useful middle state. The customer keeps their data and can complete payment, while actions that increase your cost stop.
Not every product needs that middle state. A low-cost collaboration feature may stay fully available. A high-cost API may need a shorter period or an immediate rate limit. Use the economics and operational risk of the feature—not one rule copied across the catalog.
Set the length around a real recovery window
Your payment-recovery sequence already has a schedule. The grace period should be long enough to contain the retries and customer response time.
If you retry on days 0, 3, and 7, ending access on day 2 makes the later recovery sequence meaningless. Keeping full service for 30 days creates a month of unpaid usage before the policy has any effect.
A practical policy usually considers:
- how often customers update payment after the first notice;
- whether bank failures commonly clear after a few days;
- how quickly unpaid usage creates material cost;
- and how damaging an interruption is to the customer’s own operations.
The result may be three days, seven days, or fourteen. The reason behind the number matters more than copying an industry default.
Tell the customer the date and the change
“Your account is past due” does not explain what happens next. A useful notice says:
We could not collect SAR 499 for your renewal. Report generation will pause on 17 July if the invoice remains unpaid. Your existing reports will stay available. Update your payment method to continue without interruption.
The customer now knows the amount, deadline, exact product impact, and next action.
If payment succeeds, restore service automatically. Do not leave the account waiting for a support agent after the money has arrived.
Keep data retention separate
Pausing service is not the same as deleting customer data. The grace period controls access after non-payment. Data retention controls how long information remains after suspension or cancellation.
Keep those policies separate and state both. A customer who misses a payment should not discover that “access paused” secretly meant “reports deleted.”
In Tirdad, the subscription and invoice carry the payment state while entitlements determine which capabilities remain available. Once payment succeeds—or the deadline arrives—the configured access change applies consistently without a manual support decision.
A good grace period gives the customer time to fix payment, protects completed work, and puts a clear limit on new cost.
Eight connected decisions—from the first usage event to recurring revenue.
Set the rule once. Tirdad applies it every time.
Keep the policy, effective date, customer agreement, and invoice calculation in one billing system instead of rebuilding the decision in every product surface.