Access can change while work is in flight.
A merchant can revoke an API key while a checkout request is running. A suspension can happen during checkout creation too. Those operations can overlap, and the payment system has to decide which authority governs the result.
Checking permission at the start of a request leaves a question unanswered: what happens if that permission changes before the operation finishes? We want a decision people can rely on when access is withdrawn.
Give concurrent decisions an enforceable order.
Our CairnPay change dated 27 July 2026 coordinates checkout creation with merchant authority and API-key authority in a consistent order. The authorization decision is part of the transaction that creates the checkout.
Work that has crossed the authorization boundary resolves before the revocation or suspension. Subsequent attempts are rejected. That distinction makes the withdrawal of authority enforceable without pretending that concurrent work happens one request at a time.
Exercise the race in PostgreSQL.
The existing PostgreSQL integration test runs checkout authorization alongside key revocation and merchant suspension. It checks the ordering of the operations and verifies that later rejected requests do not create checkout rows.
This is a property of the interaction between requests. Testing each request in isolation would miss the point where their decisions meet. The database test checks that boundary directly.