Why AI agents keep stopping at checkout

An agent can research a product, compare twelve offers, read the reviews, decide, and put the right thing in a cart. Then it stops and asks you for a card. Every AI agents checkout flow ends in the same place: a human, in the middle of an automated process, doing the one step nobody automated.

I watched this happen hundreds of times. Not in a dashboard: on a screen, next to people who had just told me the thing worked.

The day I understood it was not an intelligence problem

I was building Celeste, an AI browser. It was good: the agent could open pages, follow instructions, compare options, complete research. Then it reached the payment step, and the task ended. Not because the agent got the answer wrong. Because the last screen assumed a person.

That was the useful finding. The abandonment was not a failure of comprehension, it was a handoff. The agent had done the hard part and could not cross the last metre, and every workflow that ended there had been technically completed and practically abandoned. I wrote the first version of this argument in the money layer for AI agents, and this piece is the part of it that is about checkout specifically.

Three gaps, and only one of them is a payments problem

• Identity. Checkout is built for a person with a card: a name, an address, a device, a session. An agent has none of those in a form the page accepts, so it borrows a human's credentials and inherits all of that human's authority.
• State. A checkout is a small state machine with a step that is genuinely unknown for a while: the payment is authorised, or pending, or declined, and the page has to be asked again. Agents retry. Retrying something that was pending is how you get two orders.
• Authority. Whoever holds the card holds the authority. So you cannot give the card to the agent, which means the human comes back at the exact moment the automation was supposed to remove them.

The first two are engineering. The third is the reason adding a checkout API to your product does not fix the problem: it moves the handoff one layer down, and the layer below is still a card.

The difference between a timeout and a decline

This is the detail I did not appreciate until I was inside it. A decline is an answer. A timeout is not an answer: it is the absence of one, and the difference matters more when the client is software that will retry.

An agent that treats a timeout as a failure retries. An agent that retries a payment whose state is unknown creates a duplicate, and duplicates are not a performance problem, they are a money problem. This is the same class of bug as idempotency for autonomous agents, with a worse blast radius because nobody is watching the second charge happen.

The answer in our engine is that the retry is keyed on the intention rather than the request. Same intention, same decision, one charge, and the second request returns the first decision instead of making a new one. It is tested with 100 parallel identical requests, and exactly one decision comes out. Boring, and the only version of this I would let near a real card.

The merchant is looking at the wrong thing

There is a second checkout, and only one of the two parties has been thinking about it. The merchant's checkout is built to answer one question: is this a fraudster or a customer? The signals it uses are all human signals. A device fingerprint, a shipping address that has history, a typing rhythm, a browsing session that took four minutes instead of four milliseconds.

An agent fails all of those checks while being completely legitimate. So the merchant sees something that looks like fraud and is actually a customer who automated the boring part, and the honest options on the table are all bad: decline a real sale, or loosen the check that protects everyone else. A merchant verification layer is in build on our side for exactly this reason, and I would rather describe it as in build than imply it is answering questions it has not been asked yet.

What has to exist instead

• A mandate with a perimeter. Amount, period, payees, categories, written before the agent starts.
• A deterministic decision. No model in the authorization path. The same input gives the same answer, every time, on any machine.
• An idempotent execution. The retry is part of the design, not an edge case handled by luck.
• A receipt with the reasoning. What was bought, under which rule, and why the decision came out that way.

I have been building this into Noesia: scoped capabilities that expire instead of a wallet an agent holds, and an append-only ledger behind every decision. The audit that covers the authorization core is commissioned and its findings are fixed with regression tests in the suite, which is why the phrase about being safe with money is not one I use loosely here.

What is still open

Revocation, honestly. Pausing an agent and cancelling the requests it already has in flight is designed, not shipped, and the hard part is not the button, it is what happens between the pause and the last decision already taken. Dispute handling is the same shape of problem and it is in the same state.

The other open thing is a number I refuse to publish: how long a revocation takes to reach an agent mid-flight. I have a target. A target is not a measurement, and the difference is exactly the thing this site is supposed to be careful about.

The end of a workflow is the whole workflow. An agent that stops one step before the outcome did not save you the task, it moved the task to you and added a conversation. Checkout is not the last screen of the product. It is the first place where the product has to answer for what it did.