AI payment processing: How agents pay for APIs with MPP

AI payment processing is how an agent requests, authorizes and completes a payment for a service, within limits a person or business sets. This guide explains how the Machine Payments Protocol (MPP) uses HTTP 402 to let agents pay for APIs, which payment rails sit underneath, and how to choose a billing model. For the infrastructure side, see Tempo's agentic payments solution.

Picture a research agent that needs one premium market-data lookup. Today it hits a sign-up page, a billing form and an API key tied to a human account, all to buy a response that may cost a few cents. A person can work through that once. An agent calling dozens of paid services cannot.

Agent use is growing quickly. In PwC's 2025 survey, 79% of surveyed executives said their companies were adopting AI agents. A study of 177,436 MCP tools found that action tools rose from 27% to 65% of usage over 16 months, and some of those tools handled financial transactions.

What is AI payment processing?

AI payment processing is the set of systems that let an agent request, authorize and complete a payment for a service within permissions and spending limits set by a person or business.

It has three parts: a way for a server to state a price in machine-readable terms, a way for the client to check that price against its budget and pay, and a way for the server to verify payment before it delivers. The Machine Payments Protocol (MPP), co-authored by Stripe and Tempo, is an open protocol that standardizes those steps for machine-to-machine payments.

AI payment processing vs. agentic payments

Agentic payments is the broader category: any payment an agent initiates, including purchases on behalf of a consumer. AI payment processing, as used here, focuses on the request-level flow that lets software pay software for APIs, data and compute.

Why API payments need a machine-readable flow

Most API billing assumes a long-term customer. Access usually starts with an account, a stored payment method, a pricing plan and an API key. That model fits a team that commits to a provider for months. It fits poorly when an agent needs a single response, a short burst of compute or a tool it may never call again.

Small, one-off purchases also strain card economics. Card processing usually includes a fixed per-payment component, which makes charges of a cent or less hard to price on their own. Microtransactions need either a cheaper rail or a way to bundle many small charges into one settlement.

How MPP works

MPP builds on the HTTP 402 Payment Required status code. The server uses a 402 response to tell the client that a resource needs payment and to send the terms. The basic HTTP flow has five steps:

1. Request. The agent sends an HTTP request for a resource, such as an API response or a dataset.
2. Challenge. The server returns 402 with a machine-readable payment challenge that lists the price and accepted payment methods.
3. Fulfillment. The client checks the terms against its configured budget and permissions, then pays with a supported method. If the price exceeds its limits or funds are short, it stops or asks for approval.
4. Credential. The client builds a payment credential with the method-specific proof or authorization and retries the request with it in the Authorization header.
5. Delivery. The server verifies the credential and payment, then returns the resource with a payment receipt.

MPP is also transport agnostic, with bindings for HTTP, MCP and WebSockets. The transport decides how client and server exchange messages; the payment method decides how money moves.

Payment rails underneath MPP

MPP is payment-method agnostic: the same challenge-and-credential flow works across different payment rails. Developers pick the method that fits their customers and price points.

Card payments

Stripe's MPP integration supports card payments using Shared Payment Tokens. A token grants scoped access to a payment method, with usage and expiration limits, so the agent can pay without seeing card details. The payment then appears in Stripe alongside the business's other payments.

Stablecoin payments

Stablecoins on a blockchain can carry small payments with low network fees and settle onchain at any hour. For high-frequency usage, MPP sessions on Tempo let a client fund a payment channel and sign offchain vouchers that track cumulative spending. The provider settles the total onchain, so each API call does not need its own onchain transaction.

Stablecoin payments have real limits. An agent's wallet still has to be funded, and on-ramps and off-ramps follow local banking hours, provider coverage and local rules. Accounting, tax treatment and refunds remain the business's processes.

Choosing a billing model: one-time payments, sessions and subscriptions

MPP supports three common billing patterns. The right one depends on how often a client calls the service and whether the price is fixed.

A one-time charge is the simplest to add and the easiest to audit. Sessions cut per-call overhead when an agent makes many small requests. Subscriptions suit predictable, fixed-price access.

How to add MPP to an existing API

MPP payment verification sits beside an application's existing authentication, authorization and billing logic. Teams usually choose one of three patterns, covered in more depth in the guide to API monetization:

• API gateway. Put MPP in front of the existing API. The gateway runs the payment flow, and the application keeps serving requests.
• Per-endpoint pricing. Require payment only on chosen routes, such as premium models or compute-heavy operations, and keep other routes free.
• Paid MCP tools. An MCP server returns an MPP payment challenge when an agent calls a paid tool, so each tool call can carry its own price.

Before charging, decide how the service handles failed or partial deliveries, how it issues refunds and what receipts it stores for reconciliation.

Spending controls for agents

An agent that can pay needs limits that hold even when its instructions go wrong. Developers usually set a per-request maximum, a total budget and an expiry. Session keys are one way to delegate narrowly scoped permissions from a primary wallet, limited by amount, transaction type and time. Payments above a threshold can route to a person for approval, which matches step three of the MPP flow.

Where Tempo fits

Tempo is a payments-focused blockchain that supports MPP as a stablecoin payment method.

• Onchain settlement in under a second. Stablecoin transfers on Tempo settle onchain in under a second, which suits per-request API payments.
• Fees in stablecoins. Tempo has no native gas token; network fees are paid in supported stablecoins, and standard transfers have sub-cent fees.
• Payment lanes. Dedicated payment lanes reserve blockspace for qualifying payment transactions.
• MPP sessions and subscriptions. Tempo's MPP payment method supports one-time charges, metered sessions and subscriptions.

The API provider still owns pricing, access control, refunds and the agent's spending policy, and funding and withdrawals depend on ramp providers.

Frequently asked questions

What is AI payment processing?

AI payment processing is the set of systems that let an agent request, authorize and complete a payment for a service within permissions and spending limits set by a person or business.

Do agents need cryptocurrency to use MPP?

No. MPP supports card payments through Stripe as well as stablecoin and other blockchain payments. The available options depend on the payment methods the client and server implement.

Which blockchains support MPP payments?

MPP documents payment methods for stablecoins on Tempo and for other networks, including Solana and the Bitcoin Lightning Network. Supported assets and billing models vary by payment method.

How do agents pay for API calls without a person in the loop?

The client reads the server's payment challenge, checks it against its budget, fulfills it and retries the request with a payment credential. The server verifies the payment before it returns the resource.

Is MPP a replacement for card networks or bank payments?

No. MPP is a protocol for negotiating and proving payment inside an API request. Money still moves over card networks, blockchains or other rails that the payment method uses.

Who sets an agent's spending limits?

The developer or business deploying the agent sets them in the client, wallet or payment method. MPP carries the price and payment terms, but it does not decide whether a purchase is allowed.