Stripe Cancellation Workflow Reconciliation: Rehearsal as Reference State

Cancelling a subscription at Acme can’t happen until a business owner approves it, but only if the subscription is still inside its contractual commitment term. That’s the specific exception we tested. On October 18, we ran a rehearsal against Stripe, Zendesk, Square, and Slack twins to confirm it. Four scenarios were checked, and all passed:

Scenario	Outcome
No cancellation while waiting	Passed
Authorized approval cancels	Passed
Rejection leaves unchanged	Passed
Restart while waiting, then approval cancels exactly once	Passed

You can see the full run here: view the rehearsal. The state reported was from the app, not from independent storage, and the email system was a simulated mailbox, not live SMTP.

The idea for production comparison is still unbuilt: compare business outcomes between compatible workflow versions. If IDs or timestamps differ, that’s not a failure. Without matching evidence, we can’t verify a result. Stripe’s docs on cancellation are here; note that immediate cancellation and cancellation at period end have different expected states. Webhooks can be out of order, see webhook docs.

To reproduce this, get the code from FetchSandbox playground and follow the exact steps in the product cancellation guide. Use private FetchSandbox authentication, managed relay, and isolated test/twin config. Then connect FetchSandbox MCP and ask your coding agent to verify state before approval, after authorized approval or rejection, and after restart. Current main is unpinned, so don’t assume it’s the same revision as the historical proof.