Skip to main content

​
What is MPP?

The Machine Payments Protocol (MPP) enables agentic payments over HTTP, built on the same 402 Payment Required status code as x402. Unlike x402, MPP has no facilitator. Only the client holds signing keys — the server verifies the credential and settles it in-process by submitting to Atum’s Payment Gateway, with no separate facilitator service in between. These docs guide you through Atum’s payment method for MPP — how to pay for, and charge for, MPP-gated resources.
MPP supports interchangeable payment methods, each with its own rules for how the credential is built, signed, verified, and settled.Atum lets the payer fund payments from a supported source, while the merchant configures the destination asset, network, address, and exact amount it receives.The server registers the method with the MPP SDK. It verifies the credential and submits the payment to Atum’s Payment Gateway, which coordinates settlement between the source and destination.For the protocol itself — the challenge, credential, and receipt wire format — see the MPP specification.

​
What Atum adds

​
How it works

1

Client requests a resource

A client hits the endpoint without a payment credential. The server returns 402 with a challenge listing the payment methods it accepts.
2

Client signs and retries

The client reads the challenge, signs an authorization for the source-chain deposit it specifies, and retries the request with an Authorization: Payment header.
3

The server verifies

The server checks the credential in-process — recovering the signature and checking every term against the challenge. No funds move yet, and there is no facilitator to call.
4

The server settles

The server submits the signed request to Atum’s Payment Gateway, which moves funds from the payer’s source chain to the merchant’s destination chain.
5

Resource is returned

With settlement confirmed, the server returns 200 OK with the protected content and a Payment-Receipt header carrying the receipt.
Cross-chain settlement can outrun the gateway’s ~30s synchronous window — that is pending, not failed. Your submitter should submit and return what the gateway said — do not poll inside verify(). When settlement is still in flight, raise SettlementPendingError with the payment id and let the payer re-attempt the same purchase. The gateway resolves onto the original payment, so the re-attempt cannot charge twice. 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 MPP-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.

Payment Gateway API reference

Full reference for submitting payments and reading status.