Proxy and gateway against Stripe test mode: refusals, a race and a lost answer
The scripted gateway run passed 14 of 14 rows, with one refund in an overlap (the other session told the outcome was unknown) and one after a lost answer settled by reconciliation; the proxy refused a foreign payment.
Prediction heldDoes it work?Working note
- Designed for
- Built to test whether the guard's MCP proxy and REST gateway keep their decisions against live Stripe test mode: refuse a foreign payment, let one lawful refund cross, hold one effect in a race and after a lost answer, and reconcile.
What was tested
Scripted clients with no language model ran against Stripe test mode, through the guard’s MCP proxy in front of Stripe’s MCP server and through the guard’s REST gateway. Stripe’s state was read directly; row expectations were written in the scripts, not preregistered.
What we observed
The proxy rerun ended with 0 non-OK rows: a foreign payment was refused under the provenance rule without crossing, and the control refund succeeded once. The gateway run passed 14 of 14 rows: in a race exactly one refund was made and the overlapping session got “outcome unknown”; after a lost answer, reconciliation and replay forwarded one refund request.
What this means for Heimdall
The guard’s simulated fault model carried over to the real test API in these rows. Its result bears on the executor’s same-action fence and the honest unknown, measured at the guard’s gateway.
Limits
Single scripted runs of the first-generation proxy and gateway on a tree with uncommitted files; the provider held the first proxy run’s control for human approval; the race’s replay branch was not seen; the proxy evidence is outside the repository.
What remains open
Commit the proxy evidence; repeat on today’s build.