Online Store: Storefront and Selling

Cenaly isn't only a restaurant menu — it's also a full online store: a product catalog with variants, a storefront with filters and search, a product page, a cart and checkout, pickup/delivery, and payment collection. This page is an overview of the whole path from turning on the retail vertical to making a sale; follow the links in the text for details on each step.

Turning on the "Store" vertical#

The location's business type is switched in the location's general settings, or right inside the site's web settings (Websites section → "Site settings"). As soon as the type is set to "Store" (retail), the storefront switches into online-store mode:

• instead of a restaurant conversational menu, you get product pages at /product/name, category pages and a catalog;
• at the register (POS), instead of table/floor binding you get barcode scanning and weighed-goods sales;
• in the SEO prerender served to search engines and AI agents, you get product cards instead of dish cards, and Product/Offer structured data instead of restaurant menu markup (details — SEO & storefront promotion).

Catalog#

The catalog is the set of products and categories the storefront is built from.

• Categories — the structure a product "lives" in (not to be confused with collections — marketing storefront groups).
• Products and variants — a product can have several variants (SKUs) along axes like "Color"/"Size"/"Material": every combination is its own inventory row with its own price, barcode and stock.
• Sibling color swatches — if the same product ships in several materials/colors as separate product cards, the storefront shows them as small color-swatch dots right in the category list: clicking a swatch swaps the card's photo, title and price to that colorway — no need to open the product page to see another color.
• Product features (characteristics) — size, color, material, volume, brand and any other attribute; details — Product features.
• Multi-photo gallery — a product can have a gallery of several photos and videos (not just one cover image), with a caption on each frame; one photo can be set as the "hover photo" — on the storefront it cross-fades in when a shopper hovers the card in the catalog.

The fastest way to fill the catalog is AI catalog import: upload a price list (Excel/Word/PDF/photo), the AI recognizes products and prices and shows a plan for you to review.

Add a product with a barcode#

The product window with tabs opens for locations whose business type is Store or Online store (and for pickup points). To add and change products you need the Edit right in the Catalog section; if the add button is inactive, that right is missing or the catalog has reached your plan's item limit.

1. Open the Catalog section and click ＋ Product under the right category (the same button above the list creates a product without a category). The New product window opens.
2. On the General tab, fill in the product name — without a name the Save button stays inactive. The "visible on the storefront (published)" checkbox is already on for a new product.
3. On the Price tab, enter the price and fill in the SKU field (your own article number) and the barcode field (the code from the packaging). If you don't see these fields, click the gear in the window header (Product card display settings) and turn on SKU & barcode.
4. Click Save. The barcode is written to the product card and to the POS scanner index.
5. Check: scan the code at the POS — this product should land on the ticket at the price you set.

Good to know:

• A barcode is not a quantity. Saving the card does not create stock. For a product without variants this window does not create an inventory item; per-SKU stock is kept for variants (next section), and quantities on hand are changed by inventory documents — goods receipt, stocktake and others, see Inventory.
• The window does not check for duplicate codes. If another product already has the same barcode, you get no warning — test the code with a scan at the POS before you start selling.
• Codes linked to the product at the POS are kept. The field shows one main code; extra codes linked from the POS (see POS) are not erased when you save the card.
• With variants, each variant gets its own code. As soon as a product has variants, the SKU and barcode fields on the Price tab are hidden, and the product-level code is removed on save.
• For raw materials and supplies that are not sold as a catalog card, barcodes are set in the product card on the Inventory page — there, if the code matches another card, you are asked whether to create a second one.

Create product variants and sell the right SKU#

1. Open the product in the Catalog and go to the Variants tab. If it is missing, turn on Variants in the card settings (the gear in the window header).
2. Click the add-axis button and type the axis name, for example "Size". Use the add-value button to add values: S, M, L. Add a second axis the same way, for example "Color". If the category has a product template, a line with the axes the category expects appears above the axes — click an axis to add it in one tap.
3. Click the generate-matrix button (it becomes active once every axis has at least one value). A table appears: each row is one combination, for example "M / Red", that is a separate variant (SKU).
4. Fill in each row: SKU, barcode, price, and if needed the compare-at price, cost and weight. On a product with variants, the price on the Price tab is the base price: the storefront shows it as "from …" until the shopper picks a variant.
5. Check the two columns on the right. The stock column has a tracking checkbox (on for new rows): stock of this SKU is kept on the Inventory page. The availability column has a checkbox that marks the variant as sold out: the row stays with a "Sold out" tag, and the storefront still shows the variant but it can't be ordered. The delete button in the row removes it from the matrix entirely.
6. Click Save. For every active variant, the Inventory page gets its own item named like "T-shirt / M / Red", with the same barcode and price. Its name and options can't be edited there: the inventory card shows the link "This is a product variant (SKU) — name and options are set in the product card". Quantities of this SKU are added by inventory documents.
7. Changed the axes or values — click the rebuild-matrix button (the window reminds you that the axes have changed). Rows whose combinations still exist keep everything you entered; new combinations appear empty. Variants removed from the matrix are archived on the Inventory page when you save, and their movement history is kept.
8. At the POS, a specific variant lands on the ticket when you scan its barcode. By default, tapping the tile of such a product adds the product without a variant, and that sale does not deduct the stock of any SKU. To make a tap open the Choose a variant window with the price and stock of each SKU, turn on Choose the variant on tap in ⚙ → POS appearance. To change the variant of a ticket line, use the Size / colour command. Before payment, check the variant name and price on the ticket line.

Product variants (SKUs) are not the same as dish add-ons. Changing a barcode alone does not create stock or correct previously completed sales.

Build a bundle (kit) that deducts its components#

A kit is a product whose sale should reduce the stock of its parts: "tea + mug", a gift box. The parts are inventory items, including variants of other products (for example "Mug / White").

1. Make sure the components exist on the Inventory page. If the stock catalogue is empty, the tab says so: "The stock catalogue is empty — add items on the Inventory page first."
2. Open the kit product in the Catalog and go to the Kit tab.
3. Under How the kit relates to stock, choose a mode:
   • Deduct components on sale — the kit has no stock of its own, every sale takes its components off the shelf. On save, stock tracking is switched off for the kit's variants: it would be virtual;
   • Assemble in advance — a sale deducts the kit itself (its variant with stock tracking on) and leaves the components alone;
   • Not a kit — an ordinary product, the default.
4. Under Components per unit sold, click + Add component, pick an item from the list and enter Qty per unit — how much of it goes into one kit sold. The unit (pcs, g, ml…) comes from the component's inventory card.
5. If the kit has variants, a Components for field appears, set to All SKUs (default). To give one variant its own components (for example, gift wrapping only in the large kit), pick that variant and click Set own components — the list is copied from the default one and you can adjust it. Such variants are tagged "own components" in the list; Back to default components removes the difference.
6. Click Save in the product window.
7. Check: sell the kit and, once the order is completed, open the movement history of a component on the Inventory page — it shows a deduction of the quantity from the kit.

Limitations:

• If a mode is selected but the list is empty, nothing is deducted on a sale — the window warns: "The mode is selected but no components are listed — nothing will be deducted on a sale."
• In Assemble in advance mode the components from this tab are not used on a sale, and the production document on the Inventory page does not use them either: production works with semi-finished items whose recipe is set in their inventory card. Enter the number of ready kits yourself — with a goods receipt or a stocktake for the kit variant's inventory item. A kit without variants has no inventory item, so in this mode its sale deducts nothing.
• A kit made of products is not the same as a restaurant combo made of dishes: combos have their own mechanism, see Recipe cards.

Storefront: filters and search#

On catalog and collection pages, shoppers can:

• Filter by characteristics — a facet panel (sidebar on desktop, a bottom sheet on mobile) is built automatically from the characteristics of products in the category: color, size, material and any others, plus price and stock. Checked values within one characteristic combine with OR, different characteristics combine with AND (standard faceting logic).
• Search by text — the search box matches title, description and characteristics.
• Search by meaning (semantic search) — for larger catalogs, search understands the meaning of a query, not just exact words: "something warm for winter" will find jackets and sweaters even if those words aren't in the title. It runs on a vector index of products that includes the full picture of a product — characteristics, brand, SKU, barcode, attached documents.
• Ask the AI shopping assistant — a built-in chat answers questions about products in the shopper's language: suggests a product from a description, compares options, tells stock and characteristics. The same assistant can find a product by barcode, even one that isn't shown anywhere on the storefront.

Product page (PDP)#

The product page shows:

• Gallery — all photos and videos of the product, with captions and zoom;
• Characteristics — a "property → value" table (size, material, weight, etc.);
• Editorial blocks — additional "photo + heading + text" content sections in several layouts (full-width, image left/right, overlay on the photo) — great for brand story, materials, care instructions;
• Related products, "frequently bought together" and "recently viewed" — cross-sell blocks below the description;
• Wishlist — a heart icon to save the item, available in the customer's account;
• "Notify me when available" — if a product is out of stock, a shopper leaves their contact and gets notified when it's back in stock.

Cart and checkout#

• Cart can be built from any catalog/product page and supports several variants of the same product as separate lines.
• Promo codes and coupons are validated and applied server-side — the discount amount can't be tampered with on the shopper's side.
• Cart prices don't fall behind the catalog — a cart survives a page reload together with the price captured when the item was added, so on the next menu load the prices of plain lines are recalculated against the fresh catalog. If a mismatch still reaches checkout, the server won't start the payment and sends the shopper back to the cart with the new total.
• Tax is calculated per tax group of the product (set right in the product card) and by the tax table rules of your location — the rate can also depend on the sales channel (dine-in, takeaway, delivery). See Commerce.
• Payment won't start if the item is already out of stock — before creating a payment session the server checks the cart against warehouse balances and shows the shopper exactly which lines came up short. The check runs before gift cards are charged and before the payment gateway is called, so such a refusal costs nothing. Exceptions: dishes with a recipe (their components are deducted, not the dish itself), items without stock tracking, and pre-order mode.
• Multi-currency pricing — the storefront can display prices in the shopper's currency (converted) while the location itself keeps its books in one currency.
• Customer accounts — a separate sign-in for shoppers (not shared with venue staff): order history, saved addresses, wishlist.

Coupons, automatic discounts and shipping cost rules are configured in a dedicated section — Commerce.

Order rules and customers#

The settings that decide what a shopper may put in the cart and who may buy from you at all.

• Product personalisation — input fields on the product page: engraving, a message on a cake, a made-to-measure size. Values travel with the order and are visible in the kitchen, at the POS, on the KDS and on the receipt.
• Order quantity — minimum, step and maximum per product. Steppers, hints and checkout respect the rules on the storefront, and the server validates them again.
• Unit system — metric or imperial: weight and dimensions are entered in pounds, ounces and inches while being stored in a single canonical unit. Handy for the US.
• Customer groups and sign-up moderation — a new customer can land “under review”: until approved, the storefront shows a gate instead of checkout. Groups decide who sees what.
• Blocklist and anti-fraud — banning orders by phone/email and limiting the number of orders per period. A rejected order shows the guest a clear message, and the order list shows the reason. Contacts can be added to the blocklist straight from an order.
• Storefront maintenance mode — pause order taking: a localised notice in every language, a “closed” badge in the dashboard and a server-side block on checkout.
• Owner-editable storefront labels — rename standard strings (“Add to cart”, “Checkout” and others) to match your tone of voice.

Ask the shopper to fill in a required field for a product#

This way a made-to-order product can't go into the cart without the details you need: the engraving text, a message, a made-to-measure size. The field belongs to a specific product — it is not a general comment on the whole order.

1. Open the product in the Catalog, go to the Price tab and find the Customer input fields block. If the block is missing, turn on Customer input fields (engraving, cake message) in the card settings (the gear in the window header).
2. Click + Add field. In Label, write what the shopper must provide, for example "Engraving text" — the label can be translated into the storefront languages. A field without a label will not be saved.
3. In Type, choose Short text or Long text.
4. Tick Required.
5. Optionally fill in Hint (grey text inside the field on the storefront), Max length (empty means 120 characters, 1000 for a long text) and Surcharge — an extra charge per unit of the product when the field is filled in. Use Move up and Move down to reorder fields; a product can have up to 10 fields.
6. Click Save in the product window.
7. Check on the storefront: the product page now has a Personalization block, and the required field is marked with an asterisk. While the field is empty, the add-to-cart button is inactive, and if the shopper leaves the field empty, "Please fill in the required personalization fields" appears under it. Quick-adding such a product from the catalog list opens its page so the shopper can fill in the field.
8. Place a test order: the text travels on the order line and is visible in the order card.

The requirement is checked by the storefront when the shopper adds the product to the cart. The fields are set up in the product window — the restaurant dish card has no such block.

Fulfillment#

CDEK and Russian delivery aggregators#

For stores in Russia, checkout can show a rate comparison across several carriers at once — CDEK, Yandex Delivery, Russian Post, 5Post — letting the shopper pick the cheapest or fastest option. For carriers with a pickup-point network, checkout shows a map of nearby pickup points — the shopper picks a convenient one right during checkout, without leaving to a third-party site.

Rates and pickup-point addresses sync automatically; the resulting shipping cost flows into the order and onto the receipt. Going fully live with a given carrier needs your own carrier contract (CDEK — by contract and tax ID; some carriers — by phone number) — rate quotes and pickup points are available right away, while creating shipments and printing labels require a live carrier account.

Payment#

The store accepts payment the same way a restaurant menu does: online by card/wallet through a connected payment provider (the set of providers depends on the location's country), cash/card on delivery to the courier, and pay at the register for pickup/in-person sales. Details, provider list and setup — see Payments.

Storefront readiness for AI agents#

The store's catalog is "readable" not just by people but by AI agents (voice assistants, search and shopping agents):

• an llms.txt page on your domain — a machine-readable site map for AI;
• product and catalog pages are served to bots in an enriched form: breadcrumbs, brand, availability, a characteristics table, variants with prices, structured data (Product/Offer markup, and for products with several variants — grouped markup covering all variants);
• a product search tool is available to external AI agents through the public Guest API / MCP — the same protocol voice assistants use to place a restaurant order. Details — Guest API for AI Agents.

Related sections#

• Collections — storefront groups like "New arrivals", "Best sellers" and rule-based automatic collections
• Product features — catalog attributes and the AI characteristics wizard
• Returns & RMA — how a shopper returns a product and how it's processed
• AI catalog import — quickly filling the catalog from a price list
• Website builder — storefront styling: templates, colors, card layout
• SEO & storefront promotion — product feeds, structured data, redirects
• Articles & Pages (CMS) — storefront content beyond the catalog

FAQ#

Can I run a restaurant and a store on the same account?#

Business type is set per location, so a chain with several venues can have some locations running as restaurants and others as stores, each with its own storefront mode.

Does semantic search work on any catalog?#

Regular text search and filters work on any catalog. Semantic (meaning-based) search kicks in for larger catalogs — for smaller stores, text search and facets are usually enough.

Does the storefront show the exact stock count?#

The storefront shows an availability status ("in stock" / "out of stock"), not the exact unit count on hand — exact stock levels are only visible in the admin panel.

Are color swatches variants of one product or separate products?#

Technically they're separate product cards (each with its own slug, photos, and possibly its own price), but on the storefront they're visually combined into one card via swatches — the shopper switches color right in the list without losing browsing context.