Everything You Wanted to Know About How Agents Will Handle Checkouts

TL;DR: 

Agents can already checkout with today’s card rails by riding the same flows human users use: manual form fill, merchant-stored cards, Apple/Google Pay, and one-click wallet; 

Current checkout methods work but come with friction: legal gray areas, CAPTCHAs and anti-bot hurdles, plus PCI rules.

Fully agent-friendly payment APIs will take time. Until then, lightweight overlays help agents navigate existing checkouts more easily.

We like to constantly remind ourselves our agentic payment thesis:

1. Agent-driven transactions will generate significant commerce volumes across the internet.

2. Current payment rails aren’t built for this and create friction.

We’ve written a lot about why this shift is happening and what it means—like rethinking the GUI layer of the internet or how we think about cybersecurity.

But in this post we want to zoom in on the actual checkout flow - the bits and bytes of it, and lay out a mental model for what agentic checkout looks like, plus what is needed. This becomes more important as agents start using payment methods more often, and the underlying rails will need to catch up.

Important to note a core assumption we make - we assume the primary way agents will pay online is through credit cards and existing card networks. There are other candidates—like stablecoins—but credit cards are the most practical option right now, for a few reasons:

1. They’re already widely distributed—most people around the world have a credit card, and are used to paying with them.

2. They work with nearly every online commerce system today.

3. They come with an embedded identity and reputation layer—your identity is tied to the card, and you can delegate that to your agent.

4. They have built-in dispute resolution through chargebacks.

All of this means agents can start using user credit cards with minimal changes to existing online commerce infrastructure —basically ready out of the box to charge the first dollar.

That said, there are still new challenges—mainly around how agents behave during checkout (we wrote about the authorization problem here). But we currently just want to address the technicalities around how can they go through a checkout.

Agentic Payment Routes

There are two main ways agents will eventually pay online using credit cards —for ecommerce, travel, and other services.

1. Human Checkout Paths - Using existing flows like guest checkout or merchant-stored cards. No need to change APIs, but it does require either UI automation (e.g. filling the card credentials by the agent in the forms and clicking ‘buy’) or using a human-authenticated identity that already has stored payment credentials (we’ll explain that in a second). This is probably how agents will handle checkouts in the short term—it already exists and just needs mild tweaks to current systems, not a full overhaul.

2. New Dedicated APIs Built for Agents - These are purpose-built payment endpoints. Clean, machine-readable, no UI—just API calls. In this case the agent will be able to send an API call with payment credentials or some other payment form like network tokens to a dedicated endpoint and initiate a payment. This will probably be combined with a checkout process beforehand, i.e. the agent filled a cart using APIs, and now only need to call a PayNow() endpoint. But most importantly - that’s not how most payments work on the internet today. In fact, it’s rare to find payment APIs where you can simply send credentials and pay, or call a OrderNow() type of endpoint where credentials are already stored. There are exceptions, like TikTok Shops, which integrate directly into Shopify (you can buy on TikTok directly from a Shopify store, with payment APIs under the hood). But the broader trend has been the opposite: platforms closing down open payment APIs and moving toward walled gardens. Shopify did this with their affiliate program, for example.

   Without going to deep into the history here, the reason is that most merchants and platforms want users to buy directly from their UI. That’s why this agent-native path is still underdeveloped. It’s where things are headed long term, but we’re not there yet. It’ll take time, standardization, and adoption. That’s why this post is more focused on the human checkout paths—they’re available today.

Human Checkout Paths

Existing checkout paths vary in how they use payment credentials and authentication methods, but the underlying principle is always the same: send the payment credentials to the appropriate parties and authenticate ownership of the card.

When agents try to use these paths, each one brings its own set of challenges and potential failure points. Let’s break down the different paths—and the UX flows they rely on.

Manual Card Entry

This is the most basic way human users pay online today: type in card number, expiry, CVV, and click “Buy.”

From an agent perspective, automating this comes with a few major challenges:

• Any software that handles raw card data needs to be PCI compliant (costly and time consuming).

• Captchas and anti-bot protections are everywhere.

• CVC can’t be stored permanently, so human-in-the-loop is often required to type it in —making fully autonomous use cases hard.

This is still the most straightforward path for agents to pay on the internet today (we wrote about browser agents and their payment capabilities here), but it also comes with the most friction.

Stored Cards

There are many flavors of this—users storing their card with a merchant directly, or with a third-party like Stripe (e.g. Stripe Link). In this case, if the user is already authenticated, they can just click “Pay” and it works. If not, they need to authenticate—using a password, passkey, OTP, or another login flow.

This flow is much smoother post-authentication. The catch is that agent authentication isn’t standardized yet. Startups like Arcade are trying to solve this, but it’s still early. Which means that services and merchants that authenticate, authenticate the user and not the agent. When it comes to payments, this leads to what we call the authorization problem (we wrote more about it here).

The short version: it becomes easy for agents to buy things—maybe too easy.

There’s often no clear mandate or authorization process tied back to the user, the card issuer, or the network. That creates risk: unauthorized charges, accidental purchases, no real traceability. Solving this requires better authorization infrastructure.

Network Tokens / One-Click Pay

UX-wise, this feels a lot like stored cards. The user authenticates once, then clicks “Buy”. Under the hood, it’s based on network-issued tokens (e.g. Apple Pay, Click-to-Pay). But it generally a form of stored payment credentials that requires authentication. It shares the same core challenges around agent authentication and user auth.

Can Agents Use This Payment Routes?

The short answer: technically yes.

Agents might run into captchas or anti-bot measures, but those can be handled.

With the right setup, you can automate checkouts—both for guest checkout and stored credentials.

The long answer: an agent can pay with your card today, but only by squeezing through gaps that were never meant for AIs. Three big land-mines remain:

1. Legal grey zones – Card rules say someone you trust may use your card, but they never defined an AI. If a purchase goes wrong, banks might call it “unauthorized” and claw the money back.

2. Security hurdles – CAPTCHAs, 3-D Secure codes, device fingerprints. Agents can fake being human only up to a point; one strange signal and the checkout stalls.

3. Compliance overhead – Storing or even touching card data drags you into PCI-DSS audits and network registration paperwork. Few teams are ready for that.

We expect the first step toward payment-ready agents will be layering on top of existing payment rails—adding overlays that make today’s checkout flows more agent-friendly and less brittle by existing card networks, PSPs and card issuers.

Summary

Agents will drive real GMV, yet card rails create drag.

• Two paths forward:

  1. Human checkout rails (guest form, stored card, Apple/Google Pay) → works now, but CAPTCHAs, 3-DS, PCI.

  2. Agent-native APIs → clean, but scarce and walled-garden.

• Biggest blockers: legal gray area, bot detection, PCI overhead.

• Near term fix: existing players like card networks are probably going to support overlays that supports using existing checkout routes.

• Table below maps each method by who stores the card, how you prove identity, and the friction it adds.

If you’re building agents and want to give them payment capabilities, we can help. Feel free to reach out here or through Substack here: