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:

  • Discover that a resource requires payment
  • Understand its price and supported payment methods
  • Decide whether the purchase is permitted
  • Authorize the payment
  • Prove that it paid
  • Access the requested resource

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.

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.

Why Traditional API Billing Is Not Enough

Most paid APIs use one of these models:

  • Create an account and purchase a subscription
  • Add a card before making requests
  • Preload credits
  • Negotiate an enterprise contract
  • Receive an API key tied to a billing account

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:

  • A monthly subscription
  • A permanent account
  • A long onboarding process
  • A manually created API key

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.

What Is Stripe MPP?

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.

Step 1: The Agent Requests a Paid Resource

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.

Step 2: The Server Returns an HTTP 402 Challenge

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:

  • Payment amount
  • Currency
  • Payment method
  • Payment intent
  • Resource scope
  • Expiration details
  • Challenge identifier

MPP standardizes HTTP 402 through this Challenge–Credential–Receipt model.

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.

Step 3: The Agent Evaluates the Challenge

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);
}

This separation between receiving a payment challenge and authorizing it is central to building agents that can participate in paid workflows safely and predictably. By standardizing how payment requirements are communicated over HTTP, MPP gives both agent developers and service providers a clear, interoperable foundation for machine-to-machine commerce.