Clarify when a saved test Checkout cannot reopen

Accepted October 18, 2026

The fresh native failed-card check and exact cleanup passed. Hosted Checkout declined Stripe's documented insufficient-funds test card. After that same Session expired, Resume displayed the reconciliation stop without opening another Checkout or offering a replacement purchase. Refresh, repeated Resume and ordinary sign-out passed.

Officer impact: a test member now knows when to keep the saved purchase, stop and ask Dave for reconciliation. The purchase remains locked; this adds no automatic recovery or authority to pay again.

Officer documentation: dated native acceptance, docs/officers/TEST_DUES.md, docs/officers/GLOSSARY.md, officer entrypoints and root/specialist checkpoints. A backup officer follows the screen-only stop/escalation procedure. Provider reconciliation and fixture retirement remain specialist duties.

Deployment evidence: website source 30d5f27 / finalized Hosting version 6619f96ac1a39406 remains independently qualified; all 62 published file hashes match. Final read-only verification on merged main ecf68f28ea67a7bb716a3ea01f2f98abc0970622 confirms both dues Functions remain ACTIVE v1 at backend 71f59e2, with identical 99,003-byte archives / c31a22ed digest. Same sandbox endpoint and eight events verified during native work; no provider setting changed. Documentation-only PR749 needed no redeployment. The earlier generic post-publish error is recorded and independently qualified; its reporting cause remains unqualified.

Approval and checks: implementation PR748 had exact-head Opus approval and green PR/main checks. PR749 received genuine Opus 5.5 medium APPROVE on exact final head e0e7ace54b5591192c6ddc07e099b65c0f27831d. Reviewed and merged tree 54923a9356a7e09157be46a8824e924d49341d4a matched. PR CI and main CI each passed all six jobs and all 62 steps, none skipped. Fifteen Markdown files, 161 local links and whitespace checks passed. No new app, backend, schema, migration, Rules, IAM, dependency or provider configuration change in the handoff.

Native evidence: one fresh order and one Session; expired/unpaid Session, canceled PaymentIntent with zero received, genuine expiry Event processed, original term retained, open order and no membership. No extra charge, unlock, refund or renewal. The earlier held fixture had no PaymentIntent and is cleanup evidence, not failed-card proof.

Cleanup: both owned fictional Auth users and eight allowed disposable paths are absent; six existing disposable records deleted; seven financial hashes unchanged; two processed expiry receipts retained. Ordinary sign-out and only owned-tab closure completed. Browser automation was reset. Historical fixture access, identities and financial keys must not be reused.

Real payments, production, family invitations and final club policies remain separate. This issue does not qualify every async/dispute/provider-method path or self-service recovery.

Original report and acceptance criteria (historical)

Officer impact: a supervised test member will know when a saved purchase cannot reopen and when to stop for specialist reconciliation. The current behavior is safe but can look like a working Resume control that does nothing.

Officer documentation: None — this issue proposes a screen clarification; the current verified safe-lock procedure is already in docs/officers/TEST_DUES.md and docs/TEST_DUES_NATIVE_RECOVERY.md. Update that guide and its native evidence with any implemented wording.

Deployment evidence: proposed wording is NOT AVAILABLE YET. This was observed in #742 native testing of current Hosting71f59e2/duesv1. PR746 records the dated native evidence; it changes documentation only. No production, real payment, extra provider method or account/security change is requested here.

Observed behavior

A fictional insufficient-funds card left a real sandbox PaymentIntent at requires_payment_method with zero received. After the native Session expired, the order correctly stayed open/locked. Resume returned the saved open order without a Checkout URL; the normal screen then said “Current test status loaded” and kept “Resume saved checkout.” It did not reopen checkout or offer another purchase. The officer guide correctly requires specialist reconciliation.

Smallest outcome

Give a clear stop/escalation message when Resume finishes without opening an unresolved Checkout. State that the saved purchase is retained and another payment must not be started. A useful wording is “Checkout could not be reopened. Keep this saved purchase and ask the test owner for reconciliation. Do not start another payment.” Do not infer expiry, payment, refund or eligibility from client state.

Invariants and acceptance

Keep original order, provider Session/key, payment evidence and original term unchanged. No replacement charge, automatic unlock/refund/renewal or authority override.
Preserve native session/identity/fresh-status fences, server-only decisions and no-polling behavior.
Focused rendered test: Resume receives the validated open order with no Checkout URL; stop message appears, navigation does not happen, and no prepare is attempted. Account/session changes clear stale state/message.
Native verification uses newly owned fictional fixtures only; never recreate Test annual dues: persisted Checkout and automatic payer membership activation #742's removed identities or replay their keys. Keep real payments separate and clean only exact owned disposable records.
Exact-head genuine Opus5.5 medium/max APPROVE plus all six CI jobs/every step green before any release. Verify matching hosted behavior separately; no backend deployment is assumed from frontend CI.

This is optional clarity work after the test-only, card-only/default-tenant qualification in #742. Family enrollment, legal policies, full dispute/async/tenant capability and production/live money remain separate.

The clarification is merged and published in staging. Native failed-card acceptance is incomplete; #747 remains OPEN.

Officer impact: Resume now has a clear reconciliation stop after a fresh server read confirms the same open, inactive purchase and no Checkout was opened. The saved purchase stays locked; no new prepare, replacement payment, membership override or expiry inference was added.

Officer documentation: docs/officers/TEST_DUES.md and docs/TEST_DUES_ENGINEERING.md changed with PR748. Their supervised availability remains gated on the still-pending native receipt. Existing #742 procedures/evidence remain historical and intact.

Deployment evidence:

Genuine Opus 5.5 medium APPROVED exact final head bd64d73800db803e39d59341d1b11c924bbb8754, zero permission denials/no fallback. PR748 merged 30d5f27d6eb2d47a7f85529e41f82a14001153e1, identical reviewed tree 21e5e75b51c999e921da98bd3494119f6e22fa78. Exact PR CI39096452255 and main CI39096722430 each passed all six jobs and all 62 steps, none skipped. The earlier formatting-only lint failure was corrected before approval/merge.
Both focused rendered/service suites pass, 23 tests; strict local lint baseline passes. Tests assert no navigation/prepare, fresh active/held precedence and dropped account/session late results. No schema/migration/backend/Rules/IAM/dependency change.
Firebase Hosting sites/run-mprc-staging/versions/6619f96ac1a39406 is FINALIZED, released by the club owner at 2026-10-18T04:24:14.553Z. The public marker names 30d5f27; all 62 public files match the retained staged build. The Hosting command returned its generic failure after publication; independent native/public readback qualified publication and no second deployment was attempted. The reporting cause remains unqualified. The previous local 62-file build was restored by every hash.
Independent dues verification before/after Hosting returned staging_test_dues_verified_without_deploy. Both ACTIVE v1 Functions remain at 71f59e26753b87f398b243cce5e995a44fcc538b, each 99,003 bytes, SHA256 c31a22edab34872dd10c3d3a44e12fdccf933dcb5659fb4db9ca99229d6c908b. Their authority/runtime/secret references and other targets were preserved. No backend or provider-setting deployment.

Fresh native test and safe hold:

One new uniquely owned fictional account/participant was created. Ordinary RUN (MPRC) Chrome sign-in and server offers worked with native Auth/App Check. One normal $25 USD order and one matching sandbox Session were saved with original term, provider reference, nonce/expectation fingerprints and idempotency identity. No retired Test annual dues: persisted Checkout and automatic payer membership activation #742/RACE-SIM-001C — Connect fictional race staging RPC status and member screens #731 identity or key was reused.
Chrome changed foreground/profile/tab context during native input. The automation guard repeatedly stopped actions. Provider readback showed one open unpaid Session, no PaymentIntent, no canonical membership. No native decline, expiration recovery or hosted stop-message acceptance is claimed.
A genuine exact-file Opus 5.5 medium review approved the safe-hold helper. Its native readback confirms the exact fictional participant marker is stopped, Auth is disabled and refresh tokens were revoked. It records browserReleased:false; no sign-out/closed-tab/cleanup evidence was fabricated. The original order/Session/term/payment evidence remain.
The owner has a pending coordination request for about three minutes without Chrome input. The club profile has no background browser connection; another profile is not an acceptable substitute.

Remaining: coordinate an idle Chrome window; complete exact-owned browser sign-out and Session/fixture reconciliation/cleanup; use fresh or explicitly reviewed restored fictional access to run the actual insufficient-funds -> expiry -> Resume case; verify the stop message/no navigation/no new purchase and one native Session; then update dated officer/native handoff and close only after acceptance. Do not replay retired financial keys, change the original order/term or bypass the disabled account/participant fence.

Real payments and production remain separate and untouched.

Native failed-card acceptance and exact cleanup passed on October 18. #747 remains open only for the reviewed documentation handoff in PR749.

Officer impact: normal Resume now gives the clear reconciliation stop while retaining the same open purchase. It does not reopen Checkout, offer another purchase, or infer payment/expiry from the browser.

Officer documentation: PR749 updates docs/officers/TEST_DUES.md, entrypoints/root checkpoints and docs/TEST_DUES_RECOVERY_MESSAGE.md with dated native proof and remaining specialist duties.

Deployment evidence: current Hosting30d/version6619 and all62public hashes verified; both dues Functions remain ACTIVEv1/source71f,99,003-byte/c31 archives unchanged. Same sandbox endpoint/eight events; no new deployment/provider setting/production or live-money operation. Exact source PR/main6jobs/all62steps passed before the existing release.

A fresh fictional account used ordinary Auth/AppCheck and one actual $25 sandbox Session. Stripe displayed the insufficient-funds decline; Link/browser saving were declined. Native PI read requires_payment_method/zero received. Exact saved-key expiry made the Session expired/unpaid and PIcanceled/zero; its actual Event processed/pending0. The original order stayed open, original calendar end unchanged, no membership. Resume displayed the full stop message on the dues route, with no new-purchase controls. Refresh cleared only the transient note; repeated Resume reproduced it. Native inventory confirmed one order/Session, no replacement. Ordinary Sign out cleared the note/actions and the owned tab closed.

Both this fixture and the earlier held fixture are retired. The earlier empty Session expired naturally and is not failed-card proof. Final native reads:2Auth absent,8allowed disposable paths absent,6existing disposable records deleted,7financial order/account/audit hashes unchanged,2processed expiry receipts retained. Genuine Opus5.5medium approved the exact helper bytes before writes;7guard tests passed. Browser automation state reset; other tabs preserved.

PR749 still needs exact-head Opus approval and all6CI jobs/every step green; it will not redeploy unchanged application/backend code. Production, real payments, family enrollment and final club policies remain separate.