Settle an x402 payment
Verifies the buyer’s signed authorization, screens both parties, records the payment, and submits the USDC transfer onchain. For exact, the transfer is an EIP-3009 authorization submitted through a Circle relayer. For upto, it is a Permit2 transfer submitted from witness.facilitator.
A settlement outcome always uses HTTP 200. There is no pending status code. 4xx and 5xx responses mean the request was rejected or failed before settlement, with no outcome. Pending is not failure: settlement continues, and Get payment status reconciles the outcome. Do not fulfill on pending.
Pass a payment-identifier extension to scope idempotency to your seller account. Without an identifier, each retry must reuse the exact signed buyer authorization, or it’s treated as a new charge.
For upto, paymentRequirements.amount is the actual charge, from 0 up to the maximum the buyer signed. Each authorization settles at most once, and a request for it from a different seller returns 409 credential_bound_elsewhere. The buyer grants Permit2 allowance either by approving Permit2 onchain or by signing an eip2612GasSponsoring permit the facilitator submits with the settlement.
Example signatures come from a public test key. Never fund it.
Authorizations
Bearer token authentication with a Circle API key. Use this for production settlement. Settling with an API key also binds the payTo to your Circle account, which ends the keyless trial allowance.
Body
x402 protocol version. Facilitator Service supports version 2.
2 x402 v2 payment payload. Includes the payment terms the buyer accepted and the signed authorization for the USDC transfer: an EIP-3009 authorization for exact, or a Permit2 authorization for upto.
For upto, the payload sent to /settle must match the payload sent to /verify. The seller can only vary paymentRequirements.amount between calls.
Payment terms the seller advertises for an x402 resource. Facilitator Service validates that the buyer's authorization matches these requirements.
Response
The settlement outcome.
A terminal result means settlement resolved within the HTTP wait window. An unresolved result returns success: false with errorReason: settlement_pending and a paymentId.
A repeat request from the same seller for the same upto authorization returns the original payment, even with a different amount, when the other request terms match (such as resource.url, maxTimeoutSeconds, extra.name, and extra.version). Otherwise it returns 409 payment_identifier_conflict.
Whether the transfer settled onchain within the wait window. Check the settlement-status extension to distinguish failed from pending.
true
Buyer address recovered from the signed authorization.
"0x9aE2..."
Transaction hash on terminal success. Empty string when settlement is still pending or failed before submission. Also empty for an upto settlement of 0, which completes without an onchain transaction.
"0x6f9e1d..."
CAIP-2 network identifier for the settled payment.
"eip155:5042002"
Amount in atomic USDC units. For upto, this is the amount actually settled, not the maximum the buyer signed.
"1000000"
Reason code. Present whenever success is false, either because the payment failed terminally or because the outcome was unresolved at the wait deadline (settlement_pending).
settlement_pending, invalid_x402_version, unsupported_scheme, invalid_network, invalid_payment_requirements, invalid_payload, invalid_exact_evm_payload_recipient_mismatch, invalid_exact_evm_payload_authorization_value_mismatch, invalid_exact_evm_payload_authorization_valid_after, invalid_exact_evm_payload_authorization_valid_before, invalid_exact_evm_payload_signature, invalid_transaction_state, insufficient_funds, invalid_permit2_spender, invalid_permit2_recipient_mismatch, permit2_token_mismatch, invalid_upto_evm_payload_settlement_exceeds_amount, permit2_not_yet_valid, permit2_deadline_expired, upto_facilitator_mismatch, invalid_permit2_signature, permit2_invalid_nonce, invalid_eip2612_extension_format, eip2612_from_mismatch, eip2612_asset_mismatch, eip2612_spender_not_permit2, eip2612_deadline_expired, permit2_2612_amount_mismatch, permit2_simulation_failed "invalid_exact_evm_payload_signature"
x402 extensions. Facilitator Service returns a settlement-status extension only after a payment has been recorded: on settlement_pending and on terminal failures that have a paymentId. When present, the extension carries status, paymentId, and statusUrl.
Pre-recording validation failures (invalid_x402_version, unsupported_scheme, invalid_network, invalid_payment_requirements, invalid_payload, and the other request-validation errorReason values) return success: false with an errorReason and no extension, because there is no paymentId to reconcile.
Settlement returns no poll hints.