{"slug": "how-stripe-mpp-uses-http-402-to-authenticate-and-authorize-machine-payments", "title": "How Stripe MPP Uses HTTP 402 to Authenticate and Authorize Machine Payments", "summary": "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.", "body_md": "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.\n\nTraditional 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.\n\nAn autonomous agent needs a machine-readable alternative.\n\nIt must be able to:\n\nThe **Machine Payments Protocol**, or MPP, introduces a standardized way to handle this process through ordinary HTTP requests.\n\nMPP 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])\n\nIts core flow is built around three objects:\n\n```\nChallenge → Credential → Receipt\n```\n\nLet’s examine how that flow uses HTTP `402 Payment Required`\n\nto authenticate payment credentials and authorize access to paid resources.\n\nMost paid APIs use one of these models:\n\nThese 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.\n\nConsider an AI research agent that needs a single premium market report.\n\nThe agent may not need:\n\nIt only needs to discover the report’s price, pay for it, and receive the result.\n\nStripe 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])\n\nMPP is a protocol for machine-to-machine internet payments.\n\nWhen a client requests a paid resource, the server returns an HTTP `402`\n\nresponse 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.\n\nThe complete flow looks like this:\n\n```\nAgent requests a protected resource\n             ↓\nServer returns 402 Payment Required\n             ↓\nResponse contains a payment Challenge\n             ↓\nAgent evaluates and authorizes payment\n             ↓\nAgent retries with a Credential\n             ↓\nServer verifies the Credential\n             ↓\nServer returns the resource and Receipt\n```\n\nMPP 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.\n\nStripe’s current MPP integration supports crypto payments through on-chain deposit addresses and fiat payment methods through Shared Payment Tokens.\n\nSuppose a provider exposes this endpoint:\n\n```\nGET /api/reports/market-analysis\n```\n\nThe agent sends a normal request:\n\n```\nGET /api/reports/market-analysis HTTP/1.1\nHost: reports.example.com\nAccept: application/json\n```\n\nThe server checks whether the request contains a valid payment credential.\n\nBecause this is the first request, no credential is available. Instead of returning the report, the server responds with `402 Payment Required`\n\n.\n\nThe response may conceptually look like this:\n\n```\nHTTP/1.1 402 Payment Required\nWWW-Authenticate: Payment challenge=\"...\"\nCache-Control: no-store\nContent-Type: application/problem+json\n{\n  \"status\": 402,\n  \"title\": \"Payment Required\",\n  \"detail\": \"Payment is required to access this market report.\"\n}\n```\n\nThe `WWW-Authenticate`\n\nheader carries the MPP **Challenge**.\n\nA Challenge tells the client what must be done to obtain the protected resource. It can include information such as:\n\nMPP standardizes HTTP `402`\n\nthrough this Challenge–Credential–Receipt model. ([MPP — Machine Payments Protocol][2])\n\nA 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.\n\nThe 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.\n\nReceiving a `402`\n\nresponse should not mean that the agent pays automatically.\n\nBefore authorizing payment, the agent should evaluate its spending policy:\n\n```\nIs this provider trusted?\nIs the requested amount within budget?\nDoes this purchase support the current task?\nIs this payment method allowed?\nDoes the transaction require human approval?\n```\n\nA basic policy could look like this:\n\n```\ntype PaymentChallenge = {\n  amount: number;\n  currency: string;\n  merchant: string;\n  resource: string;\n};\n\nfunction canAuthorizePayment(\n  challenge: PaymentChallenge\n): boolean {\n  const approvedMerchants = new Set([\n    'reports.example.com',\n    'search.example.com',\n  ]);\n\n  return (\n    approvedMerchants.has(challenge.merchant) &&\n    challenge.currency === 'USD' &&\n    challenge.amount <= 1\n  );\n}\n```\n\nFor higher-value or sensitive transactions, the agent could request approval from a human before proceeding.\n\nMPP coordinates payment communication. The application controlling the agent remains responsible for spending limits, merchant restrictions, and approval policies.\n\nAfter approving the payment, the client satisfies the Challenge using one of the available payment methods.\n\nIt then creates an MPP **Credential** and retries the original request:\n\n```\nGET /api/reports/market-analysis HTTP/1.1\nHost: reports.example.com\nAccept: application/json\nAuthorization: Payment credential=\"...\"\n```\n\nA 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`\n\nheader. ([MPP — Machine Payments Protocol][3])\n\nThe Credential should correspond to the original payment terms, including details such as:\n\nBinding the Credential to the Challenge prevents a payment intended for one resource from being treated as authorization for an unrelated resource.\n\nWhen the server receives the second request, it verifies the payment Credential.\n\nThis is the authentication part of the MPP flow.\n\nThe server is effectively asking:\n\nIs this a valid payment Credential that satisfies the Challenge issued for this request?\n\nConceptually, the verification may look like this:\n\n```\ntype VerificationInput = {\n  credential: string;\n  expectedAmount: string;\n  expectedCurrency: string;\n  expectedScope: string;\n};\n\nasync function verifyPayment(\n  input: VerificationInput\n): Promise<boolean> {\n  // Illustrative pseudocode.\n  const result = await paymentProvider.verify({\n    credential: input.credential,\n    amount: input.expectedAmount,\n    currency: input.expectedCurrency,\n    scope: input.expectedScope,\n  });\n\n  return result.status === 'success';\n}\n```\n\nMPP’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])\n\nA server may verify that:\n\nThe MPP specification describes Credentials as being valid for a specific request, helping keep payment authorization narrowly scoped. ([MPP — Machine Payments Protocol][3])\n\nOnce the server verifies the Credential, it can authorize access to the paid resource:\n\n```\nValid payment Credential\n          ↓\nPayment condition satisfied\n          ↓\nReturn protected resource\n```\n\nWhen the Credential is missing or invalid:\n\n```\nMissing or invalid Credential\n          ↓\nPayment condition not satisfied\n          ↓\nReturn 402 Challenge\n```\n\nStripe’s quickstart follows this pattern: the endpoint returns a `402`\n\nresponse when no valid Credential is present and grants access only after the incoming payment information has been successfully verified.\n\nA simplified endpoint might look like this:\n\n```\nexport async function getPremiumReport(\n  request: Request\n): Promise<Response> {\n  const authorization =\n    request.headers.get('authorization');\n\n  if (!authorization) {\n    return createPaymentChallenge({\n      amount: '0.50',\n      currency: 'usd',\n      scope: 'GET /api/reports/market-analysis',\n    });\n  }\n\n  const receipt = await verifyCredential({\n    credential: authorization,\n    amount: '0.50',\n    currency: 'usd',\n    scope: 'GET /api/reports/market-analysis',\n  });\n\n  if (receipt.status !== 'success') {\n    return createPaymentChallenge({\n      amount: '0.50',\n      currency: 'usd',\n      scope: 'GET /api/reports/market-analysis',\n    });\n  }\n\n  const report = await generateMarketReport();\n\n  return Response.json(report, {\n    headers: {\n      'Payment-Receipt': receipt.serialized,\n    },\n  });\n}\n```\n\nThis is illustrative pseudocode, but it represents the main server responsibility:\n\nAfter successful verification, the server returns the resource and an MPP **Receipt**:\n\n```\nHTTP/1.1 200 OK\nContent-Type: application/json\nPayment-Receipt: ...\n{\n  \"report\": {\n    \"industry\": \"AI infrastructure\",\n    \"summary\": \"Premium market analysis...\"\n  }\n}\n```\n\nThe Receipt records the outcome of the payment and completes the Challenge–Credential–Receipt flow. ([MPP — Machine Payments Protocol][2])\n\nIt can help the client:\n\nThe final exchange becomes:\n\n```\nGET protected resource\n        ↓\n402 + Challenge\n        ↓\nAuthorize payment\n        ↓\nRetry with Credential\n        ↓\nVerify Credential\n        ↓\n200 + resource + Receipt\n```\n\nIn traditional application security, authentication usually answers:\n\nWho is making this request?\n\nExamples include:\n\nMPP authentication answers a narrower question:\n\nIs the payment Credential valid for this payment Challenge?\n\nA valid MPP Credential does not necessarily prove:\n\nMPP authenticates the payment proof, not the complete real-world identity behind the agent.\n\nMPP uses verified payment as an authorization condition.\n\nThe service is saying:\n\nAccess to this resource is authorized when the required payment has been verified.\n\nHowever, payment should rarely be the only authorization requirement.\n\nA production service may need to evaluate:\n\n``` js\nconst canAccessResource =\n  identityIsValid &&\n  tenantMatches &&\n  userHasPermission &&\n  paymentIsVerified &&\n  requestPassesBusinessRules;\n```\n\nFor example, paying for a financial report should not automatically allow an agent to view another company’s private financial data.\n\nA service may still need:\n\nMPP supplies payment-based authorization. It does not replace the application’s broader security model.\n\nThese mechanisms answer different questions:\n\n| Mechanism | Main question |\n|---|---|\n| Password or passkey | Who is the user? |\n| API key | Which client is calling the service? |\n| OAuth token | What access was granted to this application? |\n| Role-based access control | Which actions may this identity perform? |\n| MPP Credential | Was the required payment authorized or completed? |\n\nA paid API could use several layers together:\n\n```\nOAuth\n  → identifies the agent and its permissions\n\nApplication authorization\n  → validates role, tenant, and resource access\n\nMPP\n  → proves that the required payment condition was satisfied\n```\n\nA successful machine payment should not bypass identity or permission checks.\n\nMPP is particularly useful for services that want to charge machines directly for:\n\nStripe’s launch examples included agents paying for browser sessions, API-based web access, physical mail, and other services through programmatic payment flows. ([Stripe][1])\n\nMPP can make payment part of the API interaction instead of requiring every machine customer to establish a billing relationship in advance.\n\nMPP should not be treated as a complete agent-security framework.\n\nIt does not automatically provide:\n\nA valid payment Credential does not necessarily identify who controls the agent.\n\nPayment does not prove that the agent has permission to access a particular account, user, organization, or record.\n\nThe agent operator must still enforce transaction limits, approved merchants, budget rules, and human-approval thresholds.\n\nA payment should not bypass product availability, contractual restrictions, compliance rules, or account status.\n\nServices still need monitoring, rate limits, anomaly detection, and appropriate fraud protections.\n\nA safer architecture is:\n\n```\nIdentity verification\n        +\nApplication permissions\n        +\nAgent spending policy\n        +\nMPP Credential verification\n        +\nBusiness rules\n        =\nAuthorized operation\n```\n\nNever trust an amount supplied by the client.\n\n```\n// Unsafe\nawait verifyCredential({\n  amount: request.body.amount,\n});\n```\n\nUse the price defined by your own product or pricing system:\n\n```\n// Better\nawait verifyCredential({\n  amount: priceCatalog.marketReport,\n});\n```\n\nA Credential for one endpoint should not authorize every paid endpoint in the application.\n\n```\nGET /reports/market-analysis\n```\n\nshould have a different scope from:\n\n```\nPOST /reports/generate-custom\n```\n\nUse unique Challenge identifiers, expiration rules, request scoping, and server-side tracking where required.\n\nNetwork retries must not accidentally create duplicate orders, reports, or charges.\n\nLog identifiers, outcomes, and receipt references without storing payment secrets in plain text.\n\nThe client should reject or escalate payments that exceed its configured limits.\n\n```\nif (challenge.amount > policy.maxAutomaticSpend) {\n  return requestHumanApproval(challenge);\n}\n```\n\nStripe MPP turns HTTP `402 Payment Required`\n\ninto a practical machine-payment flow.\n\nThe 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**.\n\nThe key distinction is:\n\n```\nPayment authentication:\nIs this Credential valid?\n\nPayment authorization:\nHas the payment condition been satisfied?\n\nApplication authorization:\nIs this agent permitted to perform the action?\n```\n\nMPP handles the first two questions.\n\nOAuth, API keys, identity systems, role-based permissions, business rules, spending policies, and human approvals must still handle the broader security requirements.\n\nMPP 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.\n\nThat separation makes it useful.\n\nDevelopers 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.\n\nWhich service would you monetize first with MPP: an API, MCP tool, premium dataset, or AI inference endpoint?", "url": "https://wpnews.pro/news/how-stripe-mpp-uses-http-402-to-authenticate-and-authorize-machine-payments", "canonical_source": "https://dev.to/synfinity-dynamics-pvt-ltd/how-stripe-mpp-uses-http-402-to-authenticate-and-authorize-machine-payments-1kpo", "published_at": "2026-08-05 10:30:34+00:00", "updated_at": "2026-08-05 10:49:40.118302+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "developer-tools"], "entities": ["Stripe", "Tempo", "Machine Payments Protocol", "HTTP 402"], "alternates": {"html": "https://wpnews.pro/news/how-stripe-mpp-uses-http-402-to-authenticate-and-authorize-machine-payments", "markdown": "https://wpnews.pro/news/how-stripe-mpp-uses-http-402-to-authenticate-and-authorize-machine-payments.md", "text": "https://wpnews.pro/news/how-stripe-mpp-uses-http-402-to-authenticate-and-authorize-machine-payments.txt", "jsonld": "https://wpnews.pro/news/how-stripe-mpp-uses-http-402-to-authenticate-and-authorize-machine-payments.jsonld"}}