Upgrade Pay with verified billing data migrations and Stripe regression coverage

[philipithomas]

PR #78 applies a tested redirect mitigation and explicitly enables only Stripe while retaining Pay 5. It does not complete the Pay major-version upgrade or change billing data. Track that work separately so a framework update cannot silently migrate payment records.

Follow the upstream upgrade guide through each applicable release:

• Add subscription billing-period, metered, and pause fields; backfill existing JSON values.
• Add payment-method and Stripe account fields and backfill existing records.
• Apply the STI conversion and rename the payment-method type field.
• Add the stored Stripe object columns and update Pay associations to the pay_ names.
• Verify the selected Pay release's Stripe gem/API compatibility and webhook requirements, including charge.updated.

Acceptance criteria:

• Choose a currently supported patched Pay release that resolves both CVE-2023-30614 and GHSA-mjgf-xj26-9qf9; verify current advisory ranges before selecting it.
• Rehearse migrations on an isolated database populated with representative legacy customers, subscriptions, charges, and payment methods. Check record counts, relationships, backfilled values, and an explicit rollback/recovery plan. Keep external synchronization out of schema migrations.
• Add request and job coverage for checkout, billing portal, trials, cancellation/resumption, payment authentication redirects, failed payments, and signed Stripe webhooks. Cover duplicate and out-of-order webhook delivery. Run all tests in SOLO and MULTIUSER modes without live billing calls.
• Preserve the explicitly Stripe-only routing configuration. Any future processor enablement needs its own verified-signature and route tests.
• Remove the Pay compatibility backports and both .bundler-audit.yml exceptions only after the selected upstream version includes the fixes, protected-route regression tests pass, and an unignored dependency audit passes. Document any remaining compatibility constraints.

References: redirect advisory, Paddle signature advisory.

[philipithomas]

Current Stripe audit, September 5, 2026:

• Main 1397ff5 and runtime PR Upgrade supported runtimes and strengthen security and image checks #78 both lock Pay 5.0.4 and Stripe Ruby 7.1.0. Pay 5.0.4 explicitly sets outgoing API version 2022-08-01. This is repository evidence; the deployed Stripe account default, endpoint API versions, enabled payment methods and portal configuration were not inspected.
• Current official releases are Pay 11.7.0 and Stripe Ruby 19.6.1. Pay 11.7.0 requires Stripe ~>19, so these are a compatible target pair to rehearse. Updating Stripe alone under Pay 5 would violate the integration's compatibility boundary.
• Upgrade supported runtimes and strengthen security and image checks #78 already backports Pay's return-link XSS fix and limits routes to Stripe, with regression tests. It deliberately retains the legacy billing schema; merging Upgrade supported runtimes and strengthen security and image checks #78 does not complete this migration.

Recommended implementation order:

1. Fix the existing payment-entitlement gap in Enforce domain setup entitlement and preserve working domains on replacement failure #84. PaymentRequired#require_payment also bypasses its check for any session_id, so include that shared concern alongside domain setup. Retrieve and validate the account-scoped Checkout session and relevant subscription state, or render a bounded pending state while trusted webhooks synchronize it. A query parameter alone cannot establish entitlement. Preserve legitimate trial access and existing grandfathering/access policies.
2. Rehearse Pay 5 → 11.7 and Stripe 7 → 19.6.1 using the migration/association checklist in this issue. Preserve processor IDs and local relationships; do not create new customers/subscriptions as a migration shortcut. Keep the current 30-day trial, promotion codes, automatic tax and billing portal behavior in characterization tests.
3. Test real signed webhook requests (valid/invalid/stale signatures), duplicate and out-of-order events, asynchronous payment completion, trial ending, failed authentication/payment, cancellation/resumption, checkout return before webhook, and account deletion. Cover both current payloads and the target API shapes without live billing calls.
4. Verify the deployed webhook event set and API version separately from the SDK update. Stripe's versioning guide explains why changing an SDK does not verify or align every endpoint/account setting. Include charge.updated required by modern Pay and rehearse rollout/rollback before changing live settings.

Useful follow-on UX: show trial end, next renewal and past-due status in the dashboard; keep “Manage billing” discoverable for existing billing customers; give delayed checkout returns a clear pending state. Hosted Checkout, tax, promotions and the billing portal already exist, so expose their state before replacing those flows.

References: Pay upgrade guide, Stripe fulfillment guidance. No live Stripe settings, subscriptions or charges were changed.