The further AI agents are evolving, the clearer it gets: they are quickly becoming the new interface for the internet. Through a chat or voice interface, agents can now scroll websites, scrape content, fetch data, call APIs and use various tools and services using protocols like MCP.
One future implication of this, is that a big chunk of the internet will be compiled into the agentic chat layer. Everything becomes headless. We’ve already explored this trend in The Great GUI Overhaul.
With regards to commerce, it also has massive implications. OpenAI is working on integrating checkout directly into ChatGPT by Q3 2025, and Perplexity is already doing it in their Pro offering, so now you can buy products directly from chat. This is both exciting and unsettling for merchants. On one hand, it’s a huge new distribution channel - ChatGPT has over a billion users (the fastest growing consumer app in history). On the other, the merchant’s entire brand gets compressed into the chatbot interface, which they do not control, with the risk of losing a lot of their e-commerce super powers like their brand, cross-selling and up-selling, promotions and user loyalty.
Historically, merchants hate being dependent on one platform. That’s why there’s been so much pushback from merchants against Amazon over the years (just some recent examples: here and here). Shopify was built as the alternative - Tobi Lütke even historically liked saying Shopify are “arming the rebels” against Amazon. It gave small merchants a way to own their store and their future. We’re about to hit the same dilemma again. Agentic checkout is coming, and every merchant will need to decide how to stay in control.
We think there’s a path forward. If done right, headless commerce opens up a big opportunity. In this post, we’ll go deeper into what that looks like, and specifically how merchants can build new headless workflows for agentic commerce that will keep them in control.
But let’s start with some definitions first.
What is headless commerce?
Headless commerce is an e-commerce architecture where the frontend (what users see) is decoupled from the backend (commerce logic). Developers can use APIs to build custom user interfaces. A headless store is basically a set of APIs that let developers build third-party commerce experiences based on a merchant’s catalog.
Historically, headless commerce was used for things like omnichannel selling. It allowed the same backend to power additional websites or mobile apps, in addition to the main merchant store.
A few examples for headless commerce infrastructure:
Shopify built the Storefront API to make this possible for every merchant to create his own storefront, or to power third party applications
Walmart’s developer portal offers different APIs for marketplace partners, suppliers, and more.
Best Buy’s API lets you query products, stores, categories, and more.
Headless commerce was also part of another trend that didn’t really take off to date - social commerce. Things like Facebook Shops (introduced in 2020), TikTok Shops (introduced in 2023) and a wave of startups tried to bring checkout into third-party social apps, blending social and commerce experiences. The trend didn’t succeed (at least in the West, in China it is pretty hot), and there’s still debate on why.
There’s some debate around why this hasn’t worked before, but we believe it comes down to two main reasons:
Platforms like Shopify have no real incentive to become fully abstracted as backend and let other apps control the user journey and much of the e-commerce assets like promotions, cross-sell etc.
Merchants want to keep control and own the customer relationship, so they are not very inclined to give permission to a third-party.
So why would this time be any different?
If these are the reasons headless / social / third-party commerce didn’t take off before, what’s changed? To answer that, let’s look at one place where third-party commerce did work: Amazon.
About a third of U.S. merchants using Amazon use it only as a storefront. Fulfillment is still handled by the merchant. So Amazon, for them, is just a third-party sales channel. It’s not 100% what we’d call “headless commerce” – merchants still register and list their stores on Amazon – but it’s pretty close in business principles.
Why did Amazon succeed where others have failed?
Two words: market power.
Amazon’s dominance created a dynamic where, if you’re not on Amazon, you basically don’t exist for a big part of the market. That created a pull dynamic – merchants come to Amazon – instead of a push dynamic where a third party needs to convince each merchant to give access to their store.
If this reminds you of something, you’re not wrong. ChatGPT market power feels like the same power that can create a pull demand the same like Amazon did. OpenAI are today listing merchants in the same dynamic that reminds us of the beginning of the centralized commerce over the internet (i.e. “register with us or you don’t exist”).
The merchant’s prisoner’s dilemma
Assume ChatGPT creates a strong enough merchant network effect – like Amazon – powered by its massive, unmatched user base. What does that mean for merchants?
They’re stuck in a dilemma. They can either play along and risk ChatGPT controlling a growing share of traffic to their store, while keeping their original experience intact.
Or…
Open their headless store infrastructure to other third parties as well, letting go of some control but reducing dependence on a single aggregator.
Time to arm the rebels again
To avoid completely recentralizing commerce around one or two aggregators, merchants will likely need to open their headless stores to some third parties. They need to become the rebels again. In many cases, most of the required components already exist in some form. But some areas will need a bit of tweaking. Let’s start with a more technical look at what’s needed for these workflows to work.
4 API groups to rule them all
We think about four core groups of APIs that define the commerce experience:
/catalog – Search for products from this merchant, including pictures, metadata etc.
/cart – Start and manage a stateful session. You can add and remove items, come back later, and pick up where you left off. A session could be authenticated or not (i.e. the user logs-in through the merchant, or as a guest checkout). We believe both workflows should exist.
/checkout – Assuming the cart is filled and a user sees the total amount to pay (including shipping and tax),
/post-order – Track shipping, order status, disputes, and any follow-up endpoints.
For many big merchants, most of the required APIs already exist. But one key family that’s either missing or not functional enough to agentic workflows is /checkout.
Checkout APIs, where they exist today, usually create a URL redirect into a GUI-based checkout page. That’s a problem for a few reasons:
It breaks the unified experience we want - like ChatGPT, where you enter payment credentials and a shipping address once, and “Buy” just works across any merchant.
It pulls users off the platform with redirects, adding extra clicks and creating UX fatigue. Instead of a one-click buy, it becomes a long and convoluted flow. That will likely hurt conversion.
It requires a different checkout flow for each merchant integration, harming the agent unified UX.
And maybe most importantly: it blocks future use cases like autonomous payments - when the user isn’t present at all (we’ve written a lot about that).
To solve this, we need a small tweak in how payment flows work. Merchants will need to open a checkout endpoint that can receive payment credentials - like network tokens. These tokens (e.g. Visa’s Intelligence Commerce agentic token) are scoped per transaction and much safer to transfer. They reduce the security burden and make the flow compatible with agent-based or autonomous systems.
🔁 Full Agent Flow
Search:
Agent calls /catalog with search term
→ displays product options
Add to Cart:
Agent calls /cart with product ID, receives cart_id
→ sends shipping info
→ receives updated cart with tax + shipping
Buy:
Agent calls /checkout with cart_id and agent-scoped payment_token
→ receives order confirmation
Track Order:
Agent calls /post-order with order_id
→ shows shipping status to user
GUI consistency
Another key issue with headless commerce is losing control over how the store looks. A reckless agent developer might display the catalog or inventory the wrong way, mess up the layout, or misrepresent the brand. And many brands are extremely sensitive to how they appear in third-party contexts.
This is already being addressed with new standards like MCP-UI - a format that lets agents present buttons and UI components in a standardized way, combining chat interfaces with real-time interactive elements.
We think this is the right direction for commerce agents: blending text with structured UI like buttons.
It’s still early, but standards like MCP-UI are an important step toward giving merchants more control over how their brand shows up in third-party platforms -without losing the benefits of headless architecture.
Summary
AI agents are becoming the main interface for the internet. Instead of clicking around websites, people are starting to use chat layers to get things done. ChatGPT and Perplexity already let users buy products directly from chat, no storefront needed.
This changes how commerce works. Merchant brands get compressed into third-party interfaces they don’t control. You lose the ability to upsell, build loyalty, or shape the experience. It’s a lot like what happened with Amazon - power shifts to the aggregator, and merchants lose leverage.
To avoid that, merchants need to open up their headless checkout in a controlled way. Done right, this gives you reach without giving up control - and can actually increase GMV.
That’s why we think headless checkout matters more this time. Most merchants already have the right APIs for catalog, cart, and post-order. What’s missing is proper checkout: no more redirect flows, just clean, token-based payments that work with agents.
If you’re building a commerce agent and want to embed payments, reach us to out to founders@nekuda.ai for access to the nekuda sdk.
And if you want to learn more about agentic payments, be sure to subscribe to get the most updated analysis of how agents will pay.
Very well thought out! I am skeptical of MCP-UI right now though. Feels like with MCP we had an opportunity for an Internet of APIs with an opportunity to standardize contracts. By adding UI it will muddy the waters again. Merchants already have a plethora of Web UIs and Mobile UIs to support and now to add MCP-UI too? The argument makes sense but I think this solution risks converging on a browser with built-in chat. Still its great to push the industry forward towards agentic commerce!