> ## Documentation Index
> Fetch the complete documentation index at: https://docs.atum.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Accept payments using Atum and x402

> Gate an HTTP route or agent-facing tool behind an x402 payment, settled through Atum.

This guide is for the **resource-server side** of an [x402 payment](/payment-protocols/x402/overview): 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:

<CardGroup cols={2}>
  <Card title="Agentic receives" icon="robot" href="/payment-protocols/x402/accept-payments/agentic-payment-acceptance">
    Run a working reference merchant locally, no code changes needed.
  </Card>

  <Card title="Develop with Atum SDK" icon="code" href="/payment-protocols/x402/accept-payments/develop-with-the-sdk">
    Gate your own route, tool, or API directly.
  </Card>
</CardGroup>

<Note>
  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](https://github.com/Atum-Labs/examples/tree/main/x402-accept-payments).
</Note>

## 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](/payment-protocols/idempotency).

## Next steps

| Topic                          | Link                                                            |
| ------------------------------ | --------------------------------------------------------------- |
| Idempotency                    | [Idempotency](/payment-protocols/idempotency)                   |
| Payer-side guide               | [Make payments](/payment-protocols/x402/make-payments/overview) |
| Facilitator API reference      | [x402 Facilitator API](/api-reference/x402/introduction)        |
| What the facilitator validates | [Verify payment](/api-reference/x402/verify)                    |
| Settlement and receipts        | [Settle payment](/api-reference/x402/settle)                    |
| Supported chains and tokens    | [Supported kinds](/api-reference/x402/supported)                |