Regardless of how credentials are issued or stored, merchants today face an unavoidable reality: there are two ways credentials can reach a merchant in a transaction flow.
1. Front-end scraping and autofill
Or
2. Direct backend communication.
That distinction matters more than it might appear, as it will shape how agentic commerce evolves, who controls it (or blocks it), and which merchants ultimately prevail.
Front-end scraping and autofill
Before we dive into front-end token delivery through an autofill-like UX, let's discuss some key terms to understand throughout this process.
First, DTVV stands for Dynamic Token Verification Value. A DTVV is a short cryptogram that replaces the 3-digit CVV on a debit or credit card. Think of a DTVV as a replacement for the CVV. Note that a DTTV has historically required network approval. When an agent or consumer initiates a checkout flow, the presence of a valid DTVV signals to the network that a token-based payment credential can be safely surfaced to the merchant. In practice, this enables payment tokens to be delivered directly into front-end checkout experiences without exposing the underlying card number.
What actually happens next:
- If the merchant's checkout UI forwards the DTVV into a PSP-controlled iframe, many PSPs will reject it outright, since the value doesn't match expected CVV/PAN semantics.
- Some PSPs attempt to “convert” the network token into a PSP-specific token (a token-on-token flow). When the PSP is not authorized to perform this conversion, it can result in hard errors or, more problematically, silent failures.
- Many PSP iframes and hosted fields are PAN-only by design and will simply refuse non-PAN formats, including network tokens accompanied by a DTVV.
- Front-end delivery only works reliably if the merchant captures the token outside the PSP iframe and routes it explicitly, rather than relying on PSP-controlled fields to ingest or interpret the value.
Front-end delivery works only if the merchant can capture the token outside the PSP iframe and route it explicitly.
Why the Front End Is Winning (For Now)
Front-end scraping and autofill already power a meaningful share of online transactions. They work well for many credential types, but not all.
Network token-based credentials, for example, introduce an added constraint: they typically require short-lived cryptograms to function securely. That added complexity makes them harder to support universally through the front end alone.
And yet, despite those limitations, front-end approaches are likely to dominate the early phase of agentic commerce.
Why?
Because networks and AI platforms are in a race. Each wants to enable agent-driven transactions faster and at greater scale than their competitors. Front-end implementations are simply quicker to deploy, require less coordination, and can be rolled out without waiting for merchants to build bespoke integrations.
Speed wins early markets.
A Familiar Pattern: Lessons From Open Banking
We've seen this movie before.
Plaid didn't become an open-banking API powerhouse by starting with pristine, bank-approved integrations. It started with scraping. By pushing massive transaction volume through front-end connections, Plaid forced banks into a decision: resist and break customer experiences, or formalize access through secure APIs.
Banks chose APIs.
History doesn't repeat itself, but it does rhyme.
Direct Backend Communication
A second model is receiving credentials directly through backend integrations problem?
Most merchants don't have the infrastructure to support this yet, won't build it soon, and may struggle to version, secure, and maintain this kind of real-time credential ingestion.
Back-end retrieval offers more control and fewer PSP constraints, but requires engineering investment.
From Agentic Front Ends to Backend APIs
The same arc is likely to play out in agentic commerce.
As merchants begin to see real revenue flowing through AI-driven transactions, tolerance for opaque front-end scraping will decline. Reliability, security, data ownership, and economics will become increasingly important. That's when we'll see a new wave of backend API integrations emerge that are purpose-built for agentic platforms.
If that happens, it may mark the beginning of the end for traditional merchant checkout pages as the primary point of conversion.
Commerce won't disappear; it will relocate.
Are you a merchant seeking more information on agentic commerce?
Check out our latest guide.
Learn More
Control Follows Integration
Merchants who proactively enable backend integrations will have something far more valuable than early access: leverage.
Backend integrations:
- Give merchants visibility into how transactions are initiated
- Provide control over credential usage and routing
- Create negotiating power with AI platforms
- Reduce dependency on brittle front-end workflows
The tradeoff, of course, is effort. These integrations generally require real development work. But the payoff is ownership of the experience, the economics, and the customer relationship.
The Platform Reality
While the ecosystem appears fragmented today, most indicators suggest that consolidation is underway.
In commerce, there are rarely dozens of dominant platforms. More often, there are a few. The prevailing belief is that a small set of high-volume AI platforms will account for the majority of agentic transactions.
For merchants, that means the integration burden may be lighter than expected. Supporting two or three platforms could be enough to capture most of the agentic commerce channel.
The Bigger Picture
Front-end scraping will unlock the first wave of agentic commerce. Backend APIs will define the second.
Merchants who wait may still participate, but on someone else's terms. Merchants who prepare will help shape the standards, economics, and future of how AI transacts on the internet.
The question isn't if this shift happens.
It's who will be ready when it does.
