Adyen Agentic Names Tax as a Layer and Preserves the Merchant of Record. Neither One Decides Who Collects.

On June 16, 2026 Adyen announced Adyen Agentic, a suite of modular APIs it calls "the universal translator for the next era of commerce." It lets an enterprise sell through conversational AI platforms without rebuilding its commerce stack for each new channel. The product ships in three layers: Agentic Feed, which distributes real-time catalog, pricing, and availability data into agent environments; Agentic Cart, which connects a merchant's existing checkout, tax, fulfillment, and order-management systems to those platforms; and Agentic Payments, which handles authentication, token portability, merchant-of-record preservation, and fraud across protocols. It launched in limited availability for U.S. enterprise merchants, with American Express, Mastercard, Salesforce, and Visa named as strategic partners and ESW, Scheels, Sézane, and SharkNinja as early retailers.

Two things in that announcement are worth more attention than the rest, and they are exactly the two the tax world has been waiting for someone in payments to say out loud. Adyen names tax as a named layer in the agentic stack. And it makes an explicit choice to keep the merchant — not the agent platform — as the merchant of record. Both are progress. Neither, on its own, answers the question a state revenue department will ask: who had the duty to collect.

Give Adyen the credit it has earned

We have spent the spring writing about agent payment rails that move money beautifully and say nothing about tax. Mastercard's Agent Pay for Machines settles across cards, banks, and stablecoins and computes no tax. Nevermined's Visa-on-x402 card rail put agents on production card credentials and left the tax layer untouched. That is not a knock on either; payment networks have never calculated sales tax, and the merchant's point-of-sale system has always carried that job.

Adyen Agentic is the first of these stacks to put "tax" in the architecture diagram. Agentic Cart is explicitly described as the layer that connects a merchant's existing checkout, tax, fulfillment, and order-management systems into the conversational channel. That is the correct design instinct. The tax determination should be made by tax logic the merchant already owns, sourced to the buyer, and then carried into the new channel — not invented inside the payment leg, and not skipped because the sale arrived through a chatbot. After a season of rails that erased the tax signal, a stack that preserves a path to the merchant's existing tax engine is the right shape.

"Connects your tax system" is only as good as the system it connects to

The caution rides in the same sentence. Agentic Cart connects to the merchant's existing tax logic. If that logic was built for a web checkout where the buyer typed a shipping address, it computes tax from facts the agentic channel may deliver differently or not at all. The taxable event in agent-mediated commerce is the same underlying sale — what was bought, by whom, delivered where — but the sourcing inputs now arrive through an AI intermediary that the merchant's tax engine was never told about.

The most consequential of those inputs is buyer location. Sales and use tax is sourced, in most states, to where the buyer takes delivery or receipt. When a conversational platform sits between the merchant and the end customer, the merchant has to be certain its tax step is sourcing to the actual buyer's jurisdiction, not to the platform's, not to a default, and not to wherever the agent infrastructure happens to terminate. An integration layer can faithfully pass through whatever the merchant's tax system returns; it cannot fix a sourcing assumption the merchant's system makes on bad inputs. "We connected your tax system" and "your tax is correct in this channel" are different claims, and only the first one is Adyen's to make.

Merchant-of-record preservation is real, and it is not a facilitator determination

The more interesting line is in Agentic Payments: merchant-of-record preservation. The design keeps the merchant, rather than the agent platform, as the merchant of record. Adyen is candid about why this matters — it governs data, chargebacks, and the customer relationship. Those are genuine, valuable consequences. A merchant that stays the merchant of record keeps its customer, its dispute posture, and its transaction data instead of ceding them to an intermediary. If you sell through agents, you want this.

What it is not is a determination of who must collect sales tax. "Merchant of record" is a commercial and contractual designation about which party stands as the seller for card-network and settlement purposes. Sales tax collection responsibility is a statutory question, and in the agent context it runs through marketplace facilitator law. Forty-six jurisdictions — forty-five states and the District of Columbia — have marketplace facilitator statutes that shift the duty to collect from the underlying seller to the platform that facilitates the sale. Those statutes turn on functional tests: did the platform facilitate the listing or sale, and did it process or collect the payment. They do not turn on which party a payments provider has labeled the merchant of record in its contracts.

That gap is the whole point. A merchant can be preserved as the merchant of record by its PSP and still find that a state reads the agent platform as a marketplace facilitator on the statutory facts — because the platform surfaced the listing, brokered the transaction, and sat in the payment flow. Conversely, an agent platform that believes it is a neutral conduit may meet a facilitator definition it never intended to trigger. The contractual MoR badge and the statutory facilitator status are decided by different decision-makers under different tests, and they can point in different directions for the same transaction. Whether a given agent platform is a facilitator under a given state's law is a genuinely unsettled question that no state has squarely answered for AI-mediated sales, and I am not going to pretend the label settles it. It does not.

What operators should do

If you are enabling Adyen Agentic as a merchant, or building an agent platform that plugs into it, the launch is a reason to make the tax determination deliberately, not to treat it as handled because the stack now names it.

• Confirm the tax step sources to the buyer, in this channel. Verify that the existing tax logic Agentic Cart connects to is receiving the real buyer jurisdiction from the agentic flow and sourcing to it — not to a platform default. A pass-through layer faithfully passes through a wrong answer too.

• Do not read merchant-of-record preservation as a collection-responsibility answer. It governs chargebacks, data, and the customer relationship. Decide your sales tax collection duty separately, on the marketplace facilitator facts of each state where you have buyers.

• Resolve platform role before volume arrives. If you are the agent platform, determine whether you facilitate the sale and process payment under each state's definition; if you are the merchant, do not assume the platform is collecting on your behalf unless it has told you so and is registered to do it. Two parties each assuming the other collects is how a state ends up assessing both.

• Keep your own sourcing and transaction records. Settlement data built to be auditor-readable is also auditor-discoverable. The record that protects you is the one that shows what was sold, to whom, sourced where.

Adyen Agentic is the most tax-aware agent commerce stack a major payments company has shipped, and naming tax as a layer while preserving the merchant of record is the right architecture for an agent economy that has mostly ignored both. But an integration layer that connects your tax system does not vouch for your tax answer, and a payments designation that keeps you the merchant of record does not decide who a state will hold responsible for collecting. Those determinations still have to be made from the transaction, against each state's law, before the agent-driven volume shows up. The per-jurisdiction mechanics for agent and machine payments are mapped in our machine-to-machine payment tax reference, and the sourcing rules for agent-mediated sales are in our x402 tax compliance reference.

We built the layer that makes the determination — classify the sale, source it to the buyer, and answer the same way whether the order arrived through a checkout page or an AI agent.

Start calculating tax on agent-mediated sales with AgentTax

This analysis is for informational purposes only and does not constitute legal or tax advice. Consult a licensed tax professional for compliance decisions.