3-D Secure & Card Checkout vs AP2, ACP & UCP
EMV 3-D Secure (3DS2) & human browser checkout forms is the classic web primitive built for human browsers and pre-integrated services (Verify cardholder presence during an interactive browser checkout and shift fraud liability), whereas Agent Payments Protocol (AP2) and its step 7 (Pay) peers provide the machine-native agentic surface (none) so autonomous agents can answer: "Did the user actually authorize what this agent is about to buy and pay for, and can the merchant prove it later?" Across the agenticweb.wiki conformance panel, Agent Payments Protocol is multi-implementation (Google (launch blog post, 60+ launch partners)).
How 3-D Secure & Card Checkout compares to AP2, ACP & UCP at step 7 (Pay): why the classic primitive breaks for software agents, and how sites deploy both together.
| Dimension | EMV 3-D Secure (3DS2) & human browser checkout forms Classic web | Agent Payments Protocol AP2 Agentic web |
|---|---|---|
| Primary consumer | Human driving a web browser or pre-integrated developer code | Autonomous software agent, coding harness, or AI search/RAG crawler |
| Lifecycle step | Classic web baseline for step 7 (Pay) | 7 Pay: Settle the bill |
| Core question answered | Verify cardholder presence during an interactive browser checkout and shift fraud liability. | Did the user actually authorize what this agent is about to buy and pay for, and can the merchant prove it later? |
| Wire format & entrypoint | Interactive iframe challenge + session device fingerprinting | endpoint at none |
| Failure mode for agents | Traditional fraud engines flag 'human-not-present' autonomous agent sessions as bot attacks, while sharing raw PANs with an LLM creates severe prompt-injection and unauthorized-spend risk without cryptographic proof of the user's budget. | Solved natively: The Agent Payments Protocol (AP2) is a security and authorization framework for agent-performed payments: it defines how a user's intent to buy something is captured as a cryptographically signed, tamper-evident Mandate that a Merchant, Credential Provider, and Merchant Payment Processor can verify and later present as dispute evidence. |
| Governance & status | Established IETF / W3C / industry baseline | Google; core specification donated to the FIDO Alliance (Payments TWG and Agentic Authentication TWG), 2026-04-28; the google-agentic-commerce/AP2 repository now hosts only samples and an SDK, not the normative spec text — Security/authorization protocol for agent-performed payments; core spec now stewarded by FIDO Alliance |
| Live adoption (/check/ census) | Universal across the classic web | multi-implementation — Google (launch blog post, 60+ launch partners) |
| Primary specification | https://www.emvco.com/emv-technologies/3-d-secure/ | https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/docs/ap2/specification.md |
Why 3-D Secure & Card Checkout breaks when the caller is an agent
Traditional fraud engines flag 'human-not-present' autonomous agent sessions as bot attacks, while sharing raw PANs with an LLM creates severe prompt-injection and unauthorized-spend risk without cryptographic proof of the user's budget.
When to use which (and how they work together)
- Keep EMV 3-D Secure (3DS2) & human browser checkout forms: A human shopper is actively typing into a checkout page in their own web browser.
- Add Agent Payments Protocol (AP2): An AI agent is purchasing on a user's behalf and needs cryptographically signed intent/cart/payment mandates (AP2), delegated payment tokens (OpenAI/Stripe ACP), or structured merchant capability discovery (/.well-known/ucp).
All agentic web standards replacing or extending 3-D Secure & Card Checkout
- Agent Payments Protocol (AP2) — multi-implementation: Did the user actually authorize what this agent is about to buy and pay for, and can the merchant prove it later?
- Agentic Commerce Protocol (ACP) — multi-implementation: How do a buyer's agent and a merchant complete a deterministic, programmatic checkout without the agent becoming the merchant of record?
- Universal Commerce Protocol (UCP) — multi-implementation · 3/574 probed origins: Can an agent discover a business's commerce capabilities, build a cart, and check out interoperably across shopping, lodging, and food ordering?
- EMV Agentic Payments – Framework for Specifications — none found: When a card network, issuer, merchant, or wallet sees an AI-agent-initiated card payment, how do they consistently find out what the consumer actually authorised — recurring purchase, spending cap, post-transaction change — rather than each building a bespoke, one-off signal?
- Visa Trusted Agent Protocol (TAP) — prototype: How does a merchant recognize that an approved commerce agent, rather than a crawler or fraudulent bot, is interacting with its site or API?
- Verifiable Intent (VI) — prototype: After an agent completes a purchase on a user's behalf, can the merchant, issuer and consumer all point to the same cryptographic record of what the user actually authorized?