ISN->Premium Configuration Approach

1. Record the ISN Outseta tenant and whether it uses v2 or v3. Use the supported forms, billing screens, and API behavior for that version.
2. Identify which scripts and settings are shared with the production ISN website.
3. Use a dedicated test configuration or supported isolated test tenant for staging. Verify that test payments cannot create live charges or live Premium access.
4. Confirm the two staging hostnames above are the canonical test hosts; remove obsolete callback targets from the staging setup.

Version selection affects the checkout: v2 supports on-site purchase/profile flows; v3 uses Stripe-hosted checkout. Do not migrate the ISN account as an incidental part of this work. Outseta version reference.

1. Preserve or establish the ISN Free offering. Free registration must not require a payment method.
2. Create the approved ISN Premium offering and its allowed billing options. Preserve Free benefits when a reader upgrades.
3. Configure the path from an existing Free account to Premium. Keep the same person/account rather than creating a second account.
4. Record each stable plan/product/price identifier, its environment, the features it represents, and the allowed upgrade, downgrade, and renewal paths. Supply this mapping to XS.
5. Keep sponsor verification separate: a Free subscriber is not automatically a verified sponsor, and buying Premium does not approve a directory listing.

Input needed from ISN/XS: approved benefits, purchase eligibility, prices, billing schedule, and whether any team seats, discounts, or trials are in scope.

1. Confirm the connected Stripe account and approved selling entity. Use the approved legal name, receipt descriptor, support contact, currency, and tax configuration.
2. Set the amount charged today, recurring amount, billing frequency, minimum commitment, renewal term, and cancellation effective date.
3. Configure the approved payment methods and test any supported wallet or bank-authentication flow.
4. Place the agreed terms and final total visibly before purchase confirmation. Ensure the advertised offer and provider checkout agree.

Use the following proposed routes, or return equivalent existing routes to XS before integration. These are page requirements, not claims that the URLs already exist.

1. Use the appropriate Outseta-generated embeds or supported portal/checkout entry points for the confirmed version.
2. Keep account, login, registration, purchase, and recovery pages reachable without a Premium subscription.
3. Apply ISN styling, mobile layouts, field labels, keyboard focus, and accessible error/progress messages.

1. Show “Join ISN free” and explain the included free benefits. Collect only the required identity fields.
2. Configure email confirmation, password setup, or a supported passwordless flow. Show “Check your email,” resend, and recovery options where applicable.
3. For an existing account email, route to login/recovery. For a newsletter-only contact, provide account activation without duplicating the contact or losing consent preferences.
4. Preserve the reader’s intended destination and selected Premium offer through activation. After joining, a reader who chose Premium continues to purchase.
5. Keep newsletter preferences separate from account and subscription status. Marketing opt-out must not cancel a paid plan.

1. Keep normal ISN logins on ISN, returning to the requested ISN page or the approved ISN default.
2. For a Premium-origin request, read the explicitly supplied return context and preserve it through login and password recovery. Do not reconstruct it from document.referrer.
3. Allow only the approved Premium staging origin and safe content destinations. Reject foreign hosts and malformed destinations; use a safe fallback.
4. If Outseta already has a valid ISN identity, continue through the agreed handoff without requiring another password prompt.
5. Remove any global callback that sends every ISN login to Premium. Use Premium continuation only for a Premium journey.

Input needed from XS: the authentication-start URL, allowed return destinations, default destination, and transaction/state contract. Premium must initialize the transaction before Dodeka sends its token.

1. For a signed-out reader, offer login or Free account creation first; retain their selected offer. A brand-new reader follows Account → Subscription → Premium.
2. For a signed-in Free reader, show the current email and “Use a different account”, then open the correct authenticated upgrade flow.
3. For an already-entitled reader, show “Open Premium” and “Manage subscription” instead of starting another purchase. Recheck account status before launching payment.
4. Route lapsed, cancelling, or payment-failed accounts to the relevant renew, resume, or payment-recovery flow.
5. Handle decline, bank authentication, cancellation, Back, and abandoned checkout. Disable repeat submission and use provider-supported duplicate-purchase protection; coordinate any remaining account-level protection with XS.
6. On completion, continue to step 9. Do not declare Premium access ready from a browser purchase event alone.

1. Before leaving ISN, preserve its authenticated state using the supported Outseta token setter/persistence mechanism.
2. Echo the Premium-issued one-use state value and the validated return context. Do not invent or reuse a state value on the ISN page.
3. Send the token to Premium’s /auth/isn callback in the URL fragment, never an ?access_token= query parameter.
4. Match the exact approved hostname/path; remove obsolete placeholder endpoints and host-specific logic that only works on a Webflow preview domain.
5. Keep tokens out of logs, analytics, screenshots, and copied support URLs. Keep the continuation page free of scripts that could capture the token-bearing URL.
6. If the transaction expired, restart through Premium’s authentication initializer. If identity differs from the current browser account, require the agreed explicit account-switch flow.

Agreed target shape — placeholders only:
https://premium-staging.independentsponsor.news/auth/isn
  #access_token=<jwt>&state=<one-use-state>&return=<encoded-safe-path>

XS readiness required: the existing Premium identity endpoint must be extended to accept and validate state. Coordinate deployment before enabling the revised callback. XS handles immediate fragment removal and server verification on the receiving page.

1. Identify the actual purchase/plan-change events and supported token-renewal method for the ISN tenant’s version.
2. After a successful upgrade, obtain or await the current supported Outseta access token. Verify the person/account association and documented subscription claims are correct.
3. Pass through the authenticated continuation to XS’s confirmation flow, retaining the original content destination.
4. If confirmation or token renewal is delayed, show a pending/retry path. Tell the reader not to pay again; provide account management and support.
5. Test the inverse change too: downgrade, cancellation, or expiry must not leave Dodeka’s UI indefinitely presenting outdated paid status.
6. Send XS the JWKS URL, expected issuer/audience, lifetime, redacted claim schema, and observed event sequence. Share no raw tokens.

Input needed from XS: the confirmed continuation/confirmation URL and pending/error behavior. XS verifies subscription state on the server; a refreshed token alone does not currently activate a Premium membership in the application.

1. Point the public ISN Premium navigation link at the Premium staging landing page.
2. Use “Log in” and “Join ISN free” for signed-out readers. Where account state is available, offer “Subscribe to Premium” to Free readers.
3. Offer “Open Premium”, “Manage subscription”, and “Log out” to eligible signed-in readers.
4. Route authenticated Premium access through the agreed transaction-start/handoff flow. Never paste a bearer token into a normal navigation or email link.
5. Ensure every staging link stays in staging and preserves the intended content destination where appropriate.

1. On ISN logout, call Premium’s POST /auth/logout before clearing the token needed to coordinate the call. Follow XS’s exact request/origin contract; the existing endpoint supports credentials and a token in the JSON body.
2. Clear the ISN Outseta session on the ISN host, then show a public signed-out page.
3. Provide the ISN-side logout destination/handler that XS can use when logout starts on Premium. Coordinate the order so it does not create a logout or login loop.
4. If one host cannot be reached, complete local sign-out and show the incomplete cross-site logout with a retry. Do not claim both sessions ended without confirmation.
5. Leave the paid subscription unchanged. “Log out” must never mean “Cancel subscription.”

Input needed from XS: logout request format, allowed ISN origin, and Premium-origin coordination. Premium currently revokes that person’s Premium sessions across devices; do not promise equivalent global Outseta logout without testing it.

1. Configure account management to expose the approved plan/status, payment method, invoices, cancellation, renewal, and reactivation options. Restrict billing actions to the appropriate account owner.
2. Apply approved cancellation, grace, refund/dispute, and plan-change rules. Verify effective dates and any proration copy.
3. Register lifecycle notifications with the receiving URL supplied by XS: subscription start/change/end, payment success/failure, and available identity/account membership changes.
4. Enable webhook signing and share the key through the approved secret channel. Provide event names, redacted payload examples, account/subscription identifiers, and expected retry behavior.
5. Identify any event the tenant cannot supply, including refunds/disputes or identity changes, so XS can agree an alternate authoritative synchronization source before launch.

Input needed: owner-approved policies; XS’s deployed callback URL, secret-transfer method, and required event/schema contract. Dodeka configures the sender; XS builds the receiver and access reconciliation.

1. Configure activation, password reset, and Free welcome messages.
2. Configure one billing receipt source and a Premium welcome with a secure route to the content and account management.
3. Configure payment-action/failure, cancellation confirmation, and effective-expiry messages where supported by the approved flow.
4. Include the correct support contact and effective dates. Verify that marketing opt-out does not remove required account/billing communications.
5. Test with staging recipients; use staging account/content links. Coordinate with XS so its old simulated receipt does not send a duplicate receipt for the provider purchase.

1. Keep public marketing, login, Free sign-up, purchase entry, activation, recovery, and signed-out pages reachable as required. Billing management needs authentication but not active Premium access.
2. Review path-based protection rules across the configured domains. A rule intended for paid content must not capture a sales or account page.
3. Inspect the actual Outseta cookie Domain, Path, Secure, and SameSite behavior. Confirm staging cannot overwrite or reuse production identity.
4. Test supported browser/storage settings and give a useful recovery message if required scripts or cookies are blocked. Avoid repeated automatic redirects.
5. Remove stale callback placeholders and any script that sends or records tokens in query strings. Use exact environment-specific origins.

Use new, newsletter-only, Free, active Premium, cancelling, expired, payment-failed, and wrong-account test identities. Record the browser, account role, result, and safe reference for each test.

1. Free sign-up: create and activate an account; confirm no charge and no paid access.
2. Login: ordinary ISN login returns to ISN; a Premium request returns to its original destination.
3. Signed-out content access: a paying subscriber logs in and gets content without another purchase; a Free subscriber sees the upgrade offer.
4. Upgrade: buy Premium as an existing Free reader and as a new reader; confirm one account, one intended purchase, current token, and access.
5. Payment recovery: decline, bank challenge, checkout abandonment, duplicate clicks, and delayed completion give correct retry/help behavior.
6. Account management: update payment method, schedule cancellation, expire, and reactivate; verify the effective access dates jointly with XS.
7. Logout: begin from each site; check the other site, another tab, Back, and a failed cross-site logout call.
8. Security and usability: wrong account, bad return URL, expired state, private browsing, mobile Safari, desktop Chromium, and keyboard-only forms.

1. Deliver the final page URL list, Outseta version, catalogue IDs, approved terms, and environment mapping.
2. Include redacted token/event schemas, observed token-update sequence, callback/logout configuration, and completed staging test results.
3. List all outstanding decisions or unsupported behaviors. Separate Dodeka defects from XS endpoint dependencies.
4. Prepare production equivalents for hostnames, product identifiers, redirects, notifications, email links, and billing settings. Do not merely reuse staging values.
5. After production release authorization, apply the agreed changes and verify the same essential journeys. Keep a rollback that disables new purchase entry while preserving account recovery and existing-subscriber navigation.