Why a 'yes' in a chat should never be enough to buy something

Picture a simple exchange. Your shopping assistant says: "I found the trainers in your size for £89. Shall I buy them?" You reply: "yes".

It feels natural, and for a lot of products it would probably turn out fine. But that one word is carrying an enormous amount of weight. Which trainers? At what price, if it has changed in the last hour? Delivered where? Paid with which card? And was it really you who typed it?

At OTTR we decided early that a reply in a chat would never, on its own, buy anything. This article explains why, and what we do instead.

The problem with conversational consent

Chat is a wonderful way to describe what you want. It is a poor way to authorise a payment, for several reasons.

Words are ambiguous

"Yes" might mean "yes, buy it", "yes, I can see it" or "yes to the second option, not the first". "Go for it" might refer to a message three replies ago. People skim, reply quickly and assume context. A language model can misread intent just as a person can.

Context drifts

Between the moment an option is shown and the moment you reply, things change. Prices move, stock sells out, delivery estimates slip. A chat reply cannot tell you whether the thing you agreed to is still the thing on offer.

Chat accounts are not strong identity

Messaging accounts are shared on family tablets, left signed in on laptops, and occasionally taken over through SIM swaps or stolen devices. A message arriving from your number is good evidence that the message came from your phone. It is weak evidence that you, specifically, intended to spend money.

Instructions can be smuggled in

AI assistants read content from the web: product pages, reviews, descriptions. That content can contain text designed to manipulate an assistant. If a model's interpretation of a chat could trigger a payment directly, the system's safety would depend entirely on the model never being fooled.

What Ottr does instead

When you decide to buy something, Ottr prepares the purchase and sends you a link to a secure approval page. Nothing is charged at that point. The approval itself has several properties, each closing one of the gaps above.

1. The link is short-lived and single use

Each approval link lasts 15 minutes and works once. We store only a keyed hash of it, never the link itself, so it cannot be recovered from our database. Asking for a new link replaces the old one.

2. Holding the link is not enough

Opening the page requires the signed-in OTTR session of the customer the purchase belongs to. If someone else sees the link, perhaps on a shared screen or in a forwarded message, it is of no use to them.

3. You see the exact terms

The page shows the item, quantity, retailer, total price including delivery, currency, delivery address and the card that will be charged. You confirm explicitly on that page.

4. Approval is bound to those terms

When the approval is requested, we compute a fingerprint of the exact terms: who you are, the purchase, the retailer, the amount, the currency, the address and the card. When you approve, we check the fingerprint again. If anything has changed, the approval is void.

5. The live price is re-checked

At the moment of approval, Ottr checks the current price and stock with the retailer. If the price has moved or the item has sold out, you are told plainly, nothing is charged, and you can ask Ottr to prepare it again.

6. Extra checks when the risk is higher

Risk rules look at things like the value of the purchase and how many purchases have been made recently. When they call for it, you are asked to confirm with a passkey, or to sign in again if you signed in a while ago. Some purchases are blocked outright during this early stage. Each decision is recorded.

Where Strong Customer Authentication fits

In the UK and Europe, Strong Customer Authentication (SCA) requires many online card payments to be confirmed with two independent factors, such as something you have and something you know or are. Your bank usually runs this through 3-D Secure, the familiar confirmation in your banking app.

Ottr funds a purchase while you are on the approval page for exactly this reason: if your bank wants to run 3-D Secure, you are there to complete it. SCA is the bank's check that the payment is genuine. Ottr's approval is our check that the purchase is exactly what you meant. The two work together rather than replacing each other.

Why not just ask the model to be careful?

It is tempting to solve all this with instructions: "Only buy when the user clearly confirms." The trouble is that instructions are probabilistic and payments are not. We prefer boundaries that hold even if the model makes a mistake:

• Ottr's agent has no tool that approves or pays. It can only request an approval link.
• The parts of the system that agents can reach have no route to card issuing or funding. Automated tests check this boundary.
• The same rule applies to other AI agents using our platform. They can prepare a purchase, but only the customer can approve it. See Agent-to-agent commerce.

Does this add friction?

A little, deliberately, and only at the moment that matters. Everything before approval stays conversational: describing what you want, comparing options, changing your mind. The approval page is a single, clear step, and on a phone with a passkey it takes seconds.

We think that is the right trade. The cost of one tap is small. The cost of a purchase you did not intend, or one made at a different price, is not.

Status

OTTR is in development. Approvals work as described here today, while funding, card issuing and checkout run in sandbox against a test merchant. The single-use virtual card that completes each purchase is described in Single-use virtual cards.

The takeaway

Conversation is how you tell Ottr what you want. Approval is how you tell it you mean it. Keeping those separate, with approval bound to the exact terms, protected by your own session and re-checked at the last moment, is what lets an AI assistant act for you without acting instead of you.

To see the whole flow, try Ottr in sandbox. Developers building their own agents can see the same approval model on our page for AI agents.