The short answer
Most AI shopping demos work on stage and fail in your kitchen. The reason isn't the model. It's that checkout was built to keep automated buyers out, and an agent driving a browser with a stored card looks exactly like the thing it was built to keep out.
The agents that pay reliably don't fight that. They pay as a card, not as a bot; they use the merchant's structured paths where they exist; and when a merchant insists on a human, they prepare everything and ask for one tap.
Why checkout is hostile to agents
Three walls, in the order an agent hits them.
Bot detection. Retailers lose money to scalpers and scrapers, so they invest in telling humans from scripts: browser fingerprinting, behavioral signals, CAPTCHAs. An agent puppeting a browser trips these constantly. The bigger the merchant, the better the wall.
3-D Secure. In Europe, PSD2's strong customer authentication means the card issuer can — and for unfamiliar card-not-present payments usually will — ask the cardholder to confirm in their banking app. An agent can't do that on your behalf, and shouldn't be able to. That's the point of the rule.
Re-pricing. Flights and hotels in particular change price and availability between the moment the agent quotes you and the moment it tries to pay. The agent gets a different number mid-flow and either fails or, worse, pays the new one.
A fourth, quieter wall: the stored card. Most agents pay with a card number the person pasted in. That number now lives in a prompt, a log, a context window. Whatever the checkout outcome, that's a bad place for a PAN to be.
Three ways an agent can pay
1. Structured checkout. Some merchants expose checkout as an API or a protocol rather than a web form. The Agentic Commerce Protocol from OpenAI and Stripe is the largest example: over a million Shopify merchants reachable for agent checkout, with a structured cart, no CAPTCHA and no browser puppetry (OpenAI/Stripe, 2026). Where this exists, the agent uses it. It's the closest thing to a clean path.
2. Card-on-file and repeat purchase. Subscriptions, top-ups, reorders. After the first authorization the merchant holds a credential and 3-D Secure is usually not re-triggered. "Reorder the same thing" and "keep this paid" are the most reliable agent purchases there are — unglamorous, high-frequency, and they work.
3. Recognized-agent checkout. The card networks have published protocols for a merchant to recognize a legitimate agent rather than block it: Visa's Trusted Agent Protocol and Intelligent Commerce, Mastercard's Agent Pay and its agentic tokens. The mechanism is that the agent presents a signed, network-issued credential at checkout, so the merchant's fraud stack sees a known agent with a known cardholder behind it — not an anonymous script. An agent whose card was issued to it, as a token, by a card issuer that can participate in these schemes, is the natural fit. Whether a given issuer participates is that issuer's claim to make.
Everything else — browser puppetry with a stored card — is the fourth way, and it's the one that gets blocked.
3-D Secure, honestly
You'll see products imply their agent "handles" 3-D Secure. Be suspicious. Strong customer authentication exists precisely so that software can't confirm a payment on a human's behalf. Any agent that "passes" 3DS is either operating where 3DS didn't fire (card-on-file, low-value exemption, a non-European issuer) or doing something your bank would like to know about.
The honest design: the agent does the ninety percent — search, compare, fill in passenger details, choose the fare, prepare the payment on its card — and when the merchant asks for 3-D Secure, it hands you the last tap. You confirm in the chat. The agent completes the purchase and puts the receipt in the ledger.
That's a worse demo than "the AI booked my flight while I slept". It's also the one that doesn't produce a story about the AI booking the wrong date.
The card the agent is holding
What the agent pays with decides most of the above.
A stored card number is the worst option: it sits in the model's context, it's your main card, and every purchase looks like an unfamiliar CNP transaction to your issuer.
A debit card issued to the agent as a network token changes three things. The number never enters the conversation — the agent holds a token, the PAN stays in the issuer's vault. The card is rule-bound at authorization: merchant allowlist, per-purchase ceiling, daily velocity, category, country — checked by the issuer before the charge is approved, so a leaked token runs into the same wall. And because the card was issued to the agent by an issuer, it can carry the agent's identity into the recognized-agent protocols above, rather than pretending to be you.
The same card carries subscriptions and card-on-file. That's what makes "cancel anything I haven't used" a real action: the agent issued the card, so it can decline the next charge at authorization rather than asking the merchant nicely.
The airline problem
Airlines are the hardest case and the most popular demo, which is a bad combination. They run the most aggressive bot detection in retail, step up 3DS on nearly everything, re-price between search and payment, and need passenger data the agent has to get right. A failed airline booking is a public, emotional failure in a way a failed €9 top-up is not.
So: hotels through card-on-file merchants, reorders, subscriptions and structured-checkout retailers first. Flights as "the agent prepares, you tap" — until recognized-agent checkout is live at that airline, and only then as an unattended purchase.
What good looks like
An agent that buys outcomes, not websites. Ask for the thing you want, with a merchant, an amount and a date. The agent uses the cleanest path that merchant offers, pays with a card that was issued to it and checked against your rules, hands you 3-D Secure when a merchant insists, and writes down why it did what it did. When a merchant blocks it outright, it says so and gives you the last step — instead of a screenshot of a CAPTCHA.