exact scheme is a fixed-price payment: the buyer authorizes exactly the stated amount, and exactly that amount settles on chain.
It is the default scheme and the one behind every fixed-price call. For the metered case, where the price is not known until after the work runs, see The upto scheme.
How a payment settles
1
The seller states an exact price
The
402 terms carry a scheme of exact, a network of stellar:testnet, an asset, an amount in atomic units, a payTo address, and a maxTimeoutSeconds.2
The buyer signs an authorization entry
The buyer signs a Soroban authorization entry permitting one
transfer(from, to, amount) on the asset’s Stellar Asset Contract, for exactly the stated amount to exactly the stated recipient.3
The facilitator verifies
/verify confirms the entry authorizes exactly the declared call, asset, amount, and recipient, is not replayed, and has not expired.4
The facilitator settles and sponsors the fee
/settle builds the transaction with the facilitator as the source, pays the network fee, and submits the transfer. The buyer needs only the payment asset.Auth entries, not pre-signed transactions
On Stellar the buyer signs a Soroban authorization entry, not a whole transaction. The entry permits one specific contract call and nothing else. The facilitator builds the transaction around that signed entry, sets its own account as the source, and submits it. This is what makes the scheme non-custodial and fee-sponsored at the same time. The buyer never submits a transaction and never spends XLM. The buyer’s wallet must support authorization-entry signing; the stock@x402/stellar client does this for you. See Stellar essentials for the wallet side.
Tamper with the amount, recipient, or asset after signing and verification fails. The authorization signs the exact call, so a changed field no longer matches the signature. This is tested, not asserted.
Ledger-based expiration
Each authorization is valid until a specific ledger,signatureExpirationLedger, derived from the seller’s maxTimeoutSeconds. The default of 60 seconds is about 12 ledgers at roughly 5 seconds each. After that ledger, the authorization is dead and the buyer signs a new one.
maxTimeoutSeconds is required on every listing. A listing without it is unconsumable and is rejected at cataloging. If an authorization expires between verify and settle, that is a coded settle rejection, not a crash, and the buyer signs again.
Sponsored, non-custodial settlement
The facilitator is the transaction source and pays the Stellar network fee. The buyer holds only the payment asset./supported advertises this with extra.areFeesSponsored: true, and the flag reflects real runtime configuration.
The facilitator never takes custody of funds and is never the source of funds. On any settlement the transfer’s from is the buyer, while the transaction source and the fee payer are the facilitator. Open the transaction in the Explorer and both facts are visible on chain.
Using it
exact is what a stock @x402/* client uses by default. The seller registers ExactStellarScheme from @x402/stellar, and the buyer registers the matching client scheme. The buyer and seller quickstarts show the full wiring. Amounts are integer strings at 7 decimals; never use floating-point math on an amount (see Stellar essentials).
When it fails
Every rejection carries a machine-readable code and a non-null reason. Commonexact codes:
The full list is in the error reference.
Next steps
The upto scheme
Authorize a ceiling and settle actual usage.
Stellar essentials
Trustlines, SEP-41 amounts, and smart accounts.
The payment loop
Where exact sits in the full flow.
Buyer quickstart
Pay a testnet endpoint and check the hash.