If your team is being asked which agentic checkout protocol to support, you are being asked to spend engineering time on a channel nobody can size yet. Adobe's Q3 2026 AI Traffic Trends Report puts AI-driven retail traffic up 138% year over year in May 2026 and travel up 194%, with AI-referred retail visitors converting 54% better than non-AI traffic. Those are growth and index figures, not volume figures, and the difference matters more than most coverage admits.
Three specifications with overlapping scope now exist: ACP, UCP and AP2. They are not three options for the same job. Two are checkout protocols; one is a payment authorization layer that sits underneath both. This guide gives you eight criteria, a comparison table, a readiness scorecard and a build order, so you can decide this week instead of waiting for consolidation.
What the three specifications actually are
ACP (Agentic Commerce Protocol) is OpenAI's standard, built with Stripe, and it is what makes a catalog transactable inside ChatGPT. You expose five REST endpoints on a checkout session resource (create, update, complete, cancel, get), each request carrying a fixed header set including Idempotency-Key, Signature and API-Version, currently pinned to 2025-09-12. Payment is delegated: you receive an encrypted token and run authorization and capture on your existing PSP, with Stripe, Adyen and Braintree named in the checkout spec. You also emit order.created and order.updated webhooks so order state survives retries.
UCP (Universal Commerce Protocol) is Google's standard, published on 11 January 2026 with more than 20 endorsing partners including Shopify, Adyen, Stripe, Visa, Mastercard, Walmart, Etsy and Zalando. The shape differs: instead of a fixed endpoint contract, you run a business server and publish a JSON manifest at /.well-known/ucp declaring the services and capabilities you support, which agents discover at runtime. It spans product discovery, checkout sessions, discounts and order management, over plain APIs, Agent2Agent or MCP. Google's Under the Hood post has the manifest structure.
AP2 (Agent Payments Protocol), announced 16 September 2025 and currently at v0.2, is not a checkout protocol at all. It is an authorization and evidence layer built on Verifiable Digital Credentials. The user signs a Checkout Mandate shared with the merchant, open at first to capture constraints and then closed to authorize a finalized cart, plus a Payment Mandate shared with credential providers and processors. The output is a non-repudiable cryptographic trail of who agreed to what. v0.2 covers pull methods, meaning cards; wallets, push rails such as UPI and PIX, and digital currencies are on the roadmap. UCP is documented as AP2-compatible.
Underneath all three sits the card-network layer. Visa's Trusted Agent Protocol, introduced in October 2025, solves a narrower problem: telling a legitimate agent apart from a malicious bot. By Visa's 18 December 2025 update it reported hundreds of completed agent-initiated transactions and 30+ partners building in its Intelligent Commerce sandbox. Mastercard's Agent Pay covers the same ground on its own rails.
The eight criteria that decide the order of work
- Agent reach. Which assistants can transact with you through this today, in your market.
- Build surface. Endpoint contract, capability manifest, or credential handling.
- Money flow. Whether you stay merchant of record and keep your own PSP.
- Discovery. Feed ingestion versus a manifest the agent reads at runtime.
- Rail coverage. Cards only, or wallets and push payments too.
- Dispute evidence. What you can show when a buyer says the agent ordered the wrong thing.
- Platform dependency. Whether your PSP or platform already ships support.
- Regional availability. Whether the consumer surface is live where your customers are.
Comparison table
| Criterion | ACP | UCP | AP2 |
|---|---|---|---|
| Owner and date | OpenAI with Stripe, spec 2025-09-12 | Google plus 20+ partners, 11 Jan 2026 | Google, 16 Sep 2025, v0.2 |
| Agent reach | ChatGPT | Partner agent ecosystem, Shopify distribution | None alone; rides UCP or a custom agent |
| Build surface | 5 REST endpoints, 9 headers, 2 webhooks | Business server plus a /.well-known/ucp manifest | Mandate issuance, signing and verification |
| Money flow | You stay merchant of record, own PSP, delegated token | Your own checkout session and orders | Authorization evidence only, no settlement |
| Discovery | Catalog feed ingested by OpenAI | Runtime capability discovery from the manifest | Not applicable |
| Rail coverage | Whatever your PSP supports | Delegates to AP2 or your PSP | Cards in v0.2; wallets, UPI, PIX on roadmap |
| Dispute evidence | Session log plus PSP record | Order records, plus AP2 if enabled | Strongest: signed, non-repudiable mandates |
| Build effort, relative | Medium, well bounded | Medium, larger surface | Low alone, high if you build the signing yourself |
Readiness scorecard: what to build first
Score your store out of 10. Two points for each yes.
- Your PSP already ships an ACP or UCP integration you can switch on rather than write.
- Your feed is complete enough that an agent could pick the right variant without the page.
- Your checkout can accept a third-party payment token with no human in the browser.
- You have a reconciliation path for orders created outside your front end.
- Legal and finance have signed off on orders arriving with no session on your domain.
At 8 to 10, pick the protocol your PSP supports and pilot it on one category. At 4 to 6, fix the feed and the token-acceptance path first; the protocol work is the small part. At 0 to 2, do nothing protocol-shaped yet: make the catalog machine-readable, instrument agent traffic, revisit in a quarter.
The ordering rule we use: ACP first if a meaningful share of your assisted traffic already comes from ChatGPT, because the contract is fixed and small. UCP first if you are on Shopify or an Adyen or Stripe stack where the manifest is largely generated for you, or if you sell across several markets and want capability negotiation rather than one hard-coded flow. AP2 never first, and never skipped if you sell anything disputable at volume, because it is the only one of the three producing evidence a bank will accept.
The payment and regulation layer you cannot skip in Europe or Turkey
None of these protocols creates a legal basis for an agent to spend someone's money. In the EU, agent-initiated payments stay inside PSD2 and the SCA requirements of Delegated Regulation (EU) 2018/389. As Osborne Clarke noted on 6 March 2026, there is no standalone regime; the open questions are who provides the payment service, who controls the funds, and what counts as valid authorization of payee, amount and timing.
The practical route is the existing exemptions. A 21 September 2026 analysis argues the trusted-beneficiary exemption fits best: SCA applies when the payer creates or changes the trusted-payee list, not on every later transaction, which maps onto authenticating at the moment of mandate rather than per order. The low-value exemption is narrower than it looks, at under EUR 30 per transaction, EUR 100 cumulative and no more than five consecutive unauthenticated payments.
In Turkey, the relevant change is on the onboarding side. An amendment to the Payment Services and Electronic Money Issuance Regulation, in the Official Gazette of 4 September 2026 (No. 33360), rewrote Article 41(4) to allow remote framework contracts to be established using biometric methods or electronic identity documents with authentication capability: NFC-readable Turkish ID cards or ICAO 9303 passports. The conditions are strict, including explicit consent under Law 6698, liveness detection, and no substituting the handset's own unlock for the institution's own system. It took effect on publication, with no transition period. The transferable point: the identity step for agentic payment credentials is regulated locally even where the checkout protocol is global, so your protocol choice does not settle your enrollment flow.
Where this breaks down
Four limits. First, nobody can tell you the revenue. The Adobe report publishes growth rates and index comparisons against non-AI traffic, not AI-sourced traffic as a share of total visits, so any article quoting a flat percentage of e-commerce traffic is not sourcing it there. Treat the relative numbers as evidence the channel converts well when it arrives, not as a volume forecast. [INTERNAL DATA NEEDED: observed AI-assistant referral share and conversion delta across Switas e-commerce and travel accounts, Q2 to Q3 2026]
Second, the specs are moving. AP2 is v0.2, UCP carries a dated version string, ACP's API version is pinned to a date. Anything you build gets a maintenance line.
Third, consumer-surface availability by country is the hardest variable to verify publicly, and it decides whether the work pays off this year. Confirm it with your PSP before scoping.
Fourth, the regulatory reading above is legal commentary, not a regulator's ruling. Treat it as the argument your payments counsel will make, not as clearance. [INTERNAL DATA NEEDED: developer-days for a five-endpoint ACP integration, from a Switas implementation]
FAQ
Does ACP make OpenAI the merchant of record?
No. The checkout spec has you accept a delegated, encrypted payment token and run authorization and capture on your own rails with your own PSP. You stay the merchant of record and keep the customer relationship and the chargeback.
Is UCP just Google's version of ACP?
They overlap, but the design differs. ACP defines a fixed endpoint contract. UCP has you declare capabilities in a manifest at /.well-known/ucp that agents read at runtime: more flexible, and a larger surface to build and test.
Where does AP2 fit if I already support ACP?
Underneath, as the authorization and evidence layer. AP2 does not move money or run a checkout; it produces signed mandates showing what the user agreed to. UCP is documented as AP2-compatible, so that pairing is the intended one.
Can an AI agent legally complete a card payment in the EU?
Only within PSD2 and its SCA rules, which were not written for an absent payer. The workable paths today are the existing exemptions, principally trusted beneficiaries and, narrowly, low-value transactions. Have payments counsel review this, not your protocol vendor.
Do I need a new product feed for any of this?
You need a better one. ACP ingests your catalog, and UCP agents read your capabilities at runtime. Either way the agent decides without visiting the page, so missing variant attributes, stock state and shipping terms become abandoned agent carts you never see.
How do I measure whether this is working?
Separate agent-referred sessions from agent-completed orders. Session-level attribution tells you about visibility; order-level tells you about the protocol. Track them as two funnels, because a store can surface well in assistants and still fail at the checkout handoff.
If you want this scored rather than read, run the five-item readiness scorecard against your own catalog and checkout, or have us run it and come back with a build order and the feed gaps that would block it.
Sources
- Adobe, Q3 2026 AI Traffic Trends Report
- OpenAI, Agentic Checkout Spec
- OpenAI, Agentic Commerce Protocol overview
- Google, Under the Hood: Universal Commerce Protocol
- Agent Payments Protocol (AP2) specification, v0.2
- Visa, Visa and Partners Complete Secure AI Transactions
- Mastercard, tools and collaborations for agentic commerce
- Osborne Clarke, Agentic payments and Europe's payments ecosystem
- fin-law, Does SCA really prevent agentic payments?
- Payment Services Regulation amendment, Official Gazette 4 September 2026, No. 33360
