Activate and enforce paid membership access

How this work is checked

1. Begin with an approved free test identity and confirm a selected paid resource/action is denied at the backend.
2. Create a membership intent for an eligible connected demo plan from one of the three paths.
3. Complete the authorized simulated checkout and observe pending versus active access through the trusted result.
4. Reload/sign out/in and verify the same active entitlement and preserved free-account data.
5. Repeat the completion and attempt a forged client/URL/account-ID request; verify no duplicate or unauthorized access.
6. Using authorized fixtures/operations, expire or revoke the test entitlement and verify premium access is denied while the free account/data remain.

Backend requirements

• Current execution scope: connect the existing three paid-membership paths to genuine local auth, account/plan-bound intents and trusted local-test entitlement. No hosted service or real billing/email deployment.
• No free trial, temporary premium unlock, countdown trial or trial-to-paid enrollment. Public benefits, plan comparison and designated public content remain accessible without an account.
• Use the same title-specific membership catalog and checkout component. Preserve origin, selected plan and an allowlisted return destination through account verification/sign-in and completion.
• A plan selection, account creation, successful-looking return URL or role-switcher selection must not grant paid access. Activation requires the trusted backend outcome in D069.
• For this demo, checkout is explicitly simulated: no card collection, charge or live billing integration. Any stored test entitlement must identify its test source and be limited to authorized demo identities/environments. This is not a customer free trial.
• Show plan benefits, applicable term/renewal behavior and the simulated nature of checkout before confirmation. Connected membership pricing and print-bundle entitlements remain unset until decided; do not invent approved prices.
• Provide an existing-account sign-in route and an Already subscribe? route. Existing subscription linkage requires verified ownership and a separate mapping decision; an email claim alone does not grant access.
• Separate account verification, checkout pending and membership active states. Handle back/cancel/failure/session expiry and safely retry without duplicate accounts or duplicate activation.
• Model account identity separately from title/plan entitlement and any creator/guide/athlete/staff attributes. Print-only selection is not connected membership without an explicit entitlement mapping.
• Define the minimum conceptual records before writing migrations: membership intent, account/title/plan reference, status/source, event identity, effective dates where applicable, and actor/time/reason for grants/revocations. Final database design follows the reviewed workflows.
• No-entitlement/free, checkout pending, active and inactive/revoked outcomes must have explicit access behavior. Payment failure/cancellation changes an intent, not an unrelated account entitlement. No trial status or time-limited evaluation grant.
• Use authenticated server validation and database policies for connected protected reads/actions; the preview role selector and URL parameters must never grant authority.
• Validate plan eligibility, account binding and completion source; make repeated/replayed completion requests idempotent. Reject changes targeting another account.
• Use an explicitly configured, audited test-only activation mechanism limited to approved demo identities/environments. Do not ship a public endpoint that lets an arbitrary user self-grant real paid membership.
• Real payment collection, payment-provider webhooks and live subscription reconciliation are outside this story. Define their future trusted-completion boundary; no client success page may stand in for it.
• Provide a trusted current-access lookup and refresh behavior so UI gates and backend enforcement agree after activation, reload, expiry or revocation.
• Keep private account, intent and decision records restricted; a public plan catalog does not expose member records or billing data.
• Test owner/other-user/signed-out access, forged roles/URLs/IDs, duplicate/replayed requests, concurrent attempts, failure/cancel/pending states and expired/revoked access. Use synthetic local dev records; no hosted or production activation is authorized.
• Implement and verify the isolated local intent/test-entitlement slice for the normal dev joining paths. Hosted schemas/services, live billing and public enrollment remain outside this authorization.
• Use managed identity from D058/D085, trusted scoped assignment/MFA from D103/D088 and owner persistence in D089 as separate dependencies.
• Use digital/print-digital as synthetic dev identifiers only; keep commercial prices unset and a trusted test-only grant issuer distinct from client simulation or live billing.