Skip to main content
This guide is for the resource-server side of an x402 payment: a merchant, an API, or an agent-facing platform — an MCP tool, an agent-callable API, a dataset — that wants to charge for access without building settlement infrastructure or holding funds/keys.
  • Without a credential: Your server returns a 402 (payment required) listing the ways it accepts payment.
  • With a credential: Your server considers the payment valid (the payer has both signed and authorized the funds) and settles it through Atum’s x402 facilitator before returning the requested resource.
Two paths, depending on where you’re starting from:

Agentic receives

Run a working reference merchant locally, no code changes needed.

Develop with Atum SDK

Gate your own route, tool, or API directly.
By default the example merchant runs a stub that completes the full 402 → pay → 200 flow locally — no facilitator, gateway, or funds (you’ll see Facilitator: stub (local, no funds) at startup). To settle for real, set USE_STUB_FACILITATOR=false and a DEST_ADDRESS on the destination chain — FACILITATOR_URL already defaults to Atum’s testnet facilitator, so there’s usually nothing to replace. Full, up-to-date run instructions live in the x402-accept-payments example.

Idempotency on the acceptance side

x402 asks nothing new of your API for naming a purchase: declare the payment-identifier extension as required, and the payer supplies the id. Your job is:
  • Map settle outcomes to settled / still settling / failed / refused
  • Set PAYMENT-RESPONSE on unsettled outcomes too, so the payer can read the payment id and reason
  • Deliver once per receipt payment_id, not per request
  • Quote the same amount and the same accounts every time you re-issue a 402 for one purchase identifier — re-price it and the payer’s next attempt is refused with a 409 instead of resuming
Full model: Idempotency.

Next steps