The double refund on Stripe's sandbox below its approval threshold: a five-pair pilot
On a Stripe sandbox (test mode), below a deliberately chosen approval threshold, 5 of 5 unguarded pairs refunded twice and 0 of 5 guarded pairs did; the gateway's in-flight answer was used in 3 of the 5 guarded pairs.
Prediction heldDoes it work?Re-checked
- Designed for
- Built to test, at pilot strength, whether the simulator's double refund reproduces on a Stripe sandbox below its approval threshold, and whether the guard's gateway in front of the sandbox prevents it.
What was tested
In a five-pair pilot, not preregistered, two claude-opus-5 agents got one refund ticket at once against a Stripe sandbox in test mode. The refund sat below the approval rule’s threshold, narrowed beforehand from the default of holding every agent refund. Arms alternated: direct calls, or through the guard’s gateway.
What we observed
Unguarded, 5 of 5 pairs refunded twice; all 10 agents had first read an empty refund list, and no approval request was raised. Through the gateway, 0 of 5: the second refund was refused as a completed prior operation in 2 pairs and as in progress in 3, while the first was still in flight.
What this means for Heimdall
The provider’s own safeguard saw nothing below its threshold, and a check at the one point both agents passed held, including in flight. This bears on the executor’s same-action fence in flight.
Limits
Five pairs, one account, one model, test mode. The threshold was set above the test amount, so the safeguard’s silence holds by construction; under the default rule a stub trial showed the provider collapsing the duplicate itself. Provider-native idempotency was not compared.
What remains open
The planned preregistered series of 20 pairs has not run.