Agentic commerce is having a moment. Read the announcements from companies like Stripe, Salesforce, and Shopify, and it's hard not to get excited. But as with all highly hyped technologies, it can also be challenging to define exactly what it is - currently it's used as a term to cover a wide variety of different implementations.

Broadly speaking, agentic commerce is commerce where an agent can discover a price, decide it wants the thing, and carry the transaction forward under some kind of authority: a wallet, a mandate, a token, or a human approval flow.

That is a massive category. A shopping assistant buying a shirt is agentic commerce. So is a research agent paying for one dataset, or a coding agent buying a single API call.

This is the first post in a series on the agentic commerce stack. We are starting at the bottom, with machine payments, because it is the part implementors can build against today.

The agentic commerce stack

At the top are commerce protocols and platforms: standards like OpenAI and Stripe's Agentic Commerce Protocol (ACP) and Google's Universal Commerce Protocol (UCP). You publish a catalogue, the assistant becomes the shopfront, and the platform helps with discovery, carting, and checkout.

This is the layer to care about if your goal is to be surfaced and bought from natively inside major assistant ecosystems (like ChatGPT, Gemini, or Copilot). It’s an exciting layer focused heavily on aggregation and discovery. Just like the early days of mobile app stores or web search, these ecosystems help users navigate an infinite web of choices. Naturally, there will be a learning curve around optimisation - understanding how these models filter user intent and rank merchants is going to be a core discipline, much like SEO or Amazon marketplace optimization. We'll be diving deep into how to optimize for this layer later in this series.

At the bottom are payment primitives: small, composable mechanisms that let software pay for a request. Here we have no catalogue, no shopfront and no product page. Just a definition of a resource, the price to pay, and how we'll allow a machine to pay for it.

The Direct-Channel Alternative

These layers aren’t competitors; they simply answer different questions. High-level protocols ask, "How does an agent shop across ecosystems?", while lower-level primitives ask, "How do we pay for access to this specific HTTP resource?"

Think of it as the difference between listing your inventory on a major global marketplace versus running your own direct-to-consumer website. While ACP and UCP excel at driving discovery and routing new users to your brand, MPP provides a decentralised alternative for direct, established interactions. If an agent already knows your API or resource exists, MPP allows it to transact with you directly over standard web architecture, removing any unnecessary friction or dependency on an external marketplace broker.

In this post, we’re going to focus on this lower-level primitive, and show how we can start building implementations today.

What is the Machine Payments Protocol (MPP)?

The Machine Payments Protocol (MPP) is a way for a server to ask for payment through ordinary HTTP request and response mechanics. The mechanism is a status code most of us have never returned on purpose: 402 Payment Required.

An unpaid request comes back with a signed 402 challenge. That challenge says what the resource costs, which payment methods the server accepts, and what the client must present on retry. The client, usually an agent or wallet acting for the buyer, obtains the right payment credential or signed payment artifact. It then retries the same request with an Authorization: header using the payment scheme.

The important architectural detail is that "the client pays" does not mean exactly the same thing on every rail. MPP defines the negotiation, but the settlement rail defines who actually moves the money.

How machine payments work

• The Stripe Rail: The buyer-side agent presents a Shared Payment Token (SPT). The token is not the completed charge. It is a scoped credential that lets the seller create and confirm a PaymentIntent for that request. In other words, the agent brings the permission to charge, but the server initiates and verifies the actual Stripe settlement inline.

• The Tempo Rail: For Tempo, the shape is closer to a direct wallet payment. The client signs a pathUSD transfer specifically for the 402 challenge. In our implementation, the signed payment is sent back to the server, which broadcasts it to the network and confirms it before returning the resource.

In this flow, there is no checkout page, and the merchant doesn't need a saved card on file to charge. The buyer may still have a wallet, a Link account, or some other underlying authority to spend, but as the merchant, your endpoint simply sees a valid, paid HTTP request rather than a traditional checkout session.

Idempotency by Design

In human e-commerce, preventing a user from being charged twice during a network glitch requires a complex web of database locks, session states, and unique idempotency keys. If a request drops mid-flight after a credit card is charged, the system has to figure out if the money actually moved.

In the agentic world, things get more complicated. An SPT is a programmable mandate. It can be single-use for an exact checkout basket, or it can be multi-use to support usage-based API billing up to a specific spending ceiling. If a network blip occurs after your server clears the payment but before you can return the data, a naive retry loop will either result in an accidental double charge (on a multi-use token) or a "token already consumed" crash from Stripe, leaving the agent empty-handed for a resource they’ve already paid for.

MPP allows us to handle this elegantly by combining cryptographic payment artifacts with application-level session state tracking.

When a payment rail successfully clears a challenge, your application can write a secure "grant" to storage using the challenge id, right before passing the request to your customer. If the network drops and the agent retries the exact same request, the storage can be checked for this challenge, and if a successful grant already exists for that challenge context, the application safely fulfills the request directly from the application storage. This ensures the client gets their asset without ever triggering a duplicate charge or hitting the payment gateway a second time. This idempotency protection is a key part of the protections we have added in our Laravel MPP package.

A working example: PayForGoals

Given that it's World Cup season, and that the best way to understand new things is often to build them yourself, we built PayForGoals. This is an API that sells one historic football scoreline per request. In this first release, it returns the final scoreline, but you'll have to wait for v2 to find out which teams actually played - a true MVP, but perfect for testing the underlying plumbing!

PayForGoals runs on an open-source Laravel package we maintain, square1/laravel-mpp. Putting a price on a route is a single line of middleware:

Route::get('/scores/match/{id}', ScoreController::class)

    ->middleware('mpp:1.00,USD,method=stripe');

That route now automatically answers an unpaid request with a 402 challenge and serves the scoreline data as soon as the payment clears and the package logs the grant. We can charge once per request, or we can “bundle” payments. We can charge a user once, then allow 3 subsequent accesses via session-based metering without requiring fresh payment each time.

The same scoreline is sold over two rails:

• Stripe, using Shared Payment Tokens presented by the buyer and settled by the server as a PaymentIntent.

• Tempo, using a signed on-chain pathUSD transfer on testnet.

Here we're selling effectively the same resource, but with different settlement mechanics available. MPP gives you a unified way to expose paid resources, while still letting different payment rails kick in depending on what your user (or their agent) has available in their wallet.

Why start with MPP?

We started with MPP because it is small enough to reason about.

A lot of agentic commerce discussions dive straight into the macro journey: discovery architectures, complex identities, long-term LLM mandates, carts, product substitutions, refunds, dispute handling, and all the fragile edges where a human used to intervene. Those problems matter, but they are not where most development teams should start if they want to understand the technical shape of this new world.

A paid request is a better first unit of work. It forces us to answer the right questions quickly:

• What exactly is being bought?

• What does the agent know before paying?

• What proof or authority does the buyer present?

• Who settles the payment?

• What does the server return as a receipt?

• What happens when the resource cannot be served?

Answer those well for one endpoint, and bit by bit, the larger infrastructure around it becomes more concrete.

The Current State of Play

Agentic commerce is real, but uneven. The high-level protocols are still settling into their roles. Payment rails are arriving at different speeds, in different markets, with different constraints. Stripe Shared Payment Tokens are promising, but live acceptance and usage through wallets like Link remains gated to US businesses at the time of writing (June 2026).

However, that is not a reason to wait. The implementable work today is to understand the primitives: how a machine sees a price, how it gets authority to spend, how the seller verifies settlement, and how the resource is delivered with a receipt. That knowledge will carry upward into ACP, UCP, and whatever marketplace protocols follow.

Where this series goes next
This was the ground floor: a single payment primitive, made concrete with a small football API. In our next posts, we will move up the stack to the high-level marketplace protocols, including ACP and UCP. We will map where each one fits: when you want your products optimised to be discovered inside major assistant storefronts, when you need a direct-to-agent paid API, and how to position your business to leverage both.

The package and the demo are how we are working through agentic commerce in the open rather than in the abstract. The code is on GitHub, and PayForGoals is live if you want to try it out for yourself.

Want to know more about getting ready for agentic commerce?
We are Square1, and we build payment and AI systems for a living. If agentic commerce is on your roadmap, we can help you work out which layer matters first, which protocols are relevant, and how to prototype the first paid request without turning it into a six-month platform bet.

Get in touch and we will help make the next step concrete.