Skip to main content
POST

Authorizations

Authorization
string
header
required

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

application/json
x402Version
enum<integer>
required

x402 protocol version. Facilitator Service supports version 2.

Available options:
2
paymentPayload
object
required

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.

paymentRequirements
object
required

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.

success
boolean
required

Whether the transfer settled onchain within the wait window. Check the settlement-status extension to distinguish failed from pending.

Example:

true

payer
string
required

Buyer address recovered from the signed authorization.

Example:

"0x9aE2..."

transaction
string
required

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.

Example:

"0x6f9e1d..."

network
string
required

CAIP-2 network identifier for the settled payment.

Example:

"eip155:5042002"

amount
string

Amount in atomic USDC units. For upto, this is the amount actually settled, not the maximum the buyer signed.

Example:

"1000000"

errorReason
enum<string>

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).

Available options:
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
Example:

"invalid_exact_evm_payload_signature"

extensions
object

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.

Example: