Skip to main content

​
What is x402?

x402 enables agentic payments using a standard HTTP status code, 402 Payment Required, instead of a custom paywall. Only the client ever holds signing keys in this flow — your server and the facilitator only ever see the proof of payment, never funds or private keys. These docs guide you through Atum’s x402 facilitator — three operations (/verify, /settle, /supported) served by the Payment Gateway under the /x402/v1 prefix, not a separate service you point at.
x402 supports plug and play schemes, each configurable to a different payment method with its own rules for how the proof is built, signed, and settled.The most common scheme moves funds on a single network. Atum contributes its own scheme, built for multi-rail money movement:
  1. The payer funds a source in whatever asset they hold
  2. The merchant receives on their own chosen destination
  3. Atum’s network handles the conversion between the two

​
What Atum adds

​
How it works

1

Client requests a resource

A client hits your endpoint without a payment credential. Your server returns 402 with the payment options you accept.
2

Client signs and retries

The client picks a payment option, signs a credential authorizing the settlement vault deposit, and retries the request with a PAYMENT-SIGNATURE header.
3

Your server verifies

Your server sends the credential to the facilitator’s /verify endpoint on the Payment Gateway. No funds move.
4

Your server settles

After a valid response, your server calls /settle. The Atum network moves funds from the payer’s source chain to your destination chain.
5

Resource is returned

With settlement confirmed, your server returns 200 OK with the protected content and a PAYMENT-RESPONSE header carrying the receipt.
Cross-chain settlement can outrun the gateway’s ~30s synchronous window — that is pending, not failed. When it does, the facilitator reports settlement_pending with the payment id. Re-attempt the same purchase (same purchase identifier, freshly signed credential from a new 402) until you get a terminal outcome — the gateway resolves onto the original payment, so you cannot be charged twice. Do not poll inside the request, and do not start a new purchase. Use MPP if you’d rather the server poll the gateway for the result. Some testnet corridors — notably those bridging to slower chains like Tempo — routinely exceed this window. See Idempotency.

​
Next steps

Whether your agent needs to pay for a resource or your platform needs to charge agents for one, start with the guide for your side of the payment.

Make payments

Pay for an x402-gated resource as an agent or a script, in under five minutes.

Accept payments

Gate an HTTP route or agent-facing tool behind payment, in under five minutes.

Idempotency

What to do when a payment is still settling.

Facilitator API reference

Full reference for /verify, /settle, and /supported.