Your AI Agent Can Shop. Can It Actually Pay?

What is agentic commerce?

Agentic commerce refers to AI agents acting on behalf of an individual (usually a consumer) to make online purchases. The transactions are made by an autonomous AI agent that acts on a user’s behalf to discover, select, and pay for goods or services, with limited or no human intervention at the moment of purchase. It spans two distinct flows:

• Consumer-facing commerce: An agent (in ChatGPT, a Google surface, or a custom app) completes a checkout for a human shopper.
• Machine-to-machine (M2M) commerce: An agent autonomously pays for an API call, a data feed, or a compute session as part of its own workflow.

Both flows share one unsolved problem: the agent has to prove it’s authorized and move real money across systems that were never designed to talk to each other. That’s where today’s tooling breaks down.

The protocol sprawl is already here

The infrastructure for agentic commerce is real, but it’s early, fragmented, and moving fast. Instead of a single standard, we’re watching a sprawl of overlapping protocols designed to enable machine-driven purchases.

On the consumer and checkout side, two major models have emerged. Google developed the Universal Commerce Protocol (UCP) in collaboration with partners including Shopify, Etsy, Wayfair, Target, and Walmart. [1] On the other side, OpenAI launched the Agentic Commerce Protocol (ACP), an open standard for agent-to-business transactions. [2]

For payment execution, Google introduced the Agent Payments Protocol (AP2), an open protocol built to securely initiate and transact agent-led payments across platforms. [3]

For merchants, this creates an immediate problem. The protocol they need depends on the acquisition channel, the agent ecosystem, the checkout flow, and the payment rail. A ChatGPT-native commerce flow brings into play ACP. A Google-led commerce flow brings UCP and AP2 into play.

Agentic protocols at a glance

The hard question is simple: how many protocols should a merchant build for, maintain, and keep secure?

Without an abstraction layer, every new agent ecosystem becomes another bespoke integration.

Machine payments don’t look like checkout

Consumer chatbots grab the headlines, but machine-to-machine payment flows are just as sophisticated.

When an AI agent autonomously pays for an API call, data feed, or compute session, it relies on backend payment protocols such as the Machine Payments Protocol (MPP) or x402. Both build on the familiar HTTP 402 (“Payment Required”) pattern. A server responds to a request with a 402 status code and payment instructions, the client authorizes the payment, then retries the request with signed payment credentials attached. [4]

MPP can settle payments on-chain. By locking funds upfront in a payment session and issuing off-chain vouchers that are settled in batches, MPP supports sub-100ms transaction latency while keeping per-request costs close to zero. [5]

Similarly, x402 enables agents to pay programmatically for digital resources using stablecoins, without requiring user accounts or manual intervention. Emerging implementations also support deferred settlement models that separate real-time cryptographic authorization from financial settlement. This allows servers to grant access immediately while aggregating micropayments for later settlement through either traditional payment rails or stablecoins.

That matters because machine-to-machine payments won’t resemble traditional checkout; they’ll be high-frequency, low-value, and fully automated. The payment layer has to be fast, programmable, and safe by default.

The trust problem: user identity isn’t enough. You need to identify agents.

Before accepting an automated transaction, a merchant has to answer one question:

Is this a legitimate AI agent acting on behalf of a real customer, or a malicious bot?

The industry is building new trust signals to draw that line.

The FIDO Alliance is developing standards for trusted AI agent interactions, focused on secure delegation, verifiable user instructions, and boundaries between user-initiated and agent-initiated actions. [6]

Visa’s Trusted Agent Protocol (TAP) takes a complementary approach. TAP uses HTTP message signatures so merchants can validate agent requests cryptographically using public keys. [7]

Mastercard’s Agent Pay & Verifiable Intent: Mastercard’s Agent Pay issues “Agentic Tokens” that mathematically bind a tokenized card credential to a specific agent identity, merchant scope, and consent policy. To prove the agent acted within those bounds, Mastercard and Google co-developed Verifiable Intent. This trust layer uses a 3-layer SD-JWT architecture that hashes the user’s identity, their specific instructions, and the transaction outcome into a single tamper-resistant record. If a hallucinating agent attempts to alter a cart item, the cryptographic hash breaks, instantly voiding the transaction.

Google’s Agent2Agent (A2A) protocol establishes intrinsic agent identity at the machine-to-machine level. It treats agent identity as a specialized workload identity based on the SPIFFE standard, ensuring credentials are bound to the runtime environment to prevent replay attacks. A2A also introduces standardized “Agent Cards” that act as a cryptographic business card, allowing agents to securely advertise their capabilities and authenticate across enterprise platforms.

All these efforts address the same core problem: letting legitimate agents through security perimeters without treating them like automated attacks.

But identity alone isn’t enough. Agentic commerce also needs to prove intent, including who the agent represents, what the human actually authorized, and whether the request should be trusted at all.

Why a translation layer isn’t optional

The thread running through all of this is interoperability.

An agent might use ACP, UCP, AP2, MPP, x402, or a standard that doesn’t exist yet. In every case, payment credentials, mandates, identity signals, and compliance data must move securely between systems that weren’t designed to communicate with each other.

To bridge the execution gap, merchants and developers need an architectural layer that handles three jobs.

1. Vaulting and tokenization. Raw payment data needs to be locked down so neither the AI agent nor the merchant unnecessarily expands their PCI compliance scope.
2. Policy and consent. The system has to track proof that a human authorized the agent to act, including spending limits, merchant permissions, and usage constraints.
3. Translation. A credential or mandate from one protocol must be ingested, normalized, and routed to the merchant’s preferred PSP in the correct format.

For card-based agentic commerce, tokenization is the scalable path. Agentic Network Tokens alone is not the answer. Agents and merchants need universal tokenization as a framework that makes their data compatible with any agentic protocol: agentic payments.

Where VGS fits into agentic commerce

VGS acts as both a “Universal Translator” and an AI Data Firewall. It collects payment data once, securely vaults it, and translates it across supported protocols and payment rails. Network tokens, PCI tokens, and protocol-specific credentials flow through a single interoperable layer, so merchants don’t have to build bespoke integrations every time a new agent, wallet, or standard hits the market. [8]

The VGS result: agents can act, merchants can accept, and sensitive data stays protected.