Synthetic test matrix for duplicate and out-of-order Stripe events

Fixture assumptions

This is an authored synthetic test specification, not an executed integration or client result. Use two disposable app users, one test subscription per user and a documented access policy. All events must use a test route; this specification does not require real customer data or live billing actions.

• User A buys the test plan; User B has no plan and must remain blocked.
• The test policy grants access after the agreed payment and current-subscription checks.
• The policy states what happens on past_due and on actual subscription end.

Replay cases and expected invariants

Expected results are assertions to implement, not evidence that they already pass. Capture the redacted event ID, processing result and before-and-after state for each case.

• Same event twice: the second delivery produces no duplicate entitlement, notification or subscription row.
• Different events about the same business transition: operation-level safeguards prevent repeating a non-repeatable side effect.
• Older update after cancellation: the handler checks authoritative current state and does not resurrect ended access.
• Unknown user mapping: no other account is updated; the event is retained for a controlled exception route.
• Invalid signature: no access mutation occurs.

Crash and recovery cases

Simulate a worker stopping after durable receipt but before the access update, then resume processing. Separately simulate a completed update before acknowledgement and deliver the event again. These cases test whether receipt, processing and completion have distinct recoverable states instead of relying on an HTTP success alone.

• Recovery either completes the intended update once or exposes a clearly recorded exception.
• No test sends a real email, charge, refund or production entitlement.
• The review compares event history with both allowed and denied app requests.

What remains outside the example

This matrix does not validate tax handling, disputes, Connect payouts, financial reconciliation or an existing membership vendor's entire behaviour. It illustrates the reliability checks needed around a subscription integration. A runnable implementation and independent exercise would be separate evidence; neither is claimed here.