The x402 Facilitator for AI Agents and Apps

x402 is an open payment standard built on the HTTP 402 Payment Required status code. A server answers an unpaid request with 402 and machine-readable payment terms; the client signs a stablecoin payment and retries; a facilitator verifies and settles it on-chain. Buyer access requirements and merchant facilitator authentication are separate, and depend on the provider and payment scheme.

Timing depends on the network, payment scheme, confirmation policy and current load; there is no universal sub-second settlement guarantee. Verification does not move funds, and a transaction hash alone does not prove confirmation. A settlement_pending response is unresolved and can have an empty transaction field. For channel schemes, interpret success in the context of the specific operation, not automatically as the final merchant payout.

PayAI supports payment kinds across Solana and EVM networks including Base, Polygon, Avalanche, Arbitrum, Sei, X Layer and SKALE. Mainnet/testnet and scheme availability can differ. Call GET https://facilitator.payai.network/supported for the currently advertised combinations. Sponsored Solana payment flows can cover transaction fees for the payer; this does not remove every setup or service cost.

There is no single advertised payment range that applies to every PayAI scheme and network. Choose a customer price that satisfies the asset's precision, the advertised requirements and the selected scheme's rules. Batch deposit limits are not the price of each API request, and network costs are distinct from facilitator fees. Check current pricing and scheme guidance before choosing an amount.

Configure compatible x402 middleware to use https://facilitator.payai.network. Merchant and client quickstarts are available at https://docs.payai.network/x402/quickstart. Buyers still need a funded wallet and secure signing; merchants configure payment terms, authentication where required, and result/recovery handling. The facilitator handles supported blockchain verification and settlement operations. Pin and test your SDK version; the core API is described at https://payai.network/openapi.json.

Ordinary exact payments can use the available free tier without merchant credentials. Every batch-settlement verification and settlement request requires merchant authentication, including the first request. Send Authorization: Bearer <jwt>, using a short-lived Ed25519 (EdDSA) JWT signed with your merchant API key secret; never send the raw secret as the bearer token. Keep the private key server-side. Public reads need no token; authenticating GET /supported can select an account-specific fee payer. See https://docs.payai.network/x402/facilitators/authentication and https://docs.payai.network/x402/facilitators/pricing.

PayAI's facilitator fee is per settlement, never a percentage of the amount moved. From 21 September 2026 at 12:00 UTC each settlement costs the network's on-chain gas plus 30%, paid in credits at $0.001 per credit and refreshed daily from what the facilitator actually pays (about 1.33 credits on Solana mainnet and 2.12 on Base at the rates published today; testnets are free). Until then every settlement costs 1 credit. Ordinary exact payments have a free allowance of 1,000 credits per receiving wallet (lifetime, not a monthly reset), with shared-pool limits and legacy allowances described in the pricing guide. Batch authentication, channel deposits and token-account setup are separate requirements. The facilitator fee is not the price your API charges its customers. The live rate table, including any announced change and its effective time, is at https://facilitator.payai.network/pricing; details and account terms at https://docs.payai.network/x402/facilitators/pricing.

Application verification errors use isValid, invalidReason and invalidMessage; settlement errors use success, errorReason and errorMessage, with transaction, network and payer when available. Edge failures, timeouts and lost responses may not contain this JSON shape. Check status, content type and body together, handle unknown reason codes, and do not infer a settlement verdict from HTTP status alone. settlement_pending means the outcome is unresolved, not a payment failure or success. The transaction field can be empty; an empty field is not proof that nothing was broadcast. Preserve the original payment payload, requirements, receipts and any transaction identifier. Reconcile the same operation with backoff, following the selected scheme's recovery rules; do not create a fresh authorization just because a response was lost. duplicate_settlement can indicate an in-flight operation or a replay marker. Recovery records have bounded, scheme-dependent retention, so keep your own evidence and check chain state if the record is unavailable. See https://docs.payai.network/x402/facilitators/capacity-and-limits and the batch recovery guide at https://docs.payai.network/x402/servers/batch-settlement.

GET https://facilitator.payai.network/discovery/resources returns the Bazaar catalog, including last-recorded payment terms and seller-declared schemas when available. Entries can persist without refresh; a listing is not proof of current availability, successful settlement or service quality. Inspect lastUpdated, then obtain current requirements from the provider before paying. See https://docs.payai.network/x402/facilitators/bazaar.

Signed authorizations and scheme-specific validation are important controls, not a blanket security guarantee. Keep merchant private keys server-side, verify the advertised terms and network, and distinguish payment verification from settlement. Preserve receipts and reconcile unresolved operations before issuing a new authorization. Channel schemes have their own deposit, payout and recovery lifecycle; review the relevant integration guide.