How Stripe MPP Uses HTTP 402 to Authenticate and Authorize Machine Payments Stripe and Tempo launched the Machine Payments Protocol (MPP) in March 2026 as an open standard for machine-to-machine payments. The protocol uses HTTP 402 Payment Required to authenticate and authorize AI agents' access to paid resources, enabling microtransactions and recurring payments without human interaction. Stripe's current integration supports crypto payments via on-chain deposit addresses and fiat payments through Shared Payment Tokens. AI agents can search the web, call APIs, analyze documents, generate reports, and coordinate multi-step workflows. However, many agent workflows stop when they reach a paid resource. Traditional checkout systems were designed for humans. They often require users to create an account, select a plan, enter payment details, complete verification, and navigate redirects. An autonomous agent needs a machine-readable alternative. It must be able to: The Machine Payments Protocol , or MPP, introduces a standardized way to handle this process through ordinary HTTP requests. MPP was launched in March 2026 as an open standard co-authored by Stripe and Tempo. It enables agents and online services to coordinate payments programmatically for APIs, content, tools, and other HTTP-addressable resources. Stripe 1 Its core flow is built around three objects: Challenge → Credential → Receipt Let’s examine how that flow uses HTTP 402 Payment Required to authenticate payment credentials and authorize access to paid resources. Most paid APIs use one of these models: These approaches work well for recurring human-controlled usage. They are less suitable when an agent needs to purchase one small resource from a service it has never used before. Consider an AI research agent that needs a single premium market report. The agent may not need: It only needs to discover the report’s price, pay for it, and receive the result. Stripe describes MPP as an internet-native protocol through which a service can request payment as part of the agent’s resource request. It can support machine-oriented business models such as microtransactions and recurring payments. Stripe 1 MPP is a protocol for machine-to-machine internet payments. When a client requests a paid resource, the server returns an HTTP 402 response containing payment requirements. The client authorizes the payment, retries the request with a payment credential, and receives the protected resource with a receipt after successful verification. The complete flow looks like this: Agent requests a protected resource ↓ Server returns 402 Payment Required ↓ Response contains a payment Challenge ↓ Agent evaluates and authorizes payment ↓ Agent retries with a Credential ↓ Server verifies the Credential ↓ Server returns the resource and Receipt MPP does not require every provider to use one specific payment rail. The protocol standardizes how clients and servers communicate payment requirements while payment methods handle the actual movement of money. Stripe’s current MPP integration supports crypto payments through on-chain deposit addresses and fiat payment methods through Shared Payment Tokens. Suppose a provider exposes this endpoint: GET /api/reports/market-analysis The agent sends a normal request: GET /api/reports/market-analysis HTTP/1.1 Host: reports.example.com Accept: application/json The server checks whether the request contains a valid payment credential. Because this is the first request, no credential is available. Instead of returning the report, the server responds with 402 Payment Required . The response may conceptually look like this: HTTP/1.1 402 Payment Required WWW-Authenticate: Payment challenge="..." Cache-Control: no-store Content-Type: application/problem+json { "status": 402, "title": "Payment Required", "detail": "Payment is required to access this market report." } The WWW-Authenticate header carries the MPP Challenge . A Challenge tells the client what must be done to obtain the protected resource. It can include information such as: MPP standardizes HTTP 402 through this Challenge–Credential–Receipt model. MPP — Machine Payments Protocol 2 A server can also return multiple payment challenges when it accepts more than one payment method. Stripe’s quickstart demonstrates an endpoint offering both crypto and fiat payment options, allowing the client to choose a supported method. The key improvement is that the price is now machine-readable. The agent does not have to scrape a pricing page or understand a checkout interface. Receiving a 402 response should not mean that the agent pays automatically. Before authorizing payment, the agent should evaluate its spending policy: Is this provider trusted? Is the requested amount within budget? Does this purchase support the current task? Is this payment method allowed? Does the transaction require human approval? A basic policy could look like this: type PaymentChallenge = { amount: number; currency: string; merchant: string; resource: string; }; function canAuthorizePayment challenge: PaymentChallenge : boolean { const approvedMerchants = new Set 'reports.example.com', 'search.example.com', ; return approvedMerchants.has challenge.merchant && challenge.currency === 'USD' && challenge.amount <= 1 ; } For higher-value or sensitive transactions, the agent could request approval from a human before proceeding. MPP coordinates payment communication. The application controlling the agent remains responsible for spending limits, merchant restrictions, and approval policies. After approving the payment, the client satisfies the Challenge using one of the available payment methods. It then creates an MPP Credential and retries the original request: GET /api/reports/market-analysis HTTP/1.1 Host: reports.example.com Accept: application/json Authorization: Payment credential="..." A Credential is the client’s response to the Challenge. It proves that the required payment was completed or appropriately authorized. MPP Credentials are transmitted using the HTTP Authorization header. MPP — Machine Payments Protocol 3 The Credential should correspond to the original payment terms, including details such as: Binding the Credential to the Challenge prevents a payment intended for one resource from being treated as authorization for an unrelated resource. When the server receives the second request, it verifies the payment Credential. This is the authentication part of the MPP flow. The server is effectively asking: Is this a valid payment Credential that satisfies the Challenge issued for this request? Conceptually, the verification may look like this: type VerificationInput = { credential: string; expectedAmount: string; expectedCurrency: string; expectedScope: string; }; async function verifyPayment input: VerificationInput : Promise