Buy Via SMS: Text "500g Beans", Reply YES, Done

You run out of coffee on a Tuesday morning. You mean to order more. Ordering more means finding the site, remembering the password, searching the catalogue, re-entering a card. So you do not, and on Thursday you buy some at the supermarket instead.

The merchant did not lose that sale on price or on quality. They lost it to friction they cannot see.

So: text the shop what you want. Get the total back. Reply YES.

you    500g beans
Aiva   500g Ethiopian beans $24.50
       Shipping $6.00
       Total $30.50

       Reply YES to send it, charged to your Visa ending 4242.
you    yes
Aiva   Done. $30.50 charged, order #1042 is on its way.

That is the whole product. It works over SMS, WhatsApp, Messenger and Instagram DM, because it all runs through the one HighLevel conversation thread.

The division of labour, which is the whole safety story

Here is the bit I care about most, and it is the bit that would go wrong if you built this carelessly.

The model picks which product someone meant. That is genuinely hard, "500g beans" to a specific variant id, and it is what language models are good at. It searches the live catalogue with tools and proposes a basket.

The code does everything else. It decides the price. It enforces the limits. It takes the money.

The model never sees a card. It never states a total. And it never decides that a message was a confirmation.

If the model proposes a variant that did not come back from a real catalogue search, that line gets dropped on the floor. Prices always come from our own lookup, never from anything the model said. A hallucinated price is a wrong charge on a real person's card, and there is no version of "the AI got it a bit wrong" that is acceptable when money moves.

YES means yes, exactly once

Confirmation is decided by exact whole-message matching, not by the model. "yes" confirms. "yes but make it 1kg" does not, because that is a change of order and treating it as a confirmation would charge for the wrong thing.

Then there is the harder problem: a webhook gets retried, someone double-taps, a carrier redelivers. Two confirmations arrive for one basket.

Moving a basket from "waiting" to "charging" is a single conditional database update. Two requests race, exactly one wins, and the loser is told the truth rather than charging the card again. There is a test that runs two genuinely concurrent database connections to prove it, because the in-memory test database does not implement the mechanism being tested and would have proved nothing.

The rules that are not negotiable

Every order shows the full total and waits. No silent charges, ever.
A spend cap per order, a spend cap per customer per day, and a limit on how many text orders anyone can place. Enforced our side, every time.
The phone has to already belong to a customer who has checked out normally at least once. A card is never saved off the back of a text message alone.
Replies only ever go to the number that texted in. No endpoint anywhere accepts a destination number from a caller. That last one matters: a form on another site once turned into an open SMS relay because it accepted both the number and the message body, and that is a bill, a phishing vector, and a fast way to lose a SIM.
STOP ends it immediately and permanently, as the Unsolicited Electronic Messages Act requires.

What else falls out of it

Once a shop can take an order by text, a few other things get easy. Aiva already knows roughly how long a bag of beans lasts a given customer, so it can ask before they run out. A customer drifting away can get a text with a one-word reorder instead of an email in a promotions tab. "The usual" works.

Where it is up to

Built, tested, and not yet switched on for anybody. Every merchant starts with it off, and the first pilots go live deliberately rather than by default. When money moves on a text message, "we'll turn it on and see" is not a plan.