WhatsApp AI agents for commerce: send objects, not paragraphs

A WhatsApp AI agent sells and supports well when it answers with WhatsApp's own commerce objects (a product list, a cart, a Flow, a Review and pay checkout, an order status update) and every product, price and link inside them comes from your catalog, payment gateway and order system. The model decides which object to send and when. Your systems fill it in.

That split was always the safer design. Since 1 October 2026 it's also the cheaper one. Meta now bills service messages, the free-form replies a business sends inside the 24-hour customer-service window, per delivered message once a number's monthly free tier runs out. An agent that describes five shoes in five texts pays for five messages, then waits for the customer to type "the blue one, size 9".

This post covers the commerce loop inside an open conversation: browse, choose, cart, pay, track. Templates, the service window and opt-outs are in our WhatsApp launch guide; calls and other channels are in omnichannel AI agents explained; the fundamentals are in the complete guide to AI voice agents.

Why paragraphs lose on WhatsApp

A text-only agent lets a shopper down in three ways at once.

• Cost. Every reply is a message. A description, a sizing question, a summary and "shall I send the link?" are four billable messages where one product message would have done.
• Accuracy. A price or product code the model types is one it can get wrong. On a call, a wrong figure gets corrected. In a chat, it gets screenshotted.
• Friction. Text makes the customer scroll back, compare, type a choice and type an address. Each typed step is a place to drop off.

WhatsApp already has objects that remove that work. A customer can open a product, add it to a cart and send the cart, or fill in a form without leaving the chat.

In some markets, India and Brazil among them, Meta's payments feature lets them review an order and pay in the thread. The agent's job is to put the right object in front of the customer at the right moment.

Match the object to the moment

This is the map we use when setting up a commerce agent. Each moment has one object that beats text, and one source that has to fill it.

1. The customer is vague ("something for my dad, he runs"). Ask one narrowing question with reply buttons (Meta allows three) or a list (up to ten rows). Filled from: your instructions. Watch: one question per message, not a questionnaire.
2. The customer names a need. Search the catalog, then send a single-product message for one clear match or a multi-product message for a shortlist (up to 30 products, grouped into sections). If they just want to browse, send the catalog itself. Filled from: the catalog search. Watch: show what's in stock now.
3. The customer sends a cart. The agent reads it as an order (each product ID, quantity and price as sent) and confirms it in one line. Filled from: the cart. Watch: prices or stock that changed since the list went out, so re-check the items before checkout.
4. You need structured details such as a delivery address and slot. Send a WhatsApp Flow: one message, several fields, and questions that appear only when an earlier answer calls for them. Filled from: a form you designed. Watch: ask only what this order needs.
5. The customer is ready to pay. Where WhatsApp checkout is set up, send an order with a Review and pay button. Otherwise send a pay button that opens your gateway's payment page. Filled from: your payment gateway, never the model. Watch: the amount (see the payment loop below).
6. After payment, and for "where is my order?". Send order status updates in the thread. Filled from: your order system. Watch: once the 24-hour window has closed, updates need an approved utility template.

Two of these steps cost the business nothing. A cart is the customer's message, and Meta doesn't charge businesses for messages from users. A submitted Flow comes back the same way. So a Flow that collects five details replaces up to five question-and-answer rounds, each of which would have been a billable reply.

The model picks, your systems fill

Most vendor demos show a product carousel. The question worth asking is where the product IDs, prices and links inside it come from. In a Callaro agent the platform enforces the answer; it isn't left to the prompt.

• Products come from a lookup. The agent searches the connected catalog by product name or ID and can send only product IDs from that search or from what the business gave it. An invented ID, or one the customer typed, is refused, and the agent has to search again. In a product message, WhatsApp draws the name, picture and price from your catalog, so the agent never writes them.
• Links are fetched fresh. A link must come from this turn's tool results or from data the business supplied. The agent's own earlier messages don't count: a link from three messages ago may be out of date or already used. The agent is told to call the tool again and send the exact link it returns.
• Amounts are quoted, not recalled. The platform creates the payment on your gateway and sets its reference. For in-chat checkout, each line's amount must be a figure a tool returned that turn or one the customer wrote. The words above a pay button are rebuilt from the payment's own amount, because of a failure we've seen: a correct pay button under a sentence quoting the wrong bill.
• References and contact cards come from your data. An order status update needs an order reference your systems supplied. A contact card carries only a name and number from the instructions or a tool.

The objects on offer are worked out each turn, not fixed in the prompt: only while free-form messages are allowed, only in kinds the connection can deliver, and only with the catalog, form, checkout or gateway they need connected. You can switch kinds off per agent. If a provider can't show an object, it's rewritten so the customer still gets the words, the choices and the link.

One detail matters at volume: a rich reply is the agent's whole reply. Sending a product list ends the turn without another model round, so it costs no more model calls than a text answer.

Worked example: one sale, counted in messages

The sale below is made up; each step is real platform behaviour. A shopper writes: "Do you have trail running shoes in size 9?" Business-sent messages are numbered in brackets.

1. The agent searches the catalog and replies with a multi-product message of the trail models in stock. (1)
2. The shopper opens two, adds one to the cart and sends it. (Customer message, no charge.)
3. The agent confirms the item and sends a delivery Flow: address, postcode, preferred slot. (2)
4. The shopper submits the Flow. (Customer message, no charge.)
5. The agent sends the order with a Review and pay button, built from the cart. (3)
6. The payment is captured. The agent thanks them, and the platform moves the order to "processing" in the thread. (4 and 5)

In text only, the same sale takes three product descriptions, a sizes answer, separate questions for address, postcode and slot, a summary, a payment link and a confirmation: ten business messages before any "sorry, which one did you mean?" turns. Objects need roughly half, with fewer places for the shopper to wander off.

To run the same check on your own traffic:

• Meta cost per order ≈ business-sent messages per order × your market's service-message rate, once the free tier is used.
• AI cost per order ≈ model turns per order × tokens per turn × your model's token rate.
• Method: pull a week of transcripts, count business-sent messages per completed order, switch the busiest moments to objects, and count again.

Meta publishes its rates on its WhatsApp pricing page; Callaro's side is on our pricing page. Of all the inputs, the message count is the one you control.

The payment loop: where WhatsApp commerce breaks quietly

Most checkout bugs never show up in a demo. They show up when a customer pays twice, pays the wrong amount, or pays while still on a call. These are the rules we run.

• Only the payment provider decides that money arrived. Until your gateway, or WhatsApp's own payment update, reports it, the agent is told never to say a payment went through. When the report lands, the agent gets a turn to reply in the customer's language.
• A wrong amount is held, not celebrated. If the amount paid doesn't match the request, it's recorded as a mismatch with a note for your team, and the customer isn't thanked for a payment that doesn't add up.
• One payment, one link. Ask for the same payment twice in a short span (same customer, amount and currency) and the same link comes back, so a retried turn or a customer who asks on a call and again in the chat can't end up holding two payable links. Two payments that share only an amount, say an instalment and a late fee, stay separate because their purposes differ.
• Duplicates are closed. If two links for one payment were opened anyway, paying one cancels the other at the gateway. A second payment that still gets through is flagged for your team to refund.
• The order moves on its own. When an in-chat checkout is paid, the platform moves the order to "processing". For WhatsApp's native checkout, Meta requires order updates to go as order status messages, not plain text.
• A live call hears it too. If the customer pays while on a call with your agent, the call is told and can say so aloud.

One rule from Meta belongs with your finance team: for in-chat payments, don't rely on the WhatsApp status update alone. Reconcile against your gateway account, because WhatsApp doesn't reconcile payments for you.

Support is the other half of commerce

Every sale creates post-purchase questions, and the same objects answer them.

• "Where is my order?" The WhatsApp number already identifies the customer, so the agent can look up their orders through your order API instead of asking for an order number. If you switch on identity verification for the agent, account details wait until the customer passes the check.
• Returns. The agent confirms which order and why, then books the pickup or exchange through your tools. A photo sent with no words goes to a person by default (configurable per channel), because a picture of a damaged parcel usually needs judgement.
• Hand-off. A person takes over the thread in the shared inbox, history in view, and hands it back to the AI once it's settled.

For the voice side of retail (cart-recovery calls, cash-on-delivery confirmation, returns by phone), see voice AI for e-commerce and retail.

When WhatsApp commerce isn't the answer

• Catalogs built for filtering. A product message shows at most 30 items. If shoppers narrow thousands of products by size, colour and fit, a link to a filtered page on your site will often beat a list in the chat.
• High-consideration purchases. For a car, a home or an insurance policy, the chat can qualify and book, but the close usually happens on a call. Let the customer ask for one from the chat rather than pushing them to checkout.
• A single FAQ number. If you only need answers to common questions on one number, with no catalog, payments or calls behind it, Meta's own Business Agent (billed on tokens since 1 August 2026) or a simple bot may be enough. A platform agent earns its keep when the loop runs across your catalog, gateway, order system and phone line.

Launch checklist for WhatsApp commerce

• Catalog: connected in Meta's Commerce Manager, with product IDs that match your own SKUs, so a cart maps straight onto your order system.
• Product names: written the way customers ask ("trail running shoe", not only a model code), since the agent's catalog search runs on names and IDs.
• Provider: confirmed for commerce messages. A direct Cloud API connection or 360dialog carries Meta's full set; some providers carry fewer.
• Flow: built around the details most orders need (usually delivery), with a live data endpoint only if the form needs live data such as open slots, as Meta itself advises.
• Payments: in-chat checkout where it's available, or a gateway connected for pay links, with a maximum amount per link.
• Bad paths: tested on a real phone. Change the cart, abandon checkout, pay a link twice in a sandbox, let a link expire.
• Metrics: business-sent messages per completed order, cart-to-paid rate, and hand-offs per hundred orders.

The takeaway

Treat the model as the shop assistant who knows which shelf to point at, and your catalog, gateway and order system as the shelves. When your data fills every product, amount and pay button, the agent can't offer something outside your catalog or ask for an amount your systems didn't set, and each sale takes fewer messages, which now shows up on every bill.

See what the WhatsApp agent includes, or check current pricing for your volumes.