x402 is a framework, not a single fixed payment format — it allows for different "schemes," each one a different way of constructing a valid payment for a given 402 response. The one DimeBox and most of the current ecosystem use by default is called exact, and the name describes exactly what it does: the client pays the exact amount quoted, no more, no less, for the exact request that triggered the 402.
Compare this to how a lot of real-world billing actually works: a subscription charges a recurring amount regardless of usage that period, a metered API tallies usage and bills in arrears, and a tip or pay-what-you-want flow accepts a range. exact rules all of that out by design. The amount in the PAYMENT-REQUIRED header is the amount that has to be signed — a signature for a different amount simply doesn't match the terms and gets rejected before the route ever runs. There's no running balance, no invoice, no "we'll true this up later." Each call is priced and paid for completely on its own.
Under the hood, an exact payment on an EVM network like Base is an EIP-3009 transferWithAuthorization signature: a message the token holder signs off-chain that authorizes a transfer of a specific amount, to a specific recipient, within a specific validity window, that can only be redeemed once. The signature itself never touches the network until someone submits it — in DimeBox's case, that someone is a facilitator, not the signer. See what EIP-3009 actually does for what's inside that signature and why it doesn't require the signer to hold ETH for gas, and x402 facilitators explained for who submits it and what they check first.
The signed authorization isn't just "pay $0.01 to this address" in the abstract — the terms in a PAYMENT-REQUIRED header are generated per request, which means a valid signature for one call can't be replayed against a different call, even one hitting the same endpoint a second later. That's part of what makes the flow safe to retry without double-charging: a network failure on the first attempt doesn't leave a signature lying around that could be reused by accident or by an attacker who intercepted it. See how a 402 response actually works, step by step for the full four-stage exchange this fits into, and is x402 secure? for the broader threat model around reuse and replay.
It's worth being explicit that exact has no concept of partial payment, overpayment credit, or a discount applied at settlement time. If the quoted amount and the signed amount don't match character for character, the payment is invalid — there's no logic anywhere that tries to be lenient about "close enough." That rigidity is a feature for a protocol meant to run unattended between machines: there's no ambiguous case for either side's software to get wrong, and no room for a rounding bug to quietly undercharge or overcharge a caller. A scheme with more flexibility would also mean more edge cases to test and more ways for two independent implementations to disagree about what counts as valid — exactness is partly what makes it practical to have many unrelated client libraries interoperate with many unrelated servers at all.
It's the server, not the client, that generates the PAYMENT-REQUIRED terms a given exact payment has to match. A client never gets to propose its own price and see if the server accepts it — it either signs what was quoted or it doesn't call the route at all. That asymmetry is deliberate: a pricing model where the caller proposes the amount would reopen exactly the kind of negotiation and dispute surface stablecoin micropayments are meant to avoid. Price-setting stays entirely on the side that knows the actual cost of running the route — which, for an AI-drafted email, includes a real inference cost that a client has no way to see or verify independently.
DimeBox's four priced actions — drafting an email, sending from an inbox, claiming a custom inbox name, priority delivery into an inbox — are all discrete, one-shot operations with a fixed cost each. There's no meaningful sense in which a draft "uses more" or "less" of anything depending on how long the email is or how complex the request was; the cost of generating one email is the cost of generating one email. A scheme built around usage metering or running totals would be solving a problem DimeBox doesn't have. exact matches the shape of the product: one call, one price, one signature, done. For the economics behind pricing things this way rather than bundling them into a subscription, see pay-per-call vs subscriptions.
If you want to see a signature like this actually constructed in code rather than described abstractly, signing your first EIP-3009 payment authorization in viem walks through it line by line.