A shopper types “do you have this in medium?” and the chat answers, shows the variant, and puts it in their cart. No leaving the page, no hunting through a dropdown. That’s the feature people mean when they ask about a WooCommerce chatbot that can add to cart, and it’s the one I get asked about most.
The boundary belongs in the same breath: it fills the cart, it doesn’t take money. When the shopper is ready it hands them to your normal WooCommerce checkout, and everything about payment, tax, and fraud stays exactly where WooCommerce already put it.
Here’s how the flow actually works, including the parts that are less obvious than the demo.
The flow, end to end
Take that conversation properly. A shopper is on a product page and asks: “do you have this in medium?”
The model searches your catalog. sohaychat-wc/search-catalog runs against your real products and comes back with matches. Results render as product cards — photo, price, stock, an Add to cart button — rather than a paragraph describing them.
It pulls the product’s detail. sohaychat-wc/get-product returns that one product including its variation axes: Size, Colour, whatever you’ve configured.
It adds the right variation. sohaychat-wc/update-cart takes the parent product_id plus an options list naming each axis — {name: "Size", value: "Medium"}. WooCommerce resolves which variation that is.
That third step has a rule in it worth stating plainly, because it’s a deliberate safety design rather than an implementation detail. A variation ID on its own is rejected. The model can only add a variant by naming the options in the customer’s own words, and if it sends an ID and options that disagree, the options win. If the shopper hasn’t said which size they want, the model is instructed to ask rather than pick one — and when a product needs a choice, the result comes back carrying the option matrix, so the shopper gets a picker to tap instead of a guess to correct.
The reasoning is simple enough. A number is unverifiable. If a model hallucinates variation_id: 4412, nothing downstream can tell that wasn’t the medium the customer asked for. “Size: Medium” can be checked against the real product. So the checkable thing is the one that’s required.
The cart comes back as a card. Line items, subtotal, discount, shipping, total, and a checkout link, with the money values formatted by WooCommerce in your store’s own currency.
Why the prices and stock are always right
Every price, stock status, and variant is read from your store at the moment it’s asked. Not from the model’s memory, not from a nightly export.
This matters more on the write path than the read path. WooCommerce’s set_quantity() doesn’t check stock — it returns success and leaves enforcement until the cart or checkout renders. A chatbot built on it naively would happily confirm “added 40 to your cart” and let the shopper discover the problem two screens later. So stock is validated before the mutation, using the product’s own check, which correctly accounts for products that don’t manage stock and for backorders you’ve allowed.
If it can’t be done, it’s rejected with a reason the shopper can read — “Not enough stock for the requested quantity” — rather than silently half-done. And operations are attempted independently: ask to add three things where one is out of stock, and the two that work go in while the third comes back with its reason attached.
Every cart change has an Undo
Each cart mutation renders with an Undo button. It’s worth being precise about what that button does, because it isn’t a transactional rollback.
Undo writes the reversal into the chat composer as plain language — “Remove 1 × Mug from my cart.” — and you review it and press send. The reversal runs as a normal request, through the same validation as any other.
That design falls out of one judgement: a cart write shouldn’t need a confirmation dialog, because the shopper’s own sentence is the confirmation. Adding a “are you sure?” step to every “yes, add it” would make the whole thing tedious. But a model that misreads “the blue one” shouldn’t cost someone a wrong order either, so the escape hatch is one click and the reversal is always visible before it runs.
In the admin Conversations inbox, where you’re reading a past conversation rather than driving a live one, the Undo button is hidden and Add to cart is disabled. A historical snapshot shouldn’t offer buttons that would act on your own cart.
The seven tools, and what each one is for
Six commerce tools plus the Knowledge Base lookup that works on any site.
| Tool | What it does |
|---|---|
sohaychat-wc/search-catalog | Search and browse — “waterproof jackets under $100”, “what’s on sale?” |
sohaychat-wc/lookup-catalog | Catalog lookup |
sohaychat-wc/get-product | One product in detail, including its variants |
sohaychat-wc/search-shop-policies-and-faqs | Shipping, returns, refunds, payment |
sohaychat-wc/get-cart | Read the shopper’s cart |
sohaychat-wc/update-cart | Add, change quantity, or remove — every change gets an Undo |
sohaychat-kb/get-information | Knowledge Base lookup |
The policy tool is the one that quietly earns its place on a store. Shipping and returns questions are what stall a sale, and it answers them from your WooCommerce store pages first, then your tagged Knowledge Base articles — which is why it’s worth grounding the chatbot in your own content even if the cart is the part you came for.
One detail on the cart tools: the shopper’s cart is identified through the normal WooCommerce session cookie. There’s no cart ID travelling over the wire for the model to get wrong or for anyone to guess.
What it can’t do
It cannot take payment or place an order. It fills the cart and hands off to your normal checkout. That line is deliberate — payment is where WooCommerce, your gateway, and your tax and fraud rules all have to agree, and a language model has no business improvising in the middle of it.
It can’t apply a coupon. There’s no discount tool. If a coupon is applied through your normal flow, the discount shows in the cart card totals, but the chat can’t add one.
It doesn’t read order history or customer records. No past orders, no saved addresses, no checkout data. The shopping tools simply aren’t wired to them — so “where’s my order?” is a question this cannot answer, and it’s worth having a Knowledge Base article that points those shoppers at the right place.
On compatibility, the boring news is the good news: Sohay declares both HPOS and Cart & Checkout Blocks compatibility, so you won’t get an “uncertified plugin” banner, and it works with the block-based cart and checkout.
One thing worth knowing for a different reason: cart contents go to your AI provider and are stored with the conversation, which is what keeps the cart card visible when a visitor scrolls back. It’s covered by the same export, erase, and retention paths as everything else — the GDPR and data guide goes through it properly.
Turning cart access off
Some stores want the catalog help and the policy answers but would rather cart data never left the site. Unset the two cart tools:
add_filter( 'sohaychat_tools', function ( $tools ) {
unset( $tools['sohaychat-wc/get-cart'], $tools['sohaychat-wc/update-cart'] );
return $tools;
} );Removing a tool doesn’t just block it — the model is never told it exists, so it can’t call it, can’t offer it, and can’t send its data anywhere. Returning an empty array disables tool use entirely; the chat still replies, it just has nothing to look anything up with.
If you want it narrower than on-or-off, sohaychat_tool_enabled runs per tool per request and receives the tool name and context, so you can allow the cart on product pages and not elsewhere. It can only narrow the offered set, never widen it.
FAQ
Does it work with variable products?
Yes, including products with several axes. The model passes the parent product ID plus a name/value pair for every axis — up to six — and WooCommerce resolves the variation. If the shopper hasn’t chosen yet, they get an option picker rather than a guess, and a bare variation ID is never accepted on its own.
What about the block-based cart and checkout?
Supported. Sohay declares Cart & Checkout Blocks compatibility alongside HPOS.
Can it apply a coupon?
No. There’s no coupon tool, so the chat can’t add or remove a discount code. Coupons applied through your normal flow still show up in the cart card’s totals.
Does any of this work without WooCommerce?
The shopping tools are hidden completely — the model isn’t told they exist, so it can’t offer to do things your site can’t do. The chat, Knowledge Base, and Conversations inbox all work fine on any WordPress site. If you’re setting this up from scratch, start with how to add an AI chatbot to WooCommerce.
Add Sohay to your store
Sohay is free on WordPress.org. You bring your own OpenAI or Gemini key, the provider bills you directly, and the daily spend cap means it can’t run away from you.
