Synthetic teaching example for a website delivery brief. Not a client result, live account test or certification.
Decide the policy before writing the switch
A member can reach a checkout success page without giving your application a permanent right to grant service. For a subscription website, commission an explicit entitlement policy: which verified state allows which feature, until when, and what happens when fresh source evidence is unavailable. Do not infer payment, expiry or authority from a browser redirect.
| Supplied condition | This teaching policy | Reason to discuss |
|---|---|---|
| Verified active or trialing, future approved accessUntil | ALLOW_IN_THIS_MODEL | Expiry is supplied, not invented from status |
| past_due, no approved grace | DO_NOT_GRANT | Grace is a merchant policy choice |
| past_due, approved grace and future expiry | ALLOW_IN_THIS_MODEL | Document the permitted duration |
| Unverified source | RECHECK_SOURCE | Unknown must not become paid |
| canceled or unpaid | DO_NOT_GRANT | No continuing grant in this model |
Use the filled example
Download the finite Node checker and filled input. Run with Node 24 or newer; no account, API or network is used.
node checks.mjs subscription-access-contract subscription-access-contract.jsonThe supplied case is verified past_due, checked at 00:00 UTC on 15 October, with an access deadline on 16 October but graceApproved false. It returns DO_NOT_GRANT. Changing only graceApproved to true grants access within this example; moving now beyond the deadline removes that grant. These are deliberate policy tests, not instructions to alter an actual subscriber.
Ask for evidence from both sides
During authorised acceptance, obtain a redacted authoritative subscription snapshot, the application entitlement row and the result of a restricted-feature request. Test trial expiry, payment recovery, cancellation and an unavailable source separately. A status badge without the protected-action result is incomplete evidence. Keep server-side checks separate from hiding a button in the interface.
This finite checker never retrieves Stripe, validates a customer, updates access or calculates an actual paid-through date. It is not a complete subscription engine. Existing users, contracts, disputes, prorations and the merchant’s approved grace policy need separate review; the example must not be pasted into production as a universal rule.
Primary facts and limits
Stripe subscription lifecycle: Distinguishes trialing, active and delinquent states; active does not necessarily mean every outstanding invoice was paid.
Sources reviewed 15 October 2026. The supplied input and acceptance rules are original teaching design; check current platform versions and your actual delivery contract before implementation.
Keep analytics purchase evidence separate from access rights