It's Lena. Machine Payments Protocol is not “a credit card for AI agents.” That was the first place I paused. A better way to read it is simpler: MPP gives an agent and a paid service a shared payment conversation. The service can say, “this action costs this much, under these terms,” and the agent can return proof that payment was authorized before the service delivers the resource.
That sounds small, but it matters. Agents are starting to call APIs, rent browsers, buy compute, use datasets, and trigger services without a human sitting there for every checkout screen. MPP tries to standardize the payment layer in that flow. It does not decide what the agent is allowed to do. It does not replace MCP. It does not make every agent trustworthy by default.
Machine Payments Protocol in One Minute
Machine Payments Protocol, or MPP protocol, is an open machine-to-machine payments standard co-authored by Stripe and Tempo. Stripe described MPP in Stripe’s MPP launch post as a way for agents and services to coordinate payments programmatically, including API calls, resources, and HTTP-addressable services.
The short version is this: an agent asks for something, the service replies with a payment request, the agent authorizes payment, and the service delivers after it can validate the payment evidence. I’m saying “can” on purpose here, because implementations may differ by payment method, provider, and service design.
MPP is also not a Stripe-only protocol. Stripe is one important implementation path, especially for businesses already using Stripe infrastructure, but the protocol’s design is payment-method agnostic. That distinction matters because developers evaluating AI agent payments should not treat MPP as a closed checkout product wearing a protocol hat.
Why Agent Services Need a Payment Layer
Human payments assume human friction. We create accounts, pick plans, enter cards, approve terms, and maybe upgrade later. Agents do not fit that pattern cleanly. If an agent only needs one dataset lookup, one browser session, or one model call, forcing it through account creation and subscription selection breaks the workflow.
This is where AI agent payments start to look less like ecommerce checkout and more like network access. The service needs a way to price a request. The agent needs a way to understand the price, decide whether it fits its budget and policy, and return payment evidence. The service then needs a record that explains why access was granted.
MCP helps agents discover and call tools. If this part feels fuzzy, EvoMap’s What Is MCP? is a useful grounding piece. But MCP is not a payment rail. It can expose a tool, while MPP can handle the paid access conversation around that tool. Different layer. Different job.
How an MPP Transaction Moves from Request to Settlement
MPP is easiest to understand as a lifecycle, not a product button. I’m holding the order loosely because services can wrap this flow differently, but the core pattern is stable enough to evaluate.
Service discovery and the payment request
Before payment, the agent needs to find a service or hit an endpoint. Discovery may happen through a directory, documentation, an MCP server, an API marketplace, or a direct HTTP request. The MPP service directory is one place where MPP-enabled services can be browsed—verify against the current directory before publishing, but the directory itself should not be confused with the protocol.
Once the agent requests a protected resource, the service can respond with a payment request. In HTTP terms, this often maps to a 402 Payment Required challenge. That challenge tells the client what payment is needed, which method or methods are accepted, and what the agent needs to return.
The key word is “request.” A payment request is not the same as permission. It is an offer or challenge from the service side. The agent still needs its own authorization rules: budget limits, allowed service categories, retry policy, user approval requirements, and maybe risk scoring.
Agent authorization and payment evidence
The agent authorization step is where builders should slow down. This is not just “the model says yes.” A production agent should have a payment policy outside the model’s improvisation. That policy might say the agent can approve up to a small amount automatically, ask the user above a threshold, reject unknown providers, or avoid recurring commitments unless explicitly approved.
After authorization, the agent returns payment evidence. Depending on the payment method, the agent returns a Payment credential containing a method-specific proof such as a signature, token, or other artifact. The service should not rely on the agent’s promise. It should validate the evidence before delivering the paid resource.
Something shifted slightly for me here. The interesting part of MPP is not that agents can “spend money.” The interesting part is that payment becomes part of the request-response loop, instead of an out-of-band signup process that breaks autonomy.
Service delivery and settlement records
Once the service validates the payment evidence, it can deliver the resource: an API result, a browser session, a generated file, a compute job, a dataset slice, or another paid output. Settlement then depends on the payment method and provider.
For Stripe-based implementations, the Stripe machine payments docs currently describe support for cards through Shared Payment Tokens and stablecoin payments on specified networks, with refunds handled through Stripe’s Refunds API or Dashboard. That does not mean every MPP implementation has the same refund path. It means Stripe’s implementation can fit MPP into Stripe’s existing reporting, reconciliation, settlement, and refund machinery.
That is the practical evaluation point. Do not only ask whether a demo can complete a payment. Ask what record exists afterward.
Where MPP Stops
MPP stops at the payment layer. I want to be careful here, because it is easy to over-read a protocol when the category is new.
MPP does not solve identity by itself. Extensions and provider-specific identity work may exist, but a payment request does not automatically prove that an agent is safe, authorized by the right human, or acting inside the right workspace.
MPP also does not decide tool access. If an agent can call a database, upload a file, or operate a browser, that belongs closer to the tool, permission, and execution layer.
And MPP does not define the service’s business logic. The service still decides what it sells, how it prices usage, when access expires, how retries work, what counts as successful delivery, and how disputes are handled.
For a different layer entirely, EvoMap’s capability stack is about agent infrastructure, reusable experience, and self-evolution patterns. That is not payment settlement. Keeping these layers separate makes the whole system easier to reason about.
Questions Builders Should Resolve Before Adoption
A builder evaluating Machine Payments Protocol should start with boring questions. Boring is good here. Payments are one of those places where clever abstractions become expensive very quickly.
First, which rails are actually supported in your target market? MPP is payment-method agnostic as a protocol, but your implementation is not abstract. It will support specific rails, currencies, wallets, regions, and compliance paths.
Second, where does authorization live? If the model can independently approve every MPP payment request, I would be nervous. A safer design keeps budgets, merchant allowlists, approval thresholds, and recurring-payment rules in deterministic policy.
Third, what happens when something fails? Agents will retry. Services will time out. A payment request may expire. A credential may be rejected. A service may deliver partial output. Builders need clear retry and idempotency behavior, or the first “small” autonomous service payment can become a messy support case.
Fourth, what audit evidence survives? A useful record should show the original payment request, the authorization decision, the payment evidence or receipt reference, the delivered service, and any refund or adjustment afterward. Without that, MPP may make payment faster while making accounting harder.
FAQ
Does MPP require every agent to use a Stripe account?
No. MPP should not be described as a Stripe-exclusive protocol. Stripe supports machine payments through its own infrastructure, and that matters for businesses already using Stripe. But MPP itself is designed as an open, payment-method-agnostic protocol. In practice, the required account, wallet, or credential depends on the payment method and service implementation.
Who can propose or approve changes to the Machine Payments Protocol standard?
The public MPP specification is currently maintained by Tempo Labs and Stripe, and public contribution is invited through the specification process. That does not mean any contributor can approve a change. Approval depends on the maintainers and the governance process around the spec. If you are building against MPP, track the specification repository rather than relying on an old blog post.
Can an MPP payment request expire before authorization?
Yes, a payment request can be designed with validity limits, and some related payment credentials include expiration or usage limits. If authorization happens after the request expires, the agent should request a fresh payment challenge rather than trying to force the old one through. I would treat expiration handling as a required implementation detail, not an edge case.
How does MPP handle refunds after service delivery?
MPP coordinates the paid request flow; refunds depend on the payment method, provider, and service policy. In Stripe-based machine payments, refunds can run through Stripe’s existing refund tools. In other MPP implementations, the refund path may be different. Builders should document this before launch, especially for autonomous service payments where no human clicked a checkout receipt.
Are recurring authorizations included in the current MPP standard?
MPP has support paths for recurring or subscription-style payment intents in the broader ecosystem, but support is not universal across every rail or service. I would not assume recurring authorization exists just because a service says it supports MPP. Check whether the specific payment method, wallet, and provider support it, and require explicit budget and cancellation rules before letting an agent approve recurring spend.
Closing Thought
The useful way to read Machine Payments Protocol is not “agents can buy things now.” That is too vague, and honestly a little too dramatic. The better read is: paid services can expose a machine-readable payment request, agents can authorize within policy, and services can validate payment evidence before delivery.
That is enough to make agent payments more real. It is not enough to make them automatically safe.
So if you are evaluating MPP, start with one small paid service, one clear authorization policy, one supported payment method, and one audit trail you can actually inspect later. I’m not ready to close this one yet, but that is the part I would not skip.
Previous Posts:
- For the tool-connection layer that MPP does not replace, MCP, CLI, and GEP stack layers explains how agent tool access, command execution, and reusable experience sit in different parts of the stack.
- If paid agent actions are becoming part of your budget planning, AI agent deployment cost breaks down implementation, usage, review, and operating costs around real agent workflows.
- To make autonomous payment decisions reviewable later, deterministic replay for LLM agents shows what records an agent run should keep around tool calls, approvals, state changes, and evidence.
- For the policy layer that should decide whether an agent can spend or act, AI agent behavior constraints explains why powerful agents need explicit limits instead of leaving action decisions to the model alone.
- To understand where paid service calls fit inside longer task execution, agentic workflows in 2026 maps how agents plan, call tools, handle steps, and complete multi-stage work.
