A signed EIP-3009 authorization isn't money that's moved yet — it's a promise that becomes money once someone submits it to the token contract on-chain. In the x402 flow, that someone is a facilitator: a service that sits between the API server and the blockchain, verifying that a submitted signature actually matches what was quoted, then submitting it on-chain and reporting back whether settlement succeeded.
When a client retries a request with a PAYMENT-SIGNATURE header attached, the API server doesn't verify the cryptography or touch the blockchain itself — it hands the signature and the original payment terms to a facilitator and asks it to do two things, usually in sequence:
Only after both steps succeed does the API route run and, if its own response comes back under 400, consider the payment final. See how a 402 response actually works, step by step for exactly where this sits in the four-stage exchange, and why DimeBox never charges for a failed call for what happens when verification succeeds but the route itself fails afterward.
Running blockchain infrastructure — submitting transactions, tracking confirmations, handling the specifics of a given network's quirks — is a different job from running an email API, and conflating them would mean every x402-accepting service also has to be a competent chain-infrastructure operator. Splitting the role out means an API server only has to speak a fairly small HTTP contract to the facilitator ("verify this," "settle this," get back a yes or no) rather than maintaining its own node, its own gas wallet, and its own retry logic for chain congestion. It also means the same facilitator infrastructure can serve many different x402-accepting APIs, rather than each one duplicating that work.
A facilitator is trusted to verify correctly and to submit what it's given, not to approve or deny payments on substantive grounds — it isn't deciding whether DimeBox should accept this particular caller, just whether the signature matches math that was quoted. If a facilitator is unreachable, the API server has no way to verify or settle anything, which surfaces as a 502 rather than a charge — see the API reference's status codes table for the full list of what gets billed and what doesn't. Nothing about a facilitator's role gives it visibility into what the underlying API call was for — it sees payment terms and a signature, not the content of an email draft or a message being delivered. That separation of concerns is deliberate: a facilitator that had to understand what each route does in order to verify a payment would tie every API's business logic to its payment infrastructure in a way neither side wants.
Settlement isn't instantaneous — verifying a signature is fast, but submitting a transaction on-chain and waiting for confirmation takes real time, even on a low-fee network like Base. A caller shouldn't assume a paid route's response arrives in the same number of milliseconds an unpaid, un-gated endpoint would. This is part of why DimeBox's send endpoint returns 202 Accepted rather than waiting on a full SMTP round trip before responding — see queued delivery: why your agent shouldn't wait on SMTP — and part of why a caller's own timeout settings should leave enough room for a facilitator to actually finish verifying and settling before giving up and retrying.
It's fair to ask what happens if a facilitator misbehaves rather than just going down. Because the terms it's checking against are fixed by the API server's own PAYMENT-REQUIRED response, a facilitator has no room to quietly change the price, the asset, or the recipient of a payment — it can only confirm or reject against terms it didn't generate. And because settlement and route execution are tied together by DimeBox's own under-400 rule, a facilitator reporting bad data about whether settlement happened doesn't translate into DimeBox charging for something that never ran.
Trusting a facilitator correctly — and understanding what happens if it misbehaves, goes down, or is slow — is one piece of a larger security picture around pay-per-call APIs. is x402 secure? a developer's threat model for pay-per-call APIs covers that more broadly, including replay protection, signature validity windows, and what a caller should and shouldn't trust about the response on the other side of a 402.