Payment protocols

​

What problem do these solve?

Both protocols let an agent or script pay for an HTTP-gated resource — an API call, a tool invocation, a dataset — with no human in the loop. A client requests a resource, gets 402 Payment Required, signs a payment credential — a self-contained, signed payment authorization (the x402 spec’s “payment-as-credential”; read it as signed payment, not a login credential) — and retries. Atum settles both the same way underneath, and neither Atum nor your server ever holds the payer’s funds or keys. The difference between them is architectural: who verifies and settles the payment.

​

Which one do you need?

Match whatever protocol the other side of the payment already speaks:

• Paying for a resource? Use the protocol its 402 response speaks.
• Gating a resource? Use the protocol the clients or agents you want to serve already speak.

Building something new with no existing counterparty to match? Use the trade-off below.

​

Facilitated (x402) vs. Direct (MPP)

​

How your payment settles

Whichever protocol you use, Atum settles the payment the same way underneath: a signed request is submitted, independent settlement operators submit price quotes to fulfill it, the gateway selects one, funds move from the source rail into a settlement vault and are delivered on the destination rail, and you get a settlement receipt. You never contact settlement operators directly. For the end-to-end sequence, see the payment lifecycle; for who does what, see network participants.

​

Slow settlement

Both protocols collect a settlement that outruns the gateway’s ~30s window the same way: the acceptance side reports pending, and the payer re-attempts the same purchase. See Idempotency.

​

Next steps