Machine Payments Protocol (MPP)
With the wallet set up and funded, AgentPay SDK can also call HTTP APIs that require inline payment.
This page covers the MPP and x402 request flow through agentpay mpp and agentpay x402.
What this page means by API
In this page, an API means a remote HTTP service endpoint, usually a URL such as <MPP_ENDPOINT_URL>, that accepts a request and returns a response.
Examples include:
a search endpoint
a scrape endpoint
a chat completion endpoint
In a normal API flow, the client usually authenticates with an API key.
In an MPP or x402 flow, the endpoint can instead return a machine-readable payment requirement. AgentPay SDK handles that payment step and then retries the original request in the same flow.
Background
Machine Payments Protocol (MPP) is an open standard for machine-to-machine payments via HTTP 402 Payment Required. It was co-developed by Tempo and Stripe.
MPP standardizes a machine-native payment flow for API requests, tool calls, and content instead of relying on custom billing integrations or ordinary API key provisioning.
For the protocol overview, see mpp.dev.
Before you submit
Before any MPP or x402 request, confirm three things:
The machine already has a wallet
The wallet is funded on the chain required by the service
The target endpoint supports MPP or x402
If any of those are unclear, go back to Wallet setup or Funding first.
Submit an MPP request
Use agentpay mpp for MPP-enabled HTTP endpoints:
The URL is required. The rest of the HTTP request controls are optional.
For example:
The command supports reusable HTTP request controls including:
--methodrepeatable
--header--data--json-body--amount--deposit--session-state-file--close-session
Use --json when you want structured non-streaming output.
How the request works
MPP lets a client request a resource, receive a machine-readable payment challenge, satisfy that challenge, and receive the real response without leaving the original HTTP flow.
MPP is payment-method agnostic at the protocol level. This page covers the AgentPay SDK client path: how agentpay mpp responds to an MPP-enabled endpoint and completes the request.
An MPP request has three main pieces:
Challenge - the server returns
402 Payment Requiredand describes the payment requirement in theWWW-AuthenticateheaderCredential - the client retries the request with proof that the payment requirement was satisfied
Receipt - the server returns the requested resource and may include a
Payment-Receiptheader confirming the response
Typical runtime sequence:
The CLI sends the request to the target endpoint
The endpoint returns
402 Payment Requiredwith the payment challengeagentpay mppreads the challenge and determines the amount, token, recipient, and chain required by the serviceThe CLI satisfies the challenge and retries the request with payment proof
The service verifies the payment and returns the actual response
Funding
Before using an MPP endpoint, the wallet must already hold the payment asset required by the service challenge on the required chain.
For MPP charge flows:
the payment chain comes from the server challenge
AgentPay SDK supports any EVM-compatible network for charge flows
on Tempo, the CLI uses the Tempo payment path
on other EVM networks, the CLI uses the corresponding ERC-20 payment path
Tempo mainnet with chain ID 4217 is included in the current AgentPay SDK release.
If the wallet does not hold the required asset or does not have enough balance, the request cannot complete. In that case, go back to Funding first.
Check the amount
agentpay mpp supports two basic amount modes:
omit
--amountwhen you want the CLI to accept the amount requested by the service challengeprovide
--amountwhen you want the CLI to verify that the server challenge matches the expected amount before paying
Example with explicit amount verification:
Use this when you want the CLI to refuse a request if the challenged amount differs from the amount you expected.
Use session mode on Tempo
For repeated requests on Tempo, agentpay mpp also supports session-style flows.
Session mode is useful when the same workflow will make multiple related requests and you want to reuse session state instead of treating each request as a separate one-shot payment.
This path supports session open, voucher signing, optional --deposit, persisted reuse through --session-state-file, and explicit close through --close-session.
Example:
Related flags:
--deposit- funds the session--session-state-file- persists session state across CLI invocations--close-session- closes the saved session and removes the local state when the flow is complete
Session mode is Tempo-only.
Use x402
Use agentpay x402 for x402-protected HTTP endpoints:
As with agentpay mpp, the URL is the required part of the command. Other HTTP request controls such as --method, repeatable --header, --data, and --json-body are optional.
agentpay x402 follows the same broad pattern: the server returns a payment requirement, the CLI satisfies it, and the original request is retried automatically.
In the current AgentPay SDK release, agentpay x402 supports exact-payment and EIP-3009 x402 flows.
The distinction in AgentPay SDK terms is simple:
use
agentpay mppfor MPP-enabled endpointsuse
agentpay x402for x402 payment flows where the server challenge defines the exact payment requirement
Output
Successful MPP responses can include a decoded Payment-Receipt.
In --json mode, AgentPay SDK includes that decoded receipt under payment.receipt when present. Tempo session responses can also include payment.closeReceipt when the close step returns one.
For Tempo session event streams in text mode, the CLI can also handle payment-need-voucher events automatically, including top-up and voucher replenishment when needed.
Operator notes
Keep these constraints in mind:
all request handling still happens locally on the operator's machine
the wallet must be funded before the request starts
--jsonis best for non-streaming responsesMPP session mode is supported only on Tempo
For the full workflow sequence, return to Workflows.
Last updated