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. ([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.
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. ([Stripe][1])
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. ([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.
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) &&
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.
Step 4: The Agent Creates a Payment Credential
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:
- The Challenge
- The amount
- The currency
- The intended resource
- The payment method
- The request scope
Binding the Credential to the Challenge prevents a payment intended for one resource from being treated as authorization for an unrelated resource.
Step 5: The Server Authenticates the Credential
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<boolean> {
// Illustrative pseudocode.
const result = await paymentProvider.verify({
credential: input.credential,
amount: input.expectedAmount,
currency: input.expectedCurrency,
scope: input.expectedScope,
});
return result.status === 'success';
}
MPP’s server APIs compare the Credential against expected values from the original Challenge, including request parameters, metadata, and resource scope. ([MPP — Machine Payments Protocol][4])
A server may verify that:
- The Credential is correctly formatted
- It was created for the expected Challenge
- The payment amount is correct
- The currency matches
- The Credential applies to the requested resource
- The payment has succeeded
- The Credential is still valid
- It has not been improperly reused
The MPP specification describes Credentials as being valid for a specific request, helping keep payment authorization narrowly scoped. ([MPP — Machine Payments Protocol][3])
Step 6: Payment Verification Authorizes Resource Access
Once the server verifies the Credential, it can authorize access to the paid resource:
Valid payment Credential
↓
Payment condition satisfied
↓
Return protected resource
When the Credential is missing or invalid:
Missing or invalid Credential
↓
Payment condition not satisfied
↓
Return 402 Challenge
Stripe’s quickstart follows this pattern: the endpoint returns a 402 response when no valid Credential is present and grants access only after the incoming payment information has been successfully verified.
A simplified endpoint might look like this:
export async function getPremiumReport(
request: Request
): Promise<Response> {
const authorization =
request.headers.get('authorization');
if (!authorization) {
return createPaymentChallenge({
amount: '0.50',
currency: 'usd',
scope: 'GET /api/reports/market-analysis',
});
}
const receipt = await verifyCredential({
credential: authorization,
amount: '0.50',
currency: 'usd',
scope: 'GET /api/reports/market-analysis',
});
if (receipt.status !== 'success') {
return createPaymentChallenge({
amount: '0.50',
currency: 'usd',
scope: 'GET /api/reports/market-analysis',
});
}
const report = await generateMarketReport();
return Response.json(report, {
headers: {
'Payment-Receipt': receipt.serialized,
},
});
}
This is illustrative pseudocode, but it represents the main server responsibility:
- Issue a Challenge
- Receive a Credential
- Verify the payment
- Grant access
- Return a Receipt
Step 7: The Server Returns a Payment Receipt
After successful verification, the server returns the resource and an MPP Receipt:
HTTP/1.1 200 OK
Content-Type: application/json
Payment-Receipt: ...
{
"report": {
"industry": "AI infrastructure",
"summary": "Premium market analysis..."
}
}
The Receipt records the outcome of the payment and completes the Challenge–Credential–Receipt flow. ([MPP — Machine Payments Protocol][2])
It can help the client:
- Record the purchase
- Associate spending with an agent task
- Reconcile transactions
- Audit agent activity
- Troubleshoot payment failures
- Avoid accidental duplicate purchases
The final exchange becomes:
GET protected resource
↓
402 + Challenge
↓
Authorize payment
↓
Retry with Credential
↓
Verify Credential
↓
200 + resource + Receipt
What “Authentication” Means in MPP
In traditional application security, authentication usually answers:
Who is making this request?
Examples include:
- Passwords and passkeys
- API keys
- OAuth access tokens
- Signed identity tokens
- Enterprise single sign-on
MPP authentication answers a narrower question:
Is the payment Credential valid for this payment Challenge?
A valid MPP Credential does not necessarily prove:
- The legal identity of the agent operator
- Which employee initiated the request
- Which organization owns the agent
- Whether the agent may access a customer account
- Whether a human approved the transaction
MPP authenticates the payment proof, not the complete real-world identity behind the agent.
What “Authorization” Means in MPP
MPP uses verified payment as an authorization condition.
The service is saying:
Access to this resource is authorized when the required payment has been verified.
However, payment should rarely be the only authorization requirement.
A production service may need to evaluate:
const canAccessResource =
identityIsValid &&
tenantMatches &&
userHasPermission &&
paymentIsVerified &&
requestPassesBusinessRules;
For example, paying for a financial report should not automatically allow an agent to view another company’s private financial data.
A service may still need:
- Authentication
- Tenant isolation
- Role-based access control
- Data permissions
- Regional restrictions
- Usage limits
- Compliance checks
MPP supplies payment-based authorization. It does not replace the application’s broader security model.
MPP vs OAuth, API Keys, and RBAC
These mechanisms answer different questions:
| Mechanism | Main question |
|---|---|
| Password or passkey | Who is the user? |
| API key | Which client is calling the service? |
| OAuth token | What access was granted to this application? |
| Role-based access control | Which actions may this identity perform? |
| MPP Credential | Was the required payment authorized or completed? |
A paid API could use several layers together:
OAuth
→ identifies the agent and its permissions
Application authorization
→ validates role, tenant, and resource access
MPP
→ proves that the required payment condition was satisfied
A successful machine payment should not bypass identity or permission checks.
What Stripe MPP Solves
MPP is particularly useful for services that want to charge machines directly for:
- API calls
- MCP tool calls
- Premium content
- Data retrieval
- Document generation
- AI inference
- Browser automation
- Compute resources
- Usage-based services
Stripe’s launch examples included agents paying for browser sessions, API-based web access, physical mail, and other services through programmatic payment flows. ([Stripe][1])
MPP can make payment part of the API interaction instead of requiring every machine customer to establish a billing relationship in advance.
What MPP Does Not Solve
MPP should not be treated as a complete agent-security framework.
It does not automatically provide:
Agent identity
A valid payment Credential does not necessarily identify who controls the agent.
Application permissions
Payment does not prove that the agent has permission to access a particular account, user, organization, or record.
Spending governance
The agent operator must still enforce transaction limits, approved merchants, budget rules, and human-approval thresholds.
Business-rule validation
A payment should not bypass product availability, contractual restrictions, compliance rules, or account status.
Fraud and abuse controls
Services still need monitoring, rate limits, anomaly detection, and appropriate fraud protections.
A safer architecture is:
Identity verification
+
Application permissions
+
Agent spending policy
+
MPP Credential verification
+
Business rules
=
Authorized operation
Security Practices for MPP Endpoints
Validate server-defined payment terms
Never trust an amount supplied by the client.
// Unsafe
await verifyCredential({
amount: request.body.amount,
});
Use the price defined by your own product or pricing system:
// Better
await verifyCredential({
amount: priceCatalog.marketReport,
});
Bind Credentials to a scope
A Credential for one endpoint should not authorize every paid endpoint in the application.
GET /reports/market-analysis
should have a different scope from:
POST /reports/generate-custom
Protect against replay
Use unique Challenge identifiers, expiration rules, request scoping, and server-side tracking where required.
Make paid operations idempotent
Network retries must not accidentally create duplicate orders, reports, or charges.
Do not log raw credentials
Log identifiers, outcomes, and receipt references without storing payment secrets in plain text.
Enforce agent-side budgets
The client should reject or escalate payments that exceed its configured limits.
if (challenge.amount > policy.maxAutomaticSpend) {
return requestHumanApproval(challenge);
}
Final Thoughts
Stripe MPP turns HTTP 402 Payment Required into a practical machine-payment flow.
The server sends a payment Challenge. The client authorizes payment and responds with a Credential. The server authenticates that Credential against the original terms, authorizes access to the paid resource, and returns a Receipt.
The key distinction is:
Payment authentication:
Is this Credential valid?
Payment authorization:
Has the payment condition been satisfied?
Application authorization:
Is this agent permitted to perform the action?
MPP handles the first two questions.
OAuth, API keys, identity systems, role-based permissions, business rules, spending policies, and human approvals must still handle the broader security requirements.
MPP does not replace application authentication and authorization. It adds a standardized payment layer that allows agents and services to negotiate, verify, and complete payments through ordinary HTTP requests.
That separation makes it useful.
Developers can monetize APIs and machine-accessible services without forcing every agent through a human checkout flow, while still keeping identity, permissions, and governance under application control.
Which service would you monetize first with MPP: an API, MCP tool, premium dataset, or AI inference endpoint?
Top comments (0)