• The views and opinions expressed in this article or video are my own in an individual capacity and do not reflect views or opinions of my current or previous employers.

• This article is intended as a high level overview to help busy payments professionals gain an understanding of the protocol quickly. Check these resources for a deeper dive into the protocol: Coinbase, x402.org, Github.

HTTP Status Codes

You’ve probably seen “https://” in your internet browser at some point. The HTTP part is Hypertext Transfer Protocol, the core communication protocol of the web. It defines how a “client” i.e. such as a browser, mobile app, API client, or AI agent, requests information or actions from a server, and how that server responds. A server can also be a client.

A critical component of HTTP is its status codes, some of which you might have also seen if you’ve used the internet long enough. The infamous 500 (Internal Server Error); 404 (Not found), 200 (OK) and 400 (Bad request) are common examples of the 64 HTTP status codes that exist today. They are sent by the server in its response, and tell the client in a standardised way what happened to its request. In case it isn’t obvious, codes like this make it easy for machines/programming to react to specific scenarios. If the code is 200, then do this (show success banner), if the code is 500, then do that (show sad emoji).

A lesser-known HTTP status code, 402 (Payment Required) was defined and reserved for future use in HTTP’s first standardisation in 1997. It envisioned a scenario where a server would require payment in some form, before giving a client access to a resource. However, the web didn’t adopt this status code, leaving it largely dormant.

Coinbase appears to be the first major industry-backed attempt to turn HTTP 402 into a widely adopted, developer-facing payment protocol.

An x402 Payment, Step by Step

x402 is an open protocol by Coinbase that operationalises the 402 Payment Required HTTP Status Code, for internet-native, machine-readable payments. Let’s see how it works step by step with an example of an AI agent client trying to access a premium PDF report.

1. Initial Request

Client sends a standard HTTP request to a server requesting paid-for Premium PDF report via the report’s URL.

2. 402 Response

Server returns HTTP status 402 response with a Payment-Required header. In this header is an encoded payload with details of how to make payment to access the PDF. The structure of the payload and the payment details is defined by the x402 protocol. Here’s a snippet.

{
  "x402Version": 2,
  "resource": {
    "url": "https://api.example.com/premium-report"
 },
...
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "amount": "10000",
      "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", 
      "payTo": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
      "extra": {
        "name": "USDC", 
        "version": "2"
      }
    }
  ]
...
}

As of this writing, the most mature and common x402 implementations are crypto/stablecoin focused, especially around USDC-style flows. These details might not be familiar for those purely in traditional Fintech so I’ve included comparable equivalents. Think of the details like a machine-readable payment request or digital invoice. It specifies:

• Asset & Amount: What ‘currency’ is required (e.g., USD, USDC, USDT, BTC) and the exact micro-value expressed in lower minor units.

• payTo: The recipient’s (merchant) destination payment address (similar to a bank account number or IBAN).

• The Network: The rails being used (similar to SEPA, FedNow, or a card network).

3. Authorising Payment

Client chooses one of the available payment options specified in the “accepts” block in step 2. The Client then generates a payment authorisation payload for that specific payment option, based on the provided recipient payment details… and cryptographically signs it.

4. Re-requesting with Payment Proof

Client encodes the payment authorisation payload and makes a new HTTP request to the server requesting for the premium PDF. This request is identical to the one in step 1, but this time with the base64 encoded payment authorisation payload (from step 3) in the PAYMENT-SIGNATURE header.

5. Server Handles Request

The server (merchant) receives the new request and verifies the payment authorisation in the signature header. To reduce infrastructure overhead, the server can optionally pass this payload to a non-custodial third party called a Facilitator. However, the merchant itself is entirely capable of building out capability to verify and settle stablecoin payments directly.

6. Facilitator Verifies Payment

The Facilitator functions similarly to a PSP-like infrastructure layer, but it is narrower than a traditional card PSP/acquirer. It verifies the payment authorisation and can help settle, but it does not necessarily custody funds, underwrite merchants, manage chargebacks, or connect to card schemes.

7. Access Granted

Once the payment is validated, the server immediately returns an HTTP 200 OK status code and delivers the requested premium content back to the client. The value exchange is complete in seconds, entirely machine-to-machine.

Commerce in an AI Agent Economy

You can see how Coinbase with this Protocol is positioning itself for a world in which AI agents autonomously interact and transact with other AI agents.

By upgrading the web’s foundational communication layer rather than stacking more software on top of legacy banking networks, protocols like this show us what a friction-free, machine-executable economy may look like.

For example, an AI Agent trained and fine-tuned on translating and converting imagery of Egyptian hieroglyphs to their English text equivalent could offer its services on the web to other AI agents for $0.0001 per megabyte of imagery or API call. An educational AI agent used by a student doing a paper on African writing scripts could interact with the hieroglyph-expert agent and exchange value through a series of micropayments of under $0.10 upon every usage.

Let’s see how this exact scenario would play out on x402 versus typical e-commerce

x402 + Stablecoins vs Traditional eCommerce

In a traditional e-commerce or API monetisation setup, the hieroglyph-expert service would likely create a paywall, pricing page, account system, API key flow, and card or bank payment integration through a PSP. The student or their software would sign up, choose a plan, enter payment details, possibly complete a 3DS challenge, and receive API credentials. The merchant would rely on its PSP/acquirer stack for payment acceptance, authorization, settlement, reporting, and dispute handling. Settlement may take one or more business days, and card-style chargebacks remain part of the operating model.

In an x402 + stablecoin model, the student could give their AI agent software a wallet, USDC balance, and spending rules. When the agent needs the hieroglyph translation service, it requests the resource, receives a 402 Payment Required response, signs a payment authorization, and retries the request with the payment payload attached. The service provider can verify and settle the payment directly, or delegate that work to a facilitator. The result is a much more automated, request-level payment flow, especially suited to one-off API calls and micro-value machine-to-machine transactions.

This is an over-simplification but one isn’t necessarily better than the other. However, in a world of one-time, micro-value payments, the x402-Stablecoin combo has an edge in that it allows for a more friction-free human-free exchange, perfect for an agentic economy.

x402 is open and evolving, later versions could see TradFi payment methods like cards become part of the protocol. However the only way that would work would be if the cards are specifically issued for use-cases the protocol powers e.g. without 2FA. The Facilitator role is an interesting one. It is worth noting that buyers can also leverage facilitators to abstract away the complexity of authorising and cryptographically signing payments. We will see more PSPs participating in this paradigm as facilitators bringing the reach of TradFi payment methods and their legacy characteristics.

.......

That is the core promise of x402. It turns payment from a separate checkout journey into a native part of the web request itself. For human shoppers, that may feel abstract. For AI agents, APIs, and machine-to-machine commerce, it could be foundational.

As always, I’m keen to hear your feedback and thoughts in the comments. If you found this useful, feel free to share it.

Until the next one, Paul

UCP attempts to address the NxN problem between AI platforms and Sellers. Imagine the average e-commerce merchant that wants to maximize it’s reach through all major AI platforms: Gemini, ChatGPT, Claude, Perplexity, etc. They’d have to build an integration with each platform, in every platform’s own defined protocol.

UCP makes this task less complex by providing a universal “language” with which the platforms and sellers can communicate. Let’s review how UCP achieves this with an end-to-end product discovery to checkout and payment through a simplified breakdown of steps.

Part 1: Capability Negotiation

Before anything can happen, both the AI Surface/Interface (Platform) and the Business (Merchant) define their UCP Profiles. The profile outlines what the platform or business is capable of doing under UCP and the relevant communication details.

1. The Platform looks up the Business’s profile from the UCP-structured URL address hosted by the business.

2. Platform contacts Business via endpoints listed in the Business’s profile, and sends over its own UCP profile.

3. Business computes the intersection of capabilities and services supported on both profiles and responds to the Platform with the details of what they both support.

4. Going forward, Platform can interact with Business within the selected UCP Services and Capability specifications.

Part 2: Product Discovery

1. Platform looks up or searches for products at the Business using lookup requests to the Business. How these inquiries are structured and handled is defined in the Catalog Capability.

2. Business responds with various details of products it has determined match the Platform’s lookup criteria, including product IDs, SKUs, prices, links, etc.

3. Platform can show the user the product details and interact with the user if they’d like to purchase the product(s).

Part 3: Checkout Initiation & Payment

If the user asks the Platform to purchase the product:

1. Platform makes checkout ‘creation’ request to the Business outlining the selected product IDs as line items and other checkout specific info like the user’s billing and shipping addresses. This request is defined in the Checkout Capability.

2. Business responds, acting on the requested checkout action with the created Checkout ID, supported payment handlers and its checkout specific configs and constraints.

3. Platform interacts with user to choose a payment method among those the Business indicated it supported in (2).

4. Platform triggers user payment authorization flow with the Credential Provider of the selected payment method. User authenticates and/or authorizes the payment with the Credential Provider (e.g. ApplePay, GooglePay, PayPal, ShopPay or other Tokenizer).

5. Credential Provider generates a payment token according to the Business’s payment handling configs shared in (2). The payment token is then given to the Platform.

6. Platform passes the Payment Token, the checkout ID and other checkout info in the “complete-checkout” request to the Business. This is the final step performed by the platform.

7. Business validates the checkout completion request and processes the provided payment token with its PSP.

8. The result of the payment processing and the order in general are returned to the Platform in the Business’s response. In case of issues that require escalation, such as SCA or 3DS, UCP has a requires_escalation state/response where the Business shares a continue_url to the Platform. With this URL, the platform can hand the user over to the Business through that URL either in a new browser tab or through an embedded web-view.

Part 4: Key Takeaways

1. Each Payment Method or its relevant authority, defines its UPC specs and how Businesses and Platforms use it under UCP.

2. By having a decoupled payment architecture, UCP solves for the N-times-N problem within agentic payments. Platforms do not necessarily have to build or integrate APIs and/or SDKs from every possible PSP a Business might have.

3. UCP is payment protocol agnostic. Although Google obviously promotes its own AP2 protocol, UCP also works with other payment protocols.

4. The business remains the merchant of record. The AI Platform does not take on the merchant of record responsibility.

5. Complex situations that require escalation such as 3DS, SCA or KYC can be handled for example, by handing the user over to the business through a web-view of whatever URL the business provides for escalation.

6. The AI platform defines how it recommends or searches for products. This is not defined by UCP. Remember, the platform communicates directly with the Business, UCP is just the shared communication language.

The Order, Identity Linking and Cart capabilities have not been mentioned in this overview but are worth checking out too. It is interesting that UCP only introduced the Catalog (lookup, search) capability in the April version release. The initial release at the end of 2025 didn’t have it, which to me it felt quite incomplete.

Let me know in the comments if you’ve found value in this article and video. Your feedback and critique is also very welcome.

See you in the next one - Paul

Human Present Flow

1. The User instructs the Shopping Agent to purchase an item. For example, a user asks Gemini to order a Pizza Peperoni from Dominos.

2. The Shopping Agent (Gemini) interacts with the Merchant (Dominos) via the merchant’s MCP endpoint or AI agent, to create a cart with the requested pizza. In this interaction, things like price, product availability, the user’s address, accepted payment methods and delivery options and are exchanged.

3. The Merchant prepares a Cart Mandate which it cryptographically signs, guaranteeing that it’ll fulfil the order at the indicated price. The Cart Mandate indicates the accepted payment methods and other sale conditions. The Merchant signed Cart Mandate is passed to the Shopping Agent.

4. The Shopping Agent then queries the User’s Credentials Provider for the available and compatible payment methods based on the details of the Cart Mandate. The Shopping agent doesn’t access the raw payment credentials, only aliases or tokens are accessed.

5. The Shopping Agent now presents the Cart Mandate and the compatible Payment methods for the user to select a payment method and approve the purchase. This can manifest as a final confirmation request showing the cart, delivery details as well as a selection of compatible payment methods

6. The User selects the payment method and authorizes the purchase. In practice, the authorization manifests as the user’s device signing the Cart Mandate and a Payment Mandate. This involves some form of authentication with the Credential Provider (like how an app invokes Google or Apple Wallet/Pay during an in-app-pruchase, triggering a biometric authentication). The Shopping Agent now has a Cart Mandate signed by the merchant and user, as well as a user-signed Payment Mandate.

7. The Shopping Agent passes the Cart & Payment Mandates to the Merchant for order fulfilment.

8. The Merchant validates the Mandates and processes the order, sending the Payment Mandate to the Merchant’s PSP for processing. Depending on the payment method, the Cart Mandate might be passed as well.

9. The PSP executes the payment instruction defined in the Payment Mandate according to the protocols of the selected payment method and its respective Payment Network and Issuers. This could involve submission of the mandates to the networks & issuers as well as interaction between the networks, issuers and the Credentials Provider to confirm the Payment Mandate’s user authorization before the payment is approved, allowing the Merchant to fulfil the order.

Thanks to the Verifiable Credentials (VCs), i.e. the Cart Mandate and Payment Mandate. There is a deterministic, non-repudiable proof of authorization from the user. In case of any disputes, VCs offer a clear audit trail that will bring about quick resolution.

Human Not Present Flow

This is my understanding of how the Human Not Present flow might work. Keep in mind that it might differ from the eventual protocol version release that defines the flow.

1. The User instructs the Shopping Agent to make a purchase when specific conditions are met. For example, the user might say “Buy me a 2 week return Economy class ticket for Amsterdam to Entebbe sometime in April or May 2026 that’s under 900 when its available.” This exchange includes answering clarifying questions from the Shopper agent such as, whether there’s any particular Airline(s) the user would want to book with.

2. The Shopping Agent validates the conditions by interacting with the potential Merchant Airlines via their MCP endpoints or Merchant AI agents. This could manifest as the Shopper Agent checking which Airlines operate in the requested route, confirming their accepted payment methods, fare ranges, schedules, baggage allowance and other ticket conditions.

3. With the scope of the applicable Merchants, their accepted payment methods; potential fares and other conditions defined … the Shopping Agent then requests for the user’s compatible payment methods from the Credential Provider, ensuring that they meet the user’s & the merchant’s requirements for the potential purchase.

4. The Shopping Agent presents an Intent Mandate to the user to review and approve. It that outlines the purchase conditions, potential merchants, validity period and compatible payment methods in/with which the Agent can make the purchase on the user’s behalf. Think of this as a sort of pre-signed Cart Mandate. This manifests in the form of a confirmation request with all the necessary information for the user approve.

5. The User selects a payment method and approves the Intent Mandate. Specifically, the user’s device signs the Intent Mandate, cryptographically capturing the conditions under which the Shopping Agent is authorized to make the purchase in the user’s absence. In this step, some form of user authentication is performed that involves the Credential Provider. A user signed Payment Mandate is also generated, capturing the user’s authorization to use the selected payment method per the conditions of the Intent Mandate.

6. The Shopping Agent continually checks with the Merchants whether the specific conditions outlined in the signed Intent Mandate have been met. Once met, the Shopping Agent interacts with the Merchant for the preparation of a Cart Mandate with the ticket purchase. The Merchant signs the Cart Mandate and passes it to the Shopping Agent.

7. Armed with the User-pre-signed Intent Mandate and the pre-signed Payment Mandate, the Shopping Agent links the Cart Mandate to the Intent Mandate, essentially embedding the user’s authorization onto the Cart Mandate making it a fully signed Mandate. The Shopping Agent then passes the Cart and Payment Mandates to the Merchant for order fulfilment.

8. The Merchant validates the Mandates and processes the order, sending the Payment Mandate to the Merchant PSP for processing. Depending on the payment method, the Cart and Intent Mandate might be passed as well.

9. The PSP executes the payment instruction defined in the payment mandate according to the protocols of the selected payment method and its network and issuers. This could involve submission of the mandates to the networks & issuers as well as interaction between the networks, issuers and the Credentials Provider to confirm the payment mandate’s user authorization before the payment is approved by the parties involved, after which the tickets can be issued by the merchant.

Like in the Human-Present flow, there is a cryptographic, non-repudiable audit trail across all the parties that verifies the user’s intent and authorization in case of disputes.

Thoughts on the Human-not-Present Flow

It will be interesting to see how this is manifested in the real world, and how granular the conditions can be encoded depending on the merchant’s industry. Would a user for example be able to specify the class of seating, meals, assistance available?

How will these conditions be stipulated in the Intent Mandate technically speaking, in a manner that can be clearly understood by the AI Shopping Agent with no room for hallucination or misinterpretation? In Text, Numbers, JSON? Whatever the means used, the Payment Networks & Issuers will certainly have a major say.

This isn’t so much a problem in the human-present flow since the user is around to give their final approval before the purchase is made. In the human-not-present flow however, there might be room for misinterpretation of qualifying conditions on the part of the AI Shopper. Perhaps it won’t matter since the Payment Networks/Issuers also get to check whether the conditions indeed match those on the Intent Mandate.

I imagine there will be implementations of this flow that include a requirement for the user to confirm the order within a couple of days once the purchase is made, otherwise it’s cancelled (with/without a fee).

There could even be a world where the user-signed Intent Mandate is shared with potential merchants so that a merchant prepares the Cart Mandate as soon as the conditions are met. This would be valuable information for Merchants. They would know how many purchases lie waiting in specific scenarios. It would make for an interesting black Friday & cyber-Monday.

Thank you for watching and reading. Drop a comment below and let me know how you think these flows might play out in different payment method use-cases. I look forward to geeking out on further releases and Agentic Payments Protocols.

If you’re in Payments and/or Tech, you’ve probably seen one of those videos already — an AI agent browsing, selecting, and paying, all on its own. Armed with a disposable virtual card and email address, I set out to give it a try. I tasked a popular AI agent to order a pizza for pickup on the local Pizzeria’s website. As the x10 speed video shows, the AI Agent was successful. From start to finish, the process took about 20 minutes. More importantly, it raised several questions/concerns:

1. Was the merchant aware of the AI navigating their site and hitting ‘pay’?

2. Does the PSP, the card issuer & network see this as an ordinary transaction?

3. Can an AI agent take control of a Mobile device and do the same on an app?

4. What if the AI made a mistake and got me something different?

5. Can I claim I didn’t authorise this transaction?

6. How safe are the card details with the AI provider?

7. How does a merchant tell a good AI agent/bot from a bad one?

Visa, Mastercard, PayPal, Google, Stripe, and others have announced solutions that address several of these concerns, enabling smooth and trusted commerce and payments within Agentic Commerce contexts. They include mechanisms that verify and store human-intention; introduce safeguards and offer APIs & SDKs for merchants and other payment ecosystem players to plug into.

These will inevitably power AI-native commerce use-cases and flows with merchant, acquirer, network and/or PSP level awareness that an AI shopper is at play. Awareness might be inferred from something as simple as a virtual PAN or token attributes specific to Agentic Commerce; or even through bespoke Agentic Commerce specific integrations such as MCP endpoint exposure to AI platforms.

And with this awareness, intent/mandate and other key transaction information — different players in the payments value-chain can process such AI-initiated/AI-assisted transactions with adequate controls, clearer liability frameworks and dispute resolution mechanisms.

While these ‘agent-declared‘ flows, frameworks and protocols are a positive and much needed development, adoption will take time and will be fragmented across the competing options. As merchants, regulators and ecosystem players wait and see how things pan out ... Agentic commerce/payments continue to happen today, right now on merchant websites as demonstrated, maybe even on Mobile apps without Agentic commerce protocols, frameworks or MCP integrations.

On the Mobile Apps front, there’s already published research, automation providers and consumer apps proving that similarly capable Mobile AI agents exist. You could soon be able to ask an app-based AI assistant to purchase a flight ticket on a 3rd party Airline’s app in the same way my Pizza was ordered. (i.e. without the Airline knowing an AI Agent is performing the action). An agent-declared equivalent of this is OS level assistants Siri/GoogleA leveraging App Intents/Actions exposed to them by apps to purchase on behalf of users. But these are restricted flows, you cannot yet ask Siri/GoogleA to search, compare and purchase on apps that haven’t exposed these intents/actions to the OS.

Now to be fair, I am hardly the average consumer. I have the wherewithal to correctly prompt/instruct the AI agent to do this for me with safeguards (disposable card & email; low risk & value purchase). It could be years before the average consumer can do similar with the same degree of confidence. In fact, there’s even some interesting arguments that cast Agentic Commerce as misplaced hype. Still, what’s possible for me today will be trivial for the average consumer tomorrow. And that’s where the real risk begins.

Regardless, commerce/payments of this pizza example and other ‘agent-undeclared‘ payment flows are possible and are happening today, even if just a fraction of overall e-commerce payment volume. In these cases, most e-commerce merchants today are unable to detect or react to these AI agents. They are effectively ‘agent-blind’!

Why is this important? The AI Agent in this video asked me for a final confirmation before hitting pay and assured me that it does not store my sensitive information. However, the technology to build similar browser & other software controlling AI agents is out there. Anyone can offer AI agent tools to the masses, may not be as scrupulous and could for example use shopping experiences to capture sensitive credentials to make unauthorised purchases. They could also be leveraged to test stolen cards at agent-blind merchants at scale. Genuine AI agents might make wrong purchases for customers who might then initiate chargebacks. The point is that real-world implications exist.

Merchants should audit how their channels interact with the available AI agent tools/platforms in the market and build policies & strategies on how to detect and distinguish such intents from the other 51% of internet traffic now generated by non-human users — bots, scripts, automated agents. From this eCommerce agent-awareness, they can then manage these use cases within acceptable risk parameters.

To be clear, many Agentic Commerce use cases are of great value to customers who are knowledgeable and comfortable with the risks, even in agent-undeclared flows. Merchants and their providers must weigh the upside against the risk in determining whether and how to support or block the use cases as applicable for their industry.

An example would be a merchant, recognising the use of an AI agent from a known platform requiring 2FA on payment execution as final check to ensure there’s a human in the final step (to the extent that this can’t also be delegated away) and shift liability away from themselves. Payment methods with 2FA offer a safeguard against the risk agent-undeclared flows present. However, if my intention is not to be present when the purchase is executed, I’m unlikely to ask the AI to use such a payment method. I could have the AI agent purchase elsewhere.

Naturally, deep-pocketed merchants will have the resources to invest in these measures. It’s another thing for merchants without dedicated payments or security teams to worry about. But an opportunity for PSPs, eCommerce Platforms, Risk and Security providers to step in and offer guidance & solutions to this challenge. If you’re interested in the nuts and bolts of detection, here’s a sales pitch with some free insights that I found educational. I am not affiliated with this provider.

Amazon appears to have made the decision to block such traffic. I wasn’t able to get the AI Agent to open their website. From their perspective, it makes sense that they wouldn’t want to cede discovery to AI platforms. But as search behaviour moves to AI powered, chat-based answer engines, can a small, eager to be found merchant afford such a policy? - Well, that’s the topic for another day. Next time, I might just let the AI decide where to order from. Let’s see which merchants are ready to notice.

Let me know what you think, do you agree? Drop a comment, share your thoughts, strategies and counter arguments. I’m eager listen to and learn from different perspectives.

Until the next one.

Paul