Stripe and Tempo have launched the Machine Payments Protocol (MPP), an open standard for machine-to-machine payments aimed at the next layer of agentic commerce: software that can discover, decide, and pay without waiting for a human to click through checkout. Tempo says Mainnet is live today, and Stripe has already wired MPP into its own stack.
That last part is why this launch matters. New payment protocols show up all the time. Most die in the gap between a clever demo and actual merchant operations. Stripe is framing MPP differently: businesses can keep one payments stack for both human buyers and agents, instead of bolting a separate crypto flow onto the side and hoping finance, tax, fraud, and refunds catch up later.
Stripe is trying to make agent payments look operationally boring
The strongest claim in Stripe's launch messaging is not that agent commerce is coming. Everyone already knows that story. The stronger claim is that Radar rules, refunds, sales tax, analytics, and accounting work out of the box for agent transactions.
That changes the shape of the decision for any company already on Stripe.
If a business wants to let agents buy API calls, data access, digital services, or usage-based resources, the usual obstacle is not payment authorization. It is everything around payment authorization:
- how the transaction lands in reporting
- how finance reconciles it
- how tax gets applied
- how disputes or refunds are handled
- how fraud controls behave when the buyer is software, not a person
Stripe's pitch is that MPP does not require a parallel back office. The payment can be initiated by an agent, while the merchant still receives it through the same system they already use for cards, checkout, and operational reporting.
That is a much bigger deal than "agents can pay now." Agents paying is easy to imagine. Agents paying into infrastructure that an actual business can trust is the harder step.
What MPP enables right now
Stripe's machine payments docs already show where MPP fits. Stripe supports machine payments across Tempo using MPP, and also across Stripe card networks using MPP, alongside x402 support on Base and Solana. The docs describe machine payments as a way to let agents pay programmatically for resources like API calls, data, or services.
The implementation details are concrete enough to matter:
- payments can be as low as 0.01 USDC
- merchants can accept machine payments into their Stripe balance
- Stripe says those payments can settle in fiat
- refunds are available in the API and Stripe Dashboard
That stack opens up business models that are awkward with conventional checkout. An API provider can charge per request. A data vendor can meter access at the endpoint level. A service can gate premium outputs behind payment instead of forcing every agent through account creation and API key provisioning first.
From the buyer side, Stripe's docs describe a simpler path too: an agent can transact on demand with access to a crypto wallet, rather than needing a user account and pre-issued API credentials for every service it may want to call.
Tempo gives MPP a payment rail built for this pattern
Tempo's role here is not just branding. The network was built around stablecoin payments and the machine-speed constraints that come with them: low-value transactions, instant settlement expectations, always-on availability, and software-controlled credentials.
Tempo's own docs position this as programmable money for AI agents, with agents purchasing digital resources, subscriptions, services, or goods autonomously. The argument is straightforward: card rails were designed around human cardholders and fraud systems meant to stop bots, while agent commerce needs a rail that expects software on both sides.
That is also why the Mainnet launch matters. This is no longer a conceptual partnership slide. Tempo says the network is now publicly available, and the documentation already includes Mainnet installation guidance for validator and RPC node operators. In practice, that means MPP now has a live chain behind it instead of just a roadmap.
The single-stack angle is the part businesses should pay attention to
Stripe's description of MPP as "Level 4 agentic commerce" is marketing language, but the operational point underneath it is solid.
Most businesses are not looking for a second checkout stack. They are looking for a way to accept a new type of buyer without rebuilding finance and ops around it. MPP gives them a path where they can still present a visual checkout to a human, but also accept a programmatic payment from an agent using the same underlying platform.
That is the practical unlock.
If this works as advertised, an existing Stripe business does not need to stand up a separate merchant-of-record flow, separate reporting environment, or separate refund logic just to experiment with agent traffic. It can add machine-payable endpoints or services while keeping the surrounding controls familiar.
That does not mean every business should rush to expose every product to agents. Early access is still gated through Stripe, and machine-payable flows will make more sense for some products than others. Usage-metered APIs, data products, and digital service endpoints are the obvious first fits. Physical goods and more complex fulfillment workflows will take more operational design.
One payment stack, two classes of buyer
MPP is interesting because it solves a very unglamorous problem: how to let software spend money without forcing the seller to invent a second commerce system. Stripe and Tempo are effectively saying agent payments should look like a new input into an existing business stack, not a separate experiment living off to the side. With Tempo Mainnet live and Stripe already exposing machine payments in docs, the launch clears the "real enough to evaluate" bar. The verdict is that MPP does not prove agentic commerce is mainstream yet, but it does make machine-initiated purchases feel much closer to normal operations than most agent payment announcements do.