Loading

Carts

The shop itself — creating one, the options that decide what it can do, and how its administration is reached.

How the Shop Works

The commerce module is a full shop: catalogue, stock, shipping, tax, discounts, checkout, orders, refunds and buyer analytics.

Where to find it

Architect Panel → Commercial:

  • Carts — the cart itself and its options
  • Shop Insights — what buyers looked for
  • Vendor Approvals — applications waiting on a decision

Architect Panel → Data:

  • Datastores — then View Data on a cart table, where most shop administration lives

Architect Panel → Configuration:

  • Platform Modules — the commerce module must be on

Administration lives in two places

Worth knowing before you start looking, because it explains why the menu seems short.

  • Commercial holds three entries — Carts, Shop Insights and Vendor Approvals.
  • Everything else is reached through Data → Datastores, opening a cart table with View Data. Rows there carry actions of their own: a shipping method offers Weight Tiers and Cut-off Times, a product offers Stock, Filters and Volume Pricing, an order offers Payments, Refunds and Basket Contents.

Those row actions are how most of the shop is configured, and they are easy to miss because nothing announces them.

The shape of it

  • A cart is one shop, with its own options, permissions and payment methods. An installation can run more than one.
  • Products are two levels — a master product carrying the name, brand, category and images, and its variants carrying SKU, price, weight and order limits.
  • Stock is event-based, against warehouses.
  • Shipping is methods with weight tiers, cut-off times and holidays.
  • Orders carry lines, payments, shipments and refunds.
  • Vendors allow a marketplace, where others sell through your shop.

Start with the cart options

They decide what the shop can do — whether prices are shown, whether reviews are on, whether SKUs and brands are visible, whether stock is tracked. Changing them later changes the shop under your customers, so decide early.

You are taking money

Which raises the stakes above most of the platform. Prices, tax, stock and shipping costs are wrong in ways customers notice, and a wrong price honoured is a wrong price you pay for.

Test a complete order — add to basket, check out, pay, refund — before opening to real customers, and do it again after any change to pricing or shipping.

Worked example

A distributor runs one cart with prices shown to signed-in trade customers only, parent-child products for size variants, two warehouses, and shipping priced by weight tier. Vendor applications are off, because it sells only its own stock.

Recommendations

  • Look for row actions — most configuration is behind them.
  • Settle the cart options before loading a catalogue.
  • Place a complete test order, including a refund.
  • Re-test after pricing or shipping changes.

Setting Up a Cart

A cart is one shop. Creating it is a single row; the options on it are the real work.

Where to find it

Architect Panel → Commercial:

  • Carts — the cart itself and its options
  • Shop Insights — what buyers looked for
  • Vendor Approvals — applications waiting on a decision

Architect Panel → Data:

  • Datastores — then View Data on a cart table, where most shop administration lives

What the options control

Each is a switch on the cart record, and together they decide what the shop is.

  • Pricing — whether prices are shown at all. Off gives a catalogue or an enquiry site rather than a shop.
  • Stock — whether availability is tracked and shown.
  • Reviews — whether customers can rate and review products.
  • Delivery dates — whether an estimated date is offered, calculated from the shipping method's cut-off times and holidays.
  • Brands, SKUs, weight — whether each is displayed.
  • Sorting and filters — how buyers narrow a listing.
  • Parent/child — whether variants are presented as one product with options, or as separate products.
  • Min/max and max SKU quantity — order quantity limits.
  • Add to cart and Buy now — which actions a product offers.
  • Shipping address and billing address — which are collected at checkout.
  • Insights — whether buyer behaviour is recorded.

Checkout mode

The cart can use the built-in checkout or a custom one. A custom checkout requires a callback function to be defined; if the mode is set without it, checkout fails and the error log says so explicitly.

Use the built-in checkout unless you have a specific reason not to.

Order of setup

  1. Create the cart and set its options.
  2. Set the permissions — who can see the shop.
  3. Add warehouses, tax types and shipping methods.
  4. Add categories, brands and filters.
  5. Load products and their variants.
  6. Enable payment methods.
  7. Place a complete test order.

Products last, because they depend on nearly everything above them.

Permissions decide who sees it

A cart is restricted to security groups. That is what makes a trade-only shop, a staff shop or a customer portal possible — and what stops an unfinished shop being visible while you build it.

Changing options later

Is possible and visible. Turning prices off, or switching parent/child presentation, changes the shop for everybody immediately. Make those decisions before you have customers, not after.

Worked example

A staff shop is created with pricing on, reviews off, stock tracked, one warehouse and a single collection shipping method. Permissions restrict it to the Employees group, so it was invisible while the catalogue was loaded and appeared complete on the day it opened.

Recommendations

  • Set permissions first so the shop is invisible while you build.
  • Settle parent/child presentation before loading products.
  • Use the built-in checkout unless you need otherwise.
  • Products last — everything else supports them.