Best Agentic Checkout Systems 2027: ACP vs UCP vs Visa vs Mastercard
DN ranks agentic checkout systems including ACP, UCP/AP2, Visa, Mastercard, MPP and x402 by authorization, state certainty, duplicate protection and recovery.
Agent Checkout Reliability Index 2027
AI agents can increasingly discover products, build carts, obtain payment credentials and complete purchases. DN ranks the emerging agentic checkout stacks by authorization integrity, checkout-state certainty, payment controls, duplicate protection, recovery and post-purchase accountability.
What Matters
The hardest part of agentic commerce is not getting an AI agent to click “buy.”
The hard part is ensuring that the agent buys the correct item, at the correct price, from the correct merchant, with authorized credentials, exactly once, and that every participant can determine what happened afterward.
Under Version 1.0 of the DN Agent Checkout Reliability Index, Agentic Commerce Protocol with Stripe ranks first at 98/100.
ACP combines a stateful checkout API with explicit create, retrieve, update, complete and cancel flows. Each interaction returns current authoritative checkout state, while Stripe's Shared Payment Tokens can constrain payment authority by merchant, amount, currency and expiration.
Google UCP + AP2 follows at 97/100 and arguably provides the most ambitious authorization architecture in the benchmark. UCP handles the broader commerce lifecycle, while AP2 binds user authorization to signed Checkout and Payment Mandates and returns cryptographically verifiable receipts.
Visa Intelligent Commerce and Mastercard Agent Pay bring network-level tokenization, authentication, intent and dispute infrastructure into agentic commerce.
MPP and x402 solve a different but equally important category: fast machine-native purchases where the buyer may be software purchasing APIs, compute, data or other digital resources rather than a human buying physical goods.
The DN Agent Checkout Reliability Rankings
| Rank | Agentic Commerce Stack | DN Score | Best Reliability Strength | Best Fit | Current Maturity |
|---|---|---|---|---|---|
| 1 | ACP + Stripe | 98/100 | Authoritative checkout state + scoped payment tokens | Retail and in-context commerce | Production |
| 2 | UCP + AP2 | 97/100 | Cryptographic intent, checkout and payment evidence | Open multi-platform commerce | Rolling Adoption |
| 3 | Visa Intelligent Commerce | 95/100 | Agent-bound credentials + transaction controls | Card-network commerce | Pilot / Rollout |
| 4 | Mastercard Agent Pay | 94/100 | Agentic Tokens + Verifiable Intent + auditability | Authenticated agent purchases | Active Pilots |
| 5 | MPP + Stripe | 92/100 | Usage-based machine payments + existing payment stack | APIs, compute and machine services | Live |
| 6 | x402 | 90/100 | Simple HTTP-native pay-and-deliver flow | APIs and digital resources | Live |
These are documented reliability-architecture scores, not measured merchant conversion rates, payment authorization rates or protocol uptime. The systems solve different layers of the commerce stack and are not perfect substitutes.
The Five States Every Agent Checkout Must Distinguish
A reliable commerce stack must preserve consistency across all five.
That requirement sounds obvious.
In distributed software, it is not.
1. ACP + Stripe: Best Overall Agent Checkout Reliability Architecture
Agentic Commerce Protocol + Stripe
Agentic Commerce Protocol was designed around a useful principle: agents should not scrape or imitate a checkout interface when merchants can expose deterministic commerce state directly.
The ACP Checkout API provides a stateful REST interface through which an agent can:
- create a checkout session;
- retrieve current checkout state;
- update cart contents;
- change fulfillment information;
- select shipping options;
- complete payment;
- cancel the session.
Most importantly, each interaction returns the latest authoritative checkout state.
That helps prevent a common agent problem where the model continues acting on stale prices, inventory or fulfillment assumptions.
The seller remains responsible for authoritative calculations including:
- inventory;
- price;
- discounts;
- tax;
- shipping;
- payment processing;
- fulfillment.
ACP therefore avoids letting the model hallucinate commercial facts that belong to the merchant.
Scoped Payment Authority
Stripe's Shared Payment Tokens add another important reliability layer.
Instead of giving an agent reusable raw payment credentials, the token can carry constraints such as:
- maximum amount;
- currency;
- merchant;
- expiration;
- usage conditions.
Underlying payment credentials remain hidden.
ACP also exposes intervention capability for cases such as 3DS authentication, allowing an automated flow to identify when human or issuer interaction is required instead of simply failing.
DN view: ACP's strongest feature is not that checkout happens inside an AI interface. It is that the agent receives a deterministic representation of the merchant's real checkout state.
Explore Agentic Commerce Protocol Stripe Agentic Commerce2. UCP + AP2: Best Cryptographic Authorization Architecture
Universal Commerce Protocol + Agent Payments Protocol
Google's Universal Commerce Protocol addresses more than payment.
UCP defines a broader commerce interface covering product discovery, checkout, fulfillment, discounts, order lifecycle and related capabilities.
Its current native checkout implementation includes:
- checkout session creation;
- retrieval;
- updates;
- completion;
- cancellation;
- structured recoverable and unrecoverable errors.
The merchant remains responsible for calculating the authoritative total and processing payment.
Current UCP order-lifecycle infrastructure also requires signed webhook events. Freshness is explicitly checked, and stale order updates can be rejected.
That matters because post-purchase data can arrive out of order in distributed systems.
AP2 Adds Proof of Intent
AP2 solves a deeper question:
How does a merchant know that the agent was actually authorized to make this specific purchase?
AP2 defines signed:
- Checkout Mandates;
- Payment Mandates;
- Checkout Receipts;
- Payment Receipts.
A Payment Mandate can be cryptographically bound to a finalized checkout.
The specification also distinguishes direct human-present flows from autonomous human-not-present purchases.
Importantly, AP2 requires mandate verification to happen in deterministic code even when an agentic system is involved.
That is exactly the separation DN wants to see in high-value autonomous commerce.
Why it ranks second: the architecture is exceptionally strong, but Google's current UCP merchant deployment path still requires approval and staged integration, making ACP's present production maturity somewhat stronger.
Google UCP Documentation AP2 Specification3. Visa Intelligent Commerce: Best Network-Agnostic Card Infrastructure
Visa Intelligent Commerce
Visa is approaching the reliability problem from the payment-network layer.
Its Intelligent Commerce infrastructure is designed to let agents obtain payment credentials that are:
- tokenized;
- bound to the agent;
- linked to authenticated user instructions;
- subject to transaction controls.
Visa's documentation describes controls that can verify that a transaction came from the intended merchant and for the appropriate amount.
The system can also receive commerce outcome signals after the purchase.
Those signals are important for:
- auditability;
- dispute evidence;
- reconciliation;
- fraud analysis.
Visa Intelligent Commerce Connect broadens this further by positioning itself as a network-, protocol- and token-vault-agnostic integration layer.
This matters because merchants are unlikely to want a completely different checkout integration for every AI agent, card network and token provider.
DN view: Visa's core strength is bringing agent identity and user intent into existing payment infrastructure rather than requiring merchants to replace the entire payment stack.
Visa Intelligent Commerce4. Mastercard Agent Pay: Best for Verifiable Intent and Agent Recognition
Mastercard Agent Pay
Mastercard's Agent Pay framework centers on making the agent visible as a governed participant in the transaction.
Mastercard Agentic Tokens are designed to connect tokenized payment credentials to a specific agent and user.
Its newer Verifiable Intent model adds a second dimension:
not merely who initiated the payment, but what the agent was authorized to do.
Mastercard describes the framework around:
- tokenized credentials;
- user consent;
- agent recognition;
- Payment Passkeys;
- verifiable intent;
- end-to-end auditability.
The company has already reported authenticated agentic transactions in real-world regional pilots.
Mastercard has also expanded into Agent Pay for Machines, targeting rapid, programmatic and even sub-cent machine-to-machine payments.
DN view: Card networks have a major structural advantage because they already operate authentication, dispute and fraud infrastructure at enormous scale. Agent commerce can potentially inherit rather than recreate those systems.
Mastercard Agent Pay5. MPP + Stripe: Best for Usage-Based Machine Commerce
Machine Payments Protocol + Stripe
Machine Payments Protocol addresses a different commerce pattern.
A software agent may not need a cart, shipping address and return policy.
It may need:
- one API request;
- 20 seconds of browser infrastructure;
- 500 model tokens;
- one data enrichment result;
- one digital service.
MPP lets a service respond to a machine request with a payment requirement and lets the client authorize payment programmatically.
Stripe's MPP integration then brings those transactions into existing PaymentIntents infrastructure.
That gives merchants access to familiar capabilities including:
- fraud protection;
- reporting;
- accounting integrations;
- refunds;
- fiat settlement;
- stablecoin payments.
MPP also supports payment sessions, where an agent can authorize spending once and incrementally increase the authorized amount as it consumes a service.
That can dramatically reduce payment overhead for high-frequency usage.
DN view: MPP is not a full replacement for a retail checkout protocol. It is potentially much better suited to machine-native services where the agent is buying consumption rather than a conventional product.
Explore Machine Payments Protocol6. x402: Best Minimal Pay-and-Deliver Protocol for APIs
x402
x402 is deliberately narrower than ACP or UCP.
That is not necessarily a weakness.
For paid APIs and digital resources, simplicity can improve reliability.
A typical x402 flow is:
- agent requests protected resource;
- server returns payment requirements;
- agent signs payment authorization;
- agent retries request with payment proof;
- server verifies and settles;
- resource is returned.
Current x402 infrastructure also supports optional extensions relevant to reliability, including:
- Payment Identifier for idempotency;
- Offer Receipt for signed pre-settlement agreement evidence;
- structured payment response headers;
- service discovery;
- authentication extensions.
The limitation is scope.
x402 by itself does not attempt to model a complete retail lifecycle involving complex carts, delivery choices, fulfillment, returns and customer support.
For software purchasing an API call, that may be exactly the right trade-off.
DN view: reliability improves when a protocol refuses to solve problems the use case does not have.
Explore x402The Reliability Problem: Payment Success Is Not Checkout Success
Imagine an agent purchasing a laptop.
The payment network authorizes $1,500.
At exactly the same moment, the final unit goes out of stock.
Which statement is true?
- The payment succeeded.
- The purchase succeeded.
- The order exists.
- The merchant owes the buyer a laptop.
Those are four different questions.
Agentic commerce systems need to answer all of them consistently.
The Agent Checkout Ambiguity Window
DN defines the Agent Checkout Ambiguity Window as:
the period during which a financially consequential step may have succeeded but the agent cannot yet determine the authoritative resulting state.
Examples include:
- payment authorized but order response times out;
- merchant creates order but agent does not receive confirmation;
- agent retries because it assumes failure;
- payment capture succeeds after the inventory reservation expires;
- refund occurs but agent continues treating the purchase as active.
The ideal ambiguity window approaches zero.
Why Agents Make Duplicate Checkout Risk Worse
Humans usually hesitate after a checkout error.
Software may retry immediately.
That can create:
- duplicate orders;
- duplicate payment authorizations;
- multiple inventory reservations;
- multiple fulfillment instructions;
- repeated API charges.
A robust checkout stack therefore requires either explicit idempotency or a reliable way to retrieve and reconcile existing state before retrying.
Authorization Must Be Bound to What Was Actually Purchased
Traditional payment credentials answer:
Can this payment instrument be charged?
Agentic commerce adds:
Was this agent authorized to charge this instrument for this particular purchase under these conditions?
That is why:
- AP2 binds payment mandates to checkout state;
- Stripe scopes agent payment tokens;
- Visa binds tokenized credentials to agent context and user instructions;
- Mastercard is developing Verifiable Intent.
This is a fundamental architectural change.
The Agent Should Not Calculate the Final Price
An agent can compare offers.
It can negotiate.
It can estimate.
But the merchant should remain authoritative for:
- inventory;
- price;
- tax;
- shipping;
- discounts;
- availability;
- final order total.
Both ACP and UCP reflect this principle.
That helps prevent the model from converting an approximate shopping answer into an incorrect financial transaction.
DN Agent Checkout Reliability Calculator
Model how small failure rates at several stages can compound into meaningful checkout losses at scale.
This calculator models compounding checkout failure probabilities. Inputs are supplied by the user and are not claims about ACP, UCP, Visa, Mastercard, MPP, x402 or any specific provider.
Why Tiny Failure Rates Become Huge at Agent Scale
A human may make ten meaningful online purchases in a month.
A procurement agent might make ten thousand.
A machine agent buying API access may make millions.
At 100 transactions, a 0.1% exception rate is almost invisible.
At 10 million transactions, that same rate produces 10,000 exceptions.
Agentic commerce therefore changes the optimization target.
A flow must not merely work.
It must fail predictably.
DN Agent Checkout Failure Budget
Borrowing from reliability engineering, DN proposes treating checkout errors as a finite operational budget.
For every million agent checkout attempts, businesses should define maximum acceptable:
- session creation failures;
- price or inventory mismatches;
- payment failures;
- ambiguous order states;
- duplicate orders;
- fulfillment-sync failures;
- refund-reconciliation failures.
Once a component consumes too much of that budget, the commerce system should degrade safely rather than continuing unrestricted autonomous purchasing.
Post-Purchase Reliability Is Part of Agentic Commerce
A checkout does not end when payment succeeds.
An agent may later need to:
- track shipping;
- change delivery details;
- cancel an order;
- request a return;
- obtain a refund;
- reconcile a partial shipment;
- handle a subscription renewal;
- update its own accounting records.
Google's UCP order-lifecycle work is particularly interesting here because signed, freshness-aware webhook events move agent commerce beyond the initial purchase.
ACP similarly preserves the merchant as the party responsible for fulfillment, returns, support and customer communication.
Human Present vs Human Not Present
The reliability problem becomes much harder when the user is absent.
| Issue | Human Present | Human Not Present |
|---|---|---|
| Intent clarification | User can correct agent immediately | Intent must be represented in advance |
| Price change | User can accept or reject | Agent needs predefined limits |
| Authentication | User can perform step-up | Credential must support delegated authorization |
| Merchant substitution | User sees change | Policy must specify whether substitution is allowed |
| Failure recovery | User can interpret unusual state | Machine requires deterministic error semantics |
| Dispute evidence | User remembers decision | System needs durable evidence of intent and execution |
The Checkout Reliability Stack
DN views a production-grade autonomous checkout as seven layers.
| Layer | Question | Failure Mode |
|---|---|---|
| Discovery | Is the product information current? | Agent selects stale price or unavailable product |
| Intent | What did the user authorize? | Agent exceeds mandate |
| Checkout State | What is the merchant currently offering? | Stale cart, tax, inventory or shipping |
| Credential | What payment authority was delegated? | Over-broad payment access |
| Payment | Was value actually authorized or moved? | Decline, duplicate, timeout |
| Order State | Did the merchant create the purchase? | Paid but no order, duplicate order |
| Post-Purchase | Did fulfillment remain synchronized? | Agent acts on stale shipment or refund state |
Retail Checkout vs Machine Checkout
One of the most important mistakes in agentic commerce is assuming all purchases need the same protocol.
A shoe purchase needs:
- product selection;
- size;
- shipping;
- tax;
- payment;
- fulfillment;
- returns.
An API request may need only:
- resource;
- price;
- authorization;
- payment;
- response.
ACP and UCP are better suited to rich commerce state.
MPP and x402 can be much cleaner for machine-native resources.
More protocol complexity is not automatically more reliable.
The Commerce Protocols May Converge Rather Than Compete
The emerging stack is increasingly modular.
Google explicitly positions AP2 as a secure payment layer that can operate inside UCP.
UCP can communicate over mechanisms including APIs, MCP and A2A.
Stripe supports ACP while also supporting MPP and x402.
Visa Intelligent Commerce Connect is deliberately network and protocol agnostic.
Mastercard Agent Pay for Machines lists ecosystem participants spanning payment processors, crypto infrastructure and machine-payment platforms.
The likely future may therefore be:
commerce protocol + authorization protocol + payment credential + payment rail + fulfillment system
rather than one standard replacing every other standard.
DN Agent Checkout Reliability Methodology
Version 1.0 evaluates documented architecture and current deployment maturity across seven dimensions.
| Category | Weight | What DN Evaluates |
|---|---|---|
| Checkout State Integrity | 20 | Authoritative session state, retrieval, updates, totals, inventory and completion semantics. |
| Intent & Authorization Integrity | 20 | Whether user authority can be constrained, verified and tied to the actual purchase. |
| Payment Credential Containment | 15 | Tokenization, limits, expiry, merchant binding and exposure of underlying credentials. |
| Duplicate & Retry Safety | 15 | Idempotency, receipts, session retrieval and mechanisms that reduce duplicate purchases. |
| Error & Intervention Semantics | 10 | Structured failures, recoverable versus terminal state and step-up intervention support. |
| Order & Post-Purchase Lifecycle | 10 | Fulfillment, order updates, refunds, outcome signals and durable transaction evidence. |
| Deployment & Interoperability | 10 | Live use, ecosystem integrations, openness and ability to coexist with existing commerce infrastructure. |
Scores are not directly measured uptime or conversion percentages.
Future DN versions should add controlled live checkout probes and publish empirical completion, ambiguity, duplication and recovery measurements.
The Live DN Checkout Test We Want to Build
The next version should execute controlled low-value purchases against reference merchants and services.
The test harness should capture:
- session creation success;
- cart-state accuracy;
- price consistency;
- inventory mismatch;
- credential issuance;
- payment authorization result;
- payment-to-order consistency;
- duplicate retry protection;
- ambiguous completion state;
- order confirmation delay;
- fulfillment update delay;
- refund synchronization;
- end-to-end completion rate.
DN could then publish:
- p50 checkout completion time;
- p95 completion time;
- p99 ambiguity duration;
- duplicate order rate;
- payment-without-order rate;
- order-without-payment rate;
- successful recovery rate.
What Would Prove This Thesis Wrong?
Agentic commerce could remain primarily human-supervised.
If users continue confirming every purchase and merchants simply use AI as a product discovery interface, existing checkout systems may require far less architectural change than expected.
Another possibility is that browser automation improves enough that agents navigate conventional ecommerce reliably without widespread protocol adoption.
Large marketplaces may also internalize discovery, payment and fulfillment so completely that open interoperability standards matter less.
But autonomous commerce becomes much harder to scale if every agent must interpret every merchant's website like a human.
Structured commerce state is likely to become more valuable as the amount of machine purchasing increases.
The Checkout Is Only One Layer
An autonomous transaction also needs a wallet, payment rail and potentially a trading or treasury platform.
Best Wallets for AI Agents 2027 x402 Cost & Reliability Benchmark Best Crypto Platforms for AI AgentsThese related DN decision pages may contain separately disclosed commercial relationships. This reliability index is not ranked according to affiliate economics.
Frequently Asked Questions
What is agentic checkout?
Agentic checkout is a commerce flow in which an AI agent helps create or complete a purchase on behalf of a user. A structured agentic checkout can expose product, checkout, payment and order state through APIs rather than requiring the agent to manipulate a conventional website interface.
What is the most reliable agentic checkout protocol?
Under Version 1.0 of the DN documented-architecture benchmark, Agentic Commerce Protocol combined with Stripe ranks first overall, while UCP combined with AP2 ranks very closely behind and provides particularly strong cryptographic authorization architecture.
What is the difference between ACP and UCP?
ACP defines programmatic commerce interfaces between agents and sellers, including a stateful checkout lifecycle and delegated payment mechanisms. UCP defines a broader modular commerce standard covering checkout, fulfillment, discounts, orders and other capabilities and can incorporate AP2 as a specialized agent-payment authorization layer.
What is AP2?
Agent Payments Protocol is an open protocol for securing agent-performed payments. It defines signed Checkout and Payment Mandates and corresponding receipts that can provide evidence of what an agent was authorized to purchase and pay for.
How can an AI checkout avoid duplicate purchases?
The system should use durable checkout or transaction identifiers, idempotent state-changing operations where supported, and reconcile authoritative checkout or order state before retrying after an ambiguous timeout.
What is Checkout State Certainty?
DN defines Checkout State Certainty as the degree to which all participants can establish the authoritative state of an agent-initiated purchase across intent, checkout, payment, order and fulfillment.
What is the Agent Checkout Ambiguity Window?
DN defines the Agent Checkout Ambiguity Window as the period during which a financially consequential commerce action may have succeeded but the agent does not yet know the authoritative resulting state.
Is x402 a replacement for ACP or UCP?
Not necessarily. x402 is optimized for HTTP-native programmatic payments for APIs, digital resources and autonomous agents. ACP and UCP model richer checkout and commerce lifecycles. Different protocols can coexist or serve different layers.
Primary Sources
- Agentic Commerce Protocol Documentation
- ACP Checkout Specification
- Stripe Agentic Commerce
- Stripe Shared Payment Tokens
- OpenAI: Instant Checkout and Agentic Commerce Protocol
- Google Universal Commerce Protocol
- Google UCP Native Checkout API
- Google UCP Order Lifecycle
- Agent Payments Protocol Specification
- Visa Intelligent Commerce
- Visa Intelligent Commerce Connect
- Mastercard Agentic Commerce and Agent Pay
- Mastercard Agent Pay for Machines
- Stripe and Tempo Machine Payments Protocol
- MPP Payment Sessions
- Coinbase x402 Documentation
- x402 Protocol Features and Extensions
Commercial Disclosure: This benchmark compares agentic commerce protocols and payment infrastructure rather than ranking affiliate partners. No commercial relationship determines protocol inclusion or scoring. Related DN wallet and platform decision pages may contain separately disclosed partner links.
Research Standard: Version 1.0 evaluates publicly documented protocol architecture, controls, lifecycle design and current deployment maturity. DN does not claim independently measured checkout success, conversion, payment authorization, duplication or uptime statistics where live controlled testing has not been performed.
Operational Status: Agentic commerce is changing rapidly. Protocol versions, pilot availability, supported payment methods, merchant access and product capabilities can change. DN intends to update this benchmark when material changes occur.
Disclaimer: Agentic commerce can involve financial, privacy, fraud, software, consumer-protection and operational risk. Nothing on this page constitutes financial, legal, cybersecurity or payments compliance advice.
Recommended reading:
Fastest Crypto Trading APIs 2027: Latency, Rejections & Reliability Ranked
Best Crypto Platforms for AI Agents 2027 | Agentic Finance Rankings
Agentic Wallet Security Index 2027: The Safest Wallets for AI Agents
Best Wallets for AI Agents 2027: Security, Payments & Autonomous Finance
