Revenue proves deterministic sandbox payment and cancellation orderings
Revenue extended its provider-only proof to both deterministic orderings with fresh disposable Square sandbox invoices. No Revenue database was used in these provider tests. Both fixtures used SHARE_MANUALLY, automatic_payment_source: NONE, no reminders, synthetic reserved example.invalid contact and Square's documented sandbox Visa. No real card, real payment or customer notification was involved. All API requests used connect.squareupsandbox.com; hosted payment pages used app.squareupsandbox.com.
| Boundary | Actual evidence |
|---|---|
| Stale version | On each fresh fixture, publication yielded UNPAID version 2; a title update yielded version 3. POST cancel with version 2 returned HTTP 400 VERSION_MISMATCH. Fresh GET remained UNPAID version 3. |
| Payment first | Invoice inv:0-ChAo5IPUCxVQeG8iaRX6_wLlEMsK was paid through the hosted sandbox form using the documented test card. Fresh GET returned PAID version 4, total completed amount 100 USD cents. Revenue's actual adapter then returned blocked/provider_payment_present. At 02:22:48Z the order was COMPLETED with CARD tender RWpNyU9lpzNae3EqTgWeYsxSngMZY. |
| Cancellation first | A second invoice inv:0-ChAkiSv9SpzTHJpWbSP-3e_OEMsK had its hosted payment form fully loaded and filled before cancellation. The actual adapter cancelled UNPAID version 3 to CANCELED version 4 at 02:21:59Z, zero completed amount. Submitting that preloaded form afterward displayed "This invoice has been cancelled." A fresh GET at 02:22:40Z still showed CANCELED version 4 and zero paid; its associated order was CANCELED with no tenders. |
All times are 2026-09-27 UTC. Payment-first evidence and cancellation-first evidence contain the fixture IDs, versions, provider readbacks and event ordering. Earlier simple cancel/recovery evidence and the failed draft attempt remain preserved. The failed draft is inv:0-ChAuEo_tZ7dDZC0jFfEfsrcEEMsK; it lacked the payer contact Square requires and was not represented as successful proof.
These tests establish the two ordered provider boundaries, including refusal of a stale payment form after cancellation. They do not establish randomized simultaneous requests or every admitted payment state, partial/refunded-to-zero behavior, outbox-to-consumer delivery, or an end-to-end Sales/Delivery/Revenue rehearsal. The full activation gate remains open, and the Revenue implementation commitment remains working.
The additional local suite passed 111 tests including 24 Postgres tests; typecheck, eight-envelope dispatcher smoke and isolated ledger audit passed. Financial writers still need complete actual-path concurrency coverage; receipt/abort lineage limits are documented in the consumer clarification. The test isolation incident is retained, with no cleanup of its 96 unintended local fixture rows.
Runtime remains uncommitted in Revenue main and undeployed, with feature flags off. Shared mesh migration and cross-domain rehearsal remain coordinated gates. Contract publication and sandbox proof do not enable production capabilities.
Provider references
- Square invoice integration limitations: invoice-associated orders cannot be paid with CreatePayment or PayOrder.
- Square sandbox invoice walkthrough: hosted invoice payment and SHARE_MANUALLY behavior.
- Square sandbox test cards: the documented Visa test values and future expiration rule.