Everything else under Commerce describes selling to businesses — dealers, distributors and key accounts who sign in and order against agreed terms. Direct-to-consumer is the other half: selling to end customers who arrive anonymously, browse a public catalogue, pay by card or UPI, and expect an order confirmation before they close the tab.
It runs on the same platform. A consumer order is an ordinary sales order, priced by the same engines and fulfilled by the same pipeline. What direct-to-consumer adds is the machinery a public storefront needs and a B2B portal does not: a catalogue that anonymous traffic can hit hard, a basket that survives sign-in, a checkout that can take money from someone with no account, and coupons that behave sensibly when thousands of people race for the same code.
Channels: one selling surface at a time
A Commerce Channel is one place you sell from. Channels live behind the Commerce app's Settings tiles; the record names the store the range comes from, the currency, what happens when stock runs short, and which merchant account takes the money.
- 1
Channel Type — portal (your own storefront), headless (someone else's front end calling the storefront API) or microsite (a partner's storefront).
- 2
Store — the range this channel sells. Nothing is sellable, and nothing publishes, without one.
- 3
Oversell Policy — deny reserves stock when payment starts; allow treats stock as advisory; backorder accepts and flags the line. Choose deny only where stock is actually maintained.
- 4
Payment Gateway Account — the merchant account for this surface; leave empty to use the tenant default. Its environment must match the deployment.
- 5
Allowed Origins — headless channels only: the browser origins permitted to call the storefront API with this channel's key.
- 6
Route By Pincode — send brand-storefront orders to the partner whose service area covers the shipping pincode, frozen when checkout opens.
| Field | Meaning |
|---|---|
| Channel Type | portal — your own storefront served by xMatix Portals; headless — someone else's front end calling the storefront API; microsite — a partner's own storefront on its own address |
| Store | The store whose range this channel sells; nothing is sellable without one |
| Branch, Partner Account | The fulfilling branch and, for a microsite, the selling partner |
| Currency Iso Code | Fixed per channel |
| Oversell Policy | deny reserves stock when payment starts so a paid order can always be fulfilled; allow treats stock as advisory; backorder accepts and flags the line |
| Safety Stock Buffer | Quantity held back from the sellable figure |
| Auto Approve Prepaid | A prepaid order lands Approved rather than Draft |
| Payment Gateway Account | The merchant account for this channel; empty means the tenant default (see Payments) |
| Allowed Origins | Headless only — browser origins permitted to call the storefront API; the consumer's API key is issued once through the channel's rotate-key operation and only its hash is stored |
| Route By Pincode | Route orders to the partner covering the shipping pincode (see Partner microsites) |
| Is Active | An inactive channel answers nothing |
Everything downstream is scoped to a channel, which is what lets one tenant run a brand site, a headless app and fifty partner storefronts from the same catalogue without them interfering. Choose deny only where stock is actually maintained: an item with no stock record is never gated, but a tracked item at zero becomes unsellable.
The catalogue is published, not queried
A storefront never reads the item master directly. Publishing builds an immutable, versioned catalog publication of a store's range — the listings, the browse tree, the displayed prices and stock buckets — and flips it live in one step; the previous version is superseded and the last two remain resolvable for cache and rollback. A failed build leaves the previous version serving.
This matters for two reasons that only show up in production. Anonymous traffic is unpredictable and often bot-driven; serving it from a frozen projection means a crawl cannot slow the system your staff are using. And a half-finished merchandising change cannot leak: shoppers see the last complete publication until the next one is complete.
The publication snapshots the displayed price-from, MRP and stock bucket (in stock, low under ten units, out, or unknown for untracked items) along with the content. Those browse values do not refresh until the next publication; checkout reprices the cart against current commercial rules before it freezes the deal. Product URLs are assigned once per store and never reused, so a link you published, a customer bookmarked or a search engine indexed keeps resolving across republishes.
Publishing is an administrator operation on the store, not a button on a record — see Commerce screens and records.
Carts that survive the shopper
A shopper can fill a basket before you know who they are. The cart belongs to the channel and to an anonymous token; when they sign in, it merges into whatever active basket they already had on that channel — matching lines add their quantities, new lines are carried across — rather than replacing it. Cart maths is order maths: the same routine that computes a sales order line computes a cart line, and the same scheme engine applies promotions, so the total a shopper sees is the total the order carries.
Idle carts are marked Abandoned after four hours by default (a remarketing signal; the cart is still recoverable) and Expired after 72 hours; both windows are module settings.
Checkout freezes the deal before the money moves
The moment a shopper starts paying, the platform reprices the basket, hashes the result and locks it on the checkout session. Stock is reserved on channels that refuse to oversell, a scarce coupon code is held, and a chosen delivery window is booked. Every one of those checks can fail — PRICE_CHANGED, OUT_OF_STOCK, COUPON_EXHAUSTED, DELIVERY_SLOT_UNAVAILABLE — and every one of them fails before the customer is charged.
Then the money moves, and the provider's signed webhook places the order from the frozen snapshot. Placement never reprices; it cannot fail on commercial grounds. The session lives 45 minutes by default, which is also how long its stock and coupon holds last. Customers with credit terms can pay on account (the order lands Draft for the tenant's approval), and a channel can opt in to cash on delivery, which places the order immediately without a payment record — the driver's cash is receipted later. The mechanics, the recovery sweep and the payment event trail are on Payments and gateways.
Coupons that behave under load
A Coupon Campaign carries its benefit (a percentage with an optional cap, a fixed amount, or a delegation to a trade scheme), its window, its minimum basket value, an optional channel and account-group scope, a first-order-only switch, per-customer and total redemption caps, a stacking policy and a budget. Its Codes tab holds the redeemable codes, globally unique per tenant.
Two behaviours are worth calling out. Codes marked as requiring reservation are held for the duration of a checkout, so two shoppers cannot both spend the last one; public codes are counted at redemption instead. And a campaign that crosses its budget cap does not start refusing people mid-checkout: the order completes, the redemption is flagged as exceeding budget and the campaign is marked overspent for review. A shopper is never refused for arithmetic they cannot see. Where an offer is really a trade scheme, the campaign delegates to the scheme engine instead of restating the offer in a second place.
Where the order goes
Nowhere special. A converted cart becomes a sales order and joins the pipeline described under xMatix Sales — allocation, fulfilment, delivery, invoice, collection. Consumer orders appear in the same lists, reports and mobile app as every other order, and record security, customization and analytics apply unchanged. That is the point: the consumer channel is a way in, not a parallel business.
What is available today
Direct-to-consumer is an early-availability capability. Available now: channels, catalogue publishing, carts and checkout, card and UPI payment through your own merchant account, pay on account and cash on delivery, coupons, the customer account area, consumer self-signup that provisions a linked customer, partner microsites with pincode routing, delivery windows and commission settlement, and signed outbound events for headless consumers.
Not yet: action buttons on the commerce back-office screens. Publishing a catalogue or a microsite and rotating a headless key run from administrator endpoints; settlement and payment recovery are scheduled jobs; and the configuration lists (channels, gateway accounts, coupon campaigns, microsites) show no New button today — records are created through the Setup Copilot or the Data API, or by opening the list's create form directly (for example /CommerceChannel?create=1), and are editable once they exist.
Common questions
Do consumer orders and dealer orders end up in the same place?
Yes. Both become the same order document with the same lifecycle. The channel tells you where an order came from; it does not put it in a different system.
Can we use our own front end?
Yes — that is what a headless channel is for. The storefront API serves the published catalogue and the cart and checkout operations, and signed webhooks (order placed, order status changed, payment captured, payment failed, cart abandoned, catalog published) tell your system when things move. Deliveries retry with backoff for about a day and a subscription that keeps failing is disabled rather than retried forever.
Where are payment credentials kept?
In your own secret store. The tenant stores a reference, never the secret, and a gateway account is bound to an environment so a test key cannot be used on a live deployment.
Can partners sell our range on their own storefronts?
Yes. A partner microsite is a channel over the store that partner already resolves to, with its own address and delivery areas. Orders stamp the partner as the selling organization, and the daily settlement job accrues commission at the microsite's settlement percentage when it runs; an accrued line is never recomputed afterwards.