The Week Agentic Commerce Hit Reality

Tim WilliamsMarch 12, 2026

Standards are not software. What Mastercard’s Verifiable Intent and OpenAI’s retreat tell us about where agentic commerce actually stands.

Tim Williams — CEO and Cofounder — AstraSync AI

On 5 March 2026, OpenAI quietly confirmed it was killing Instant Checkout inside ChatGPT. The feature, launched with considerable fanfare in September 2025 alongside partnerships with Shopify, Etsy, Walmart, Target, and PayPal, had produced near-zero purchase conversions. Of Shopify’s millions of merchants, roughly a dozen had integrated. OpenAI hadn’t built sales tax collection. Users browsed in enormous numbers and bought almost nothing.

The same week, Mastercard and Google published Verifiable Intent, a new open specification for cryptographically proving human authorisation in agentic transactions. The announcement landed with an impressive coalition: Adyen, Basis Theory, Checkout.com, Fiserv, IBM, Worldpay. A specification site went live at verifiableintent.dev. A GitHub repository appeared with a Python reference implementation for testing the credential format against standalone examples, though not yet integrated with any commerce protocol or payment stack.

Two announcements. One retreat from implementation. One advance in specification. Together, they tell a more honest story about where agentic commerce actually stands than either does alone.

What Verifiable Intent Actually Is

Most commentary on the announcement has focused on Mastercard’s market positioning rather than the technical substance. The technical substance deserves a closer look, because the underlying work is genuine.

Verifiable Intent (VI) is a layered SD-JWT credential format, built on RFC 9901, that creates a cryptographic chain binding an AI agent’s commercial actions to a human’s explicitly stated purchase intent. It uses established standards from the FIDO Alliance, EMVCo, the IETF, and the W3C. It is not a marketing exercise bolted onto existing payment rails. It is proper standards work.

The architecture uses three credential layers. Layer 1 is issued by a credential provider (such as a bank or payment network) and binds a user’s cryptographic public key alongside payment card identifiers. Layer 2 is created by the user and contains either final transaction values (in “Immediate” mode, where the human confirms directly) or constraints that define what an agent is allowed to do (in “Autonomous” mode, where the agent acts independently within those constraints). Layer 3, used only in Autonomous mode, is created by the agent and contains the specific transaction details that fulfil the user’s constraints.

Each layer is cryptographically bound to the one above it through key confirmation claims. The chain is tamper-evident. Selective disclosure ensures each party in a transaction sees only what it needs: merchants see checkout details (what is being purchased) but not payment credentials, while payment networks see payment details but not specific line items.

The constraint enforcement model is well designed. Eight constraint types cover amount bounds, merchant allowlists, budget caps, and recurrence terms, all cryptographically bound and machine-verifiable. In Autonomous mode, a payment network can confirm that an agent’s actions fall within the boundaries the human defined, without seeing the specific products being purchased.

This is a meaningful contribution. The problem of proving that a human authorised a specific agentic transaction, and that the agent acted within defined parameters, is one that needed solving. The cryptographic approach is sound. The selective disclosure model is thoughtful. The coalition of payments infrastructure providers behind it is credible.

The question is not whether the work is good. It is whether the announcement represents something an enterprise can deploy today, or something the industry is working toward.

The Gap Between Specification and Implementation

Verifiable Intent is a v0.1 draft specification dated 18 February 2026. Its GitHub repository contains a Python reference implementation with standalone examples for testing the credential format, including autonomous and immediate flow demonstrations, selective disclosure, and constraint checking. Ten contributors, all appearing to be Mastercard engineers. Three stars, zero forks.

What the repository does not contain is merchant integration tooling, protocol bindings that work with existing commerce stacks, or anything that connects VI credentials to actual payment processing. The specification explicitly places “out of scope” transport protocols, key management and provisioning, credential provider enrolment, agent platform APIs, dispute resolution, and regulatory compliance mapping. The protocol landscape documentation provides conceptual mappings to AP2, ACP, and UCP, but each integration would need to be built individually by the adopting party.

This means that an enterprise buyer wanting to test VI today can run Python examples that demonstrate the credential chain working in isolation. They cannot plug it into their payment stack and test it against real or simulated transactions. They cannot test it alongside AP2 or UCP without building those integrations themselves. The gap between “reference implementation” and “testable proof of concept” is where significant engineering work remains.

VI is not alone in this position. Consider the broader protocol landscape for agentic commerce as of March 2026.

Google’s Agent Payments Protocol (AP2) launched in early 2025 and has a published specification with Python SDKs. Google’s Universal Commerce Protocol (UCP) was announced at NRF in January 2026, co-developed with Shopify, Etsy, Wayfair, Target, and Walmart, and endorsed by more than 20 partners. Stripe and OpenAI’s Agentic Commerce Protocol (ACP) survives in narrower form following the Instant Checkout retreat. Visa has its Trusted Agent Protocol. Anthropic’s Model Context Protocol (MCP) and Google’s Agent-to-Agent protocol (A2A) handle agent communication and tool integration respectively.

Each of these solves a specific piece of the stack. Commerce orchestration. Payment authorisation. Agent communication. Tool integration. Intent verification. All are necessary. All represent genuine technical contributions.

The pattern, however, is striking. The agentic commerce ecosystem has an abundance of protocols and a shortage of production deployments. Every protocol needs to interoperate with several others to deliver a complete commerce flow, and each of those interoperability bridges requires its own integration work. For a merchant or enterprise evaluating this space, adopting a single protocol solves a single problem. Adopting the full stack means integrating multiple specifications, most of which have no production-grade integrations with each other.

Why OpenAI’s Retreat Matters

OpenAI’s withdrawal from Instant Checkout is frequently being framed as evidence that agentic commerce is overhyped. This reading misses the more important signal.

Agentic commerce is not overhyped as a concept. The trajectory toward AI agents participating in commercial transactions is well established and accelerating. What OpenAI’s retreat demonstrates is something more specific: the gap between announcing agentic commerce capability and deploying it in production is where every hard problem lives.

OpenAI discovered that product data across the internet is too fragmented for reliable automated checkout. That sales tax compliance across thousands of jurisdictions requires infrastructure they hadn’t built. That fraud detection for agent-initiated transactions demands systems that don’t yet exist in their stack. That users trust established merchant checkout experiences in ways they do not yet trust an AI intermediary.

These are not conceptual problems. They are implementation problems. They are the problems that emerge only when software meets the real world at scale. Specifications don’t encounter them. Production deployments do.

The Forrester analysis published this week noted that completing a purchase through an AI assistant remains the least-adopted use case among regular answer engine users. The most common uses remain asking general questions and researching products. The behavioural gap between discovery and transaction is not primarily a protocol problem. It is a trust problem.

Shopify’s president Harley Finkelstein acknowledged the constraint: merchant adoption remains extremely limited. The volume of agent-initiated transactions is not yet sufficient to justify the integration complexity that the current protocol landscape demands. This is a chicken-and-egg problem that standards alone cannot resolve. The protocols exist. The integrations between them largely do not. The production deployments are almost nonexistent.

What Merchants and PSPs Actually Need to Understand

Before examining the missing layers, it is worth stepping back and asking a practical question: why should a merchant or payment service provider care about any of this beyond the immediate protocol adoption decision?

The answer is liability.

When a human walks into a shop and pays with a card, the liability framework is well established. Card-present fraud has clear chargeback rules. The merchant knows a human was there. The acquirer knows who processed the transaction. The issuer knows whose account was debited. When something goes wrong, there is an evidence chain and a dispute process refined over decades.

When an AI agent initiates a transaction through an agentic commerce protocol, several of those signals disappear. There is no device fingerprint in the traditional sense. There is no behavioural biometric. The “customer” is software. VI addresses one piece of this: cryptographic proof that a human authorised the transaction within defined constraints. This is valuable. It is also insufficient, because the most dangerous failure modes in agentic commerce are not about whether the authorisation was valid. They are about what happens between authorisation and execution.

Consider four scenarios that illustrate how an agent with perfectly valid credentials can still cause material harm.

A developer builds an agent with a hidden backdoor. Under VI and every other current protocol, the developer is invisible. The L1 credential binds the cardholder. The agent presents cryptographic keys. Nobody in the transaction chain knows or has verified who wrote the agent’s code. The agent performs its declared shopping function while simultaneously exfiltrating merchant catalogue data, pricing intelligence, or customer interaction patterns to a third party. Every credential in the chain validates perfectly. If the developer is never identified, there is no one to hold accountable and no mechanism to flag every other agent that developer has built.

The agent connects to a compromised MCP server between authorisation and purchase. The human authorises the agent at time T1 with a $300 budget and a list of approved merchants. Between T1 and the transaction at T2, the agent connects to an MCP tool server that has been compromised. The tool poisoning modifies the agent’s behaviour. Crucially, it does not cause the agent to exceed its spend limit. The agent stays within the $300 budget and transacts with a merchant on the approved allowlist. It simply buys different products and ships to a different address. VI’s credential chain validates perfectly because every technical constraint was satisfied. The merchant fulfils the order in good faith. The human receives products they never intended to buy, or worse, the products arrive at an address the human never provided. The chargeback hits the merchant, who has already shipped the goods and loses both the product and the revenue, despite holding a cryptographically valid authorisation chain. No current protocol prevents this because the attack operated within the authorised parameters, not outside them.

A malicious website or new instructor prompt-injects the agent. The mechanism is different but the outcome is identical. The agent’s guardrails operate within the same context as adversarial inputs. A malicious website the agent visits during product research, or a new instructor crafting adversarial prompts, can alter the agent’s decision-making while the agent remains within VI’s technical constraints. The agent completes a purchase that satisfies every constraint in the credential chain, but that doesn’t reflect the human’s actual intent. The same chargeback liability follows.

The underlying model is swapped between authorisation and execution. The platform provider pushes an update to the LLM powering the agent. The agent’s code hasn’t changed. Its credentials haven’t changed. Its behaviour has changed fundamentally because the model it runs on is different. A model that previously selected the cheapest option matching a product description might now select the highest-rated option. A model that previously interpreted “running shoes” literally might now interpret it as “trail running shoes.” The model may be more susceptible to prompt injection than the version it replaced, opening the door to the scenarios above. For the buyer, this means receiving products that don’t match what they expected from an agent that previously performed reliably. For the merchant, it means processing orders that generate returns and disputes at higher rates, because the purchasing decisions were made by what is functionally a different decision-maker using the same credentials. Neither the merchant nor the buyer can detect this. VI cannot detect it because the credentials are unchanged.

All four scenarios share the same structural characteristic: the authorisation was valid, the constraints were technically satisfied, and the merchant still loses money. The existing protocols verify the authorisation. They have zero visibility into whether the agent executing the transaction is the same agent that was trusted in the first place, or whether its decision-making has been altered between authorisation and execution.

These risks sit alongside the broader disintermediation concerns that agentic commerce introduces: the loss of customer relationship data, cross-sell revenue, and retail media attribution when the point of purchase shifts from the merchant’s own storefront to an AI interface. We examined these dynamics in detail in our earlier analysis of UCP and merchant adoption. VI does not resolve them. They compound the adoption decision for any merchant evaluating whether the benefits of agentic commerce justify the risks.

The Layer Nobody Has Built

Verifiable Intent solves payment authorisation. AP2 and UCP solve commerce orchestration. A2A and MCP solve agent communication and tool integration. These are all layers of the same stack, and they are all necessary.

There is a layer none of them address.

The VI specification acknowledges this boundary explicitly. It includes an agent_attestation field designed to accept external identity or security attestations, with the specification noting that "future companion documents will define specific attestation schemes." This is a well-scoped design decision that recognises payment authorisation and agent identity are different problems. The scenarios above illustrate why that missing layer is not a future concern. It is a present one.

What the stack needs is an identity and trust layer that makes the humans in the agent’s chain visible and verified, that defines governance constraints before the agent’s first action, and that monitors the agent’s behaviour continuously between authorisation and execution. This is the layer that detects the developer backdoor, the tool poisoning, the prompt injection, and the model swap, not by preventing them from happening, but by identifying when the agent’s behaviour deviates from its declared purpose, even when its credentials remain technically valid.

Why Agent Identity Maps to Financial Compliance

In the traditional financial system, KYC (Know Your Customer), KYB (Know Your Business), and AML (Anti-Money Laundering) frameworks exist for a specific reason: before any entity is permitted to participate in financial transactions, the humans behind that entity must be verified, their authority to act must be established, and an ongoing obligation exists to monitor for suspicious activity. These are not optional features. They are regulatory requirements enforced under penalty of law.

When an AI agent initiates a financial transaction, the compliance infrastructure for the agent itself does not exist within any current protocol. VI’s Layer 1 credential binds a user’s cryptographic key alongside their payment card identifiers. The human identity verification here is inherited from the existing card issuance process: the credential provider (bank or payment network) relies on the KYC it performed when the card was originally issued. VI does not perform its own identity verification. It assumes the credential provider already did. This is a reasonable design choice for the payment authorisation layer, and it means the instructing human’s identity is covered to the extent that existing card issuance KYC covers it.

What is entirely absent is compliance infrastructure for the humans responsible for the agent itself. Under every current agentic commerce protocol, the developer who wrote the agent’s code is invisible. Not unverified. Invisible. There is no field in any credential, no layer in any chain, that identifies who built the agent. This matters because verification creates accountability, accountability creates deterrence, and deterrence reduces the likelihood of the attack scenarios described above.

The compliance mapping differs depending on the agent’s provenance. Where an individual developer builds an agent independently, verification of that developer maps to KYC, the same identity verification applied to any individual participating in financial services. The developer is a known, verified person whose identity is tied to every agent they produce. If that developer subsequently builds a malicious agent, the trust impact propagates across every agent they have registered. Where a platform provider builds and operates an agent (for example, an agent built by OpenAI or Anthropic), the verification maps to KYB, the business verification applied to corporate entities in financial services. Where an agent has changed hands, been sold through a marketplace, or been deployed by an organisation different from the one that built it, the current deploying entity requires separate KYB verification, and the lineage from developer through to current operator must be traceable. An agent whose developer has had their credentials revoked, or whose deploying organisation has failed AML screening, should not be transacting through any payment network. No current protocol enforces this. Most current protocols cannot even identify which developer or organisation to check.

The ongoing monitoring obligation is equally critical. AML and transaction monitoring frameworks require continuous surveillance of financial activity for anomalous patterns. For human account holders, this is established practice. For AI agents, the equivalent is behavioural monitoring: is the agent operating within its declared purpose? Has its behaviour changed materially since its credentials were issued? Are its transaction patterns consistent with its historical baseline? This is what detects the tool poisoning, the prompt injection, and the model swap: not by examining the credentials (which remain valid) but by identifying when the agent’s behaviour no longer matches the agent that was originally trusted. Without this monitoring, a compromised or altered agent can operate freely within the technical constraints of its credentials until the compromise is discovered by other means.

The Regulatory Dimension

Every major jurisdiction is actively developing governance frameworks for AI systems that operate with financial authority.

Singapore launched the world’s first dedicated governance framework for agentic AI in January 2026 at the World Economic Forum. Developed by IMDA, the Model AI Governance Framework for Agentic AI requires organisations to assess and bound risks before deployment, allocate clear human accountability across the agent’s value chain and lifecycle, implement technical controls throughout the agent lifecycle, and enable end-user responsibility through transparency. The framework explicitly addresses accountability distribution across developers, deployers, operators, and end users, and requires human oversight mechanisms that can override, intercept, or review agentic actions. Though currently non-binding, it signals the regulatory direction for ASEAN and has been widely adopted as a reference point globally.

The EU AI Act classifies autonomous financial decision-making systems in its highest risk category. NIST’s AI Risk Management Framework requires verifiable accountability chains for high-impact AI systems. Australia’s automated decision-making obligations, commencing in December 2026, will require entities deploying AI agents in financial contexts to demonstrate provenance, governance, and auditability.

These frameworks share a common requirement: that the humans responsible for an AI system’s actions can be identified across the full value chain, that the system’s authority can be verified, and that an immutable record of its actions exists for regulatory review. This last point is worth emphasising. Regulatory-grade auditability requires records that are immutable (cannot be altered after the fact by any party to the transaction), decentralised (not controlled by a single entity whose interests may conflict with accurate record-keeping), and comprehensive (covering the full chain from developer through deployer through to the instructing user and the agent’s actions at runtime). It requires a common ledger that all parties, including regulators and dispute investigators, can reference as a single source of truth for what an agent was authorised to do, what it actually did, and who was responsible at each point in the chain. No current agentic commerce protocol provides this. VI provides payment authorisation. The commerce protocols provide transaction orchestration. Neither provides the immutable, decentralised audit infrastructure that connects agent actions to human accountability.

What the Stack Actually Needs

The agentic commerce stack requires at minimum four distinct layers working together.

The first is communication and orchestration: how agents talk to each other and to services. A2A, MCP, UCP, and the various commerce protocols address this, with implementations progressing.

The second is payment authorisation: how we prove a human approved a financial transaction initiated by an agent. This is what Verifiable Intent addresses, and it addresses it well within its defined scope.

The third is identity, trust, and compliance: who built this agent, who deployed it, what is it authorised to do beyond a single transaction, and can the humans in the chain be verified to the same standard required for any participant in financial transactions? This is the layer that makes the developer visible and verified (preventing unaccountable agents from entering the ecosystem), that defines governance constraints before the agent’s first action (so that deviation from purpose is detectable, not just deviation from spend limits), that monitors behaviour continuously between authorisation and execution (detecting tool poisoning, prompt injection, model swaps, and other integrity failures that operate within technical constraints), and that provides an immutable, decentralised audit trail meeting regulatory evidentiary standards.

The fourth is regulatory mapping: how all of the above translates into compliance across the emerging patchwork of AI governance frameworks, from Singapore’s MGF to the EU AI Act to NIST to Australia’s automated decision-making obligations. This is inseparable from the third layer, because the audit trail, the provenance chain, and the human accountability mapping are themselves regulatory requirements, not optional additions.

Each layer depends on the others. Payment authorisation without agent identity verification is a credential chain anchored in an assumption that the agent presenting it is the same agent that was trusted. Agent identity without payment authorisation leaves financial transactions unprotected. Communication protocols without either are plumbing without a trust model.

The protocols and standards emerging across the first two layers are heading in the right direction. The identity, trust, and compliance layer is where the gap is widest. It is also the layer that, by structural necessity, cannot be built by any single platform, payment network, or hyperscaler without creating a walled garden. Google will not adopt Microsoft’s agent identity standard. Visa will not adopt Mastercard’s. Enterprises operating across multiple platforms need a neutral identity layer that works across all of them.

This is what we are building at AstraSync. Our ASAT protocol exists as an extension layer, not an alternative to any of the standards discussed in this article. We do not re-solve what VI, AP2, UCP, or any other protocol handles well. We layer on the identity and trust infrastructure they all need underneath.

Our KYD (Know Your Developer) verification makes the developer visible for the first time, with bank-grade KYC or KYB depending on whether the developer is an individual or an organisation. That verification creates a trust baseline that propagates to every agent the developer registers. Our KYO (Know Your Owner) verification traces the chain through to the deploying entity. Our KYA (Know Your Agent) verification binds the agent’s identity to its full human provenance chain. Our PDLSS constraints (Purpose, Duration, Limit, Scope, and Self-instantiation boundaries) define governance parameters before the agent’s first action, expressed as immutable, machine-enforceable rules rather than runtime-derived baselines. Our dynamic trust scoring monitors the agent’s behaviour continuously against its declared purpose, detecting the behavioural deviations that credential-based systems cannot see. And our blockchain-anchored audit trail provides the immutable, decentralised evidentiary record that regulators and dispute investigators require.

We have built AP2 and UCP compliance into our KYA Platform. We are adding VI compliance now and expect to have it integrated into our sandbox implementation by end of April. For any enterprise looking to start on a proof of concept across any of these protocols, the infrastructure is testable today, not as standalone Python examples, but as working software connected to a real verification pipeline.

Want your agent to navigate AP2, transact through Verifiable Intent, and present a Verifiable Credential or DID as its identity primitive? It should. We provide the verified lineage, behavioural trust, and accountability layer underneath that makes those credentials meaningful.

Where This Goes Next

The week of 5 March 2026 will likely be remembered as the week the agentic commerce market crossed from aspiration to reckoning. The market leader in agentic checkout retreated from implementation. A major payment network advanced the standards work. The gap between the two tells us where the industry actually stands.

The standards are moving in the right direction. The implementations are earlier than the announcements suggest. The identity and trust layer that the entire stack depends on is being built in parallel, not after the fact.

The next twelve months will separate the announcements from the deployments. Enterprises evaluating agentic commerce infrastructure should be asking not just “which protocols do you support?” but “can I test this in a sandbox this quarter?” The answers to that question are more revealing than any specification document.