← Blog
September 10, 2026 · 11 min

Adyen Agentic: auditing the protocol translation layer

Three open agentic commerce protocols and at least one proprietary surface now compete for the machine checkout. Adyen's answer, announced in June and in limited availability since, is to sell merchants a way out of choosing. This post audits the universal-translator play — what it has to translate, what is actually verifiable, and what an aggregation layer means for agents that pay.

We have spent months taking these protocols apart one at a time. OpenAI and Stripe's ACP bundles checkout and payment into a delegated token. Google's AP2 turns human authorization into signed mandates. UCP defines the commerce conversation and leaves the rail pluggable. Each dissection ended with the same caveat: a merchant reading along still has to guess which one wins.

Adyen's bet is that the guess itself is the product opportunity. On June 16, 2026 the company announced Adyen Agentic, a three-layer API suite positioned, in its own words, as a universal translator: integrate once with Adyen, and the merchant's catalog, checkout and payments become reachable through the Universal Commerce Protocol, OpenAI's Agentic Commerce Protocol, Google's Agent Payments Protocol, and Meta's AI checkout. Karan Katyal, Adyen's Global Head of Agentic Commerce, framed the problem plainly: "Every new agentic surface asks merchants to rebuild from scratch."

That framing is accurate. Whether a proprietary translation layer is the right fix is the more interesting question, and it matters directly to anyone building autonomous buyers.

Why translation became a product

The fragmentation is real and recent. ACP shipped with ChatGPT's Instant Checkout on September 29, 2025. AP2 was announced on September 16, 2025 with sixty-plus partners — Adyen among them — and reached v0.2 in April 2026 before being donated to the FIDO Alliance. UCP arrived on January 11, 2026 from Google and Shopify, published under Apache 2.0. Meta runs its own AI checkout without a published open spec. Four surfaces, four integration contracts, in under five months.

Then the market delivered its first correction. In early March 2026 OpenAI discontinued Instant Checkout, the in-chat buy button that ACP was built to power, after reporting indicated only around a dozen Shopify merchants had integrated it. The protocol survived the product: ChatGPT still uses ACP to let third-party merchant apps operate inside its interface, but purchases now complete on the merchant's own surface rather than through OpenAI's one-click flow.

That episode is the strongest argument for the translator thesis. A merchant who bet their 2025 roadmap on in-chat checkout via ACP got a strategy reversal five months later. Surfaces churn on product-management timescales; protocols churn slower; a merchant integration has to survive both. Adyen is selling insulation from exactly that churn — and its partner list for the launch (American Express, Mastercard, Salesforce, Visa, plus retailers ESW, Scheels, Sézane and SharkNinja) shows the incumbent payment stack lining up behind the hedge rather than behind any single protocol.

The three layers, and what each must translate

Adyen Agentic splits into three modular APIs: Agentic Feed, Agentic Cart, and Agentic Payments. The names sound like marketing, but they map cleanly onto the three genuinely hard translation problems in this space. It is worth walking each one, because the difficulty gradient tells you where the moat is.

Feed is the easy layer. Every agentic surface wants machine-readable catalog, price and availability data, and each defines its own shape: UCP has catalog.search and catalog.lookup capabilities with schemas anchored at ucp.dev, ACP defines a product feed spec, Meta wants its own format. Translating between catalog schemas is classic feed management — Adyen's pitch of "a single product feed that automatically adapts to each AI platform's requirements" is a solved category of problem, just tedious. Low moat.

Cart is where state machines collide. A UCP checkout is a session object negotiated capability-by-capability: the business publishes a profile at /.well-known/ucp, the platform advertises its own through a UCP-Agent header, and the checkout session carries live pricing, tax and fulfillment state through a defined lifecycle. ACP's checkout is a different lifecycle with different objects, designed for a platform that mediates the whole flow. A translator has to hold one internal cart representation and project it into each protocol's state machine without the projections drifting — same tax result, same discount application, same inventory reservation, on every surface simultaneously. When the projections disagree, the agent sees a price change between quote and settle. This is real engineering, and it is invisible until it fails.

Payments is where the translator earns its margin. The three open protocols made incompatible choices about how payment credentials move. ACP's model is the Shared Payment Token — Stripe's delegated credential, scoped to a checkout, which we covered in our ACP audit. AP2's model is the mandate chain: intent, cart and payment mandates as verifiable credentials proving what the human authorized. UCP refuses to pick: payment is a pluggable slot filled by Payment Handler specifications, with an ap2_mandate capability among the core set. Adyen's press release names the exact primitives a translator needs here: token portability — one stored credential usable across protocol frontends — and merchant-of-record preservation, meaning the merchant keeps the liability, the customer relationship and the acquiring relationship regardless of which agent surface originated the order. Both depend on being a payment company already holding the tokens and the acquiring licenses. High moat, and not a coincidence that a PSP is the one building it.

There is a fourth translation problem the layer diagram does not name: agent verification. The product page promises to "distinguish between a legitimate AI agent and a bot, using a risk engine trained on trillions of transactions." Today that determination is where the ecosystem is least standardized — Visa's Trusted Agent Protocol signs agent traffic with HTTP message signatures, Cloudflare pushes Web Bot Auth, AP2 binds authorization to mandates, and none of them interoperate yet. A translator that absorbs this problem makes its risk engine the de facto admission policy for agents across every surface it fronts. That is a lot of unilateral power in an unpublished algorithm.

The audit: what you can verify today

Our audits usually end in a spec repo. This one ends at a login wall, and the contrast is the finding.

The open protocols are inspectable to the commit. UCP's repository shows roughly 3,400 stars, 458 forks, and — more telling — 96 open issues and 93 open pull requests against 282 commits on main: heavy inbound pressure on a young spec, with shopping the only vertical fully specified and lodging and food still marked as coming soon. AP2's repository shows around 3,200 stars and 497 forks, with a Python SDK of Pydantic models and JSON schemas plus samples in Python, Go and Android. ACP is published under Apache 2.0 at agenticcommerce.dev, with REST and MCP integration patterns — and its merchant discovery mechanism still explicitly listed as in development.

Adyen Agentic, by contrast, is in limited availability for US enterprise merchants only. No pricing has been disclosed. The product page points to technical documentation on docs.adyen.com, but when we checked on September 10, 2026, the agentic-commerce documentation path returned a 404 — the integration contract is not publicly inspectable at all. There are no published schemas for how Adyen's internal cart representation projects into UCP sessions or ACP checkouts, no stated conformance targets against protocol versions, and no visibility into the agent-verification policy.

The asymmetry — every protocol Adyen translates is open enough to audit line by line. The translation itself is the one link in the chain you cannot read. For a merchant that is a convenience trade-off. For an autonomous agent on the other side of the counter, it is an unobservable intermediary deciding whether you are "legitimate."

Aggregation is a position, not a neutral act

Payments history says the translator play works. Payment service providers exist because merchants did not want to integrate each card network, local rail and fraud stack separately; Adyen built a large business being that single integration. Reading the agentic protocol war as the same fragmentation pattern is the obvious move for a PSP, and the launch partners suggest the card networks see it the same way — better a translator that preserves the card-centric merchant-of-record model than an open protocol that makes the rail pluggable.

But aggregation changes the thing it aggregates. If enough enterprise merchants reach the agentic surfaces only through translators, then protocol evolution starts routing around merchants entirely: the working groups negotiate with three PSPs instead of ten thousand integrators, and features that translators cannot or will not project — say, a stablecoin payment handler — quietly fail to reach the merchant side regardless of what the spec allows. UCP's most interesting design decision, the permissionless payment-handler slot we analyzed in July, only matters if the parties terminating UCP sessions actually expose handler diversity. A translator whose margin lives in card processing has no incentive to.

That is where this intersects the rail we care about. Nothing in Adyen's announcement mentions stablecoins or x402. AP2 — which Adyen supports — carries an x402 extension for crypto settlement, and UCP can express it as a handler. Whether those paths stay reachable through the translation layer, or get flattened into card tokens because that is what the translator's Payments layer speaks natively, will decide whether agentic commerce inherits the open rail properties of x402 or just re-skins the acquiring stack for machines.

What it means for LLM4Agents

LLM4Agents sits on the buyer side: agents funded in stablecoins that pay per call through an OpenAI-compatible gateway. A merchant-side translation layer affects us three ways.

First, it changes who our agents negotiate with. When an agent walks a UCP flow against an enterprise merchant, the counterparty terminating the session is increasingly a PSP's translation layer, not the merchant's own stack. Conformance bugs, version lag and policy decisions will originate there. Our checkout tooling should record which implementation terminated each protocol session — the same fingerprinting discipline we already apply to x402 facilitators — so failures are attributable.

Second, agent verification consolidating into PSP risk engines raises the stakes on portable agent identity. If one unpublished classifier decides whether our agents are "legitimate" across thousands of merchants, then investment in verifiable identity — signed requests, mandate chains, onchain registries — is not optional hygiene; it is the only lever an agent operator has against opaque rejection. Everything we have argued in the identity series applies with more force, not less.

Third, the translator's blind spot is our opening. Adyen's layer preserves the card-centric model by design. Machine-to-machine services that settle in stablecoins over x402 do not pass through it at all — no card token to port, no merchant of record to preserve. The deeper enterprise commerce burrows into proprietary translation, the clearer the differentiation of a rail where the protocol, the settlement and the receipts are all inspectable end to end.

Staying on the frontier

Concrete steps, in order:

  1. Track UCP termination in the wild. Instrument our agent SDK to log which stack terminates each UCP and ACP session (headers, capability profiles, schema versions), building an empirical map of where translators sit between agents and merchants.
  2. Test against the open reference implementations, not the aggregator. Adyen's contract is not public; the UCP and AP2 repos are. Conformance for our checkout flows should target the spec repos, with translator quirks handled as documented deviations when we encounter them.
  3. Ship verifiable agent identity on every commerce request. Signed HTTP requests plus AP2-style mandate references, so that when a PSP risk engine classifies our traffic, there is cryptographic material on the wire arguing for legitimacy rather than heuristics alone.
  4. Watch for an Adyen developer-docs release. The day docs.adyen.com stops returning 404 for agentic commerce, audit the contract the way we audited the protocols — object schemas, version pinning, and whether any non-card payment handler survives translation.
  5. Keep the x402 path independent. Ensure our merchant-side tooling exposes x402 alongside any UCP payment handler, so services selling to agents never depend on a translation layer's roadmap to get paid in stablecoins.

Build agents that pay on open rails

One gateway, 345+ models, stablecoin billing per call — no translation layer between your agent and settlement.

Register your agent