Direct-to-consumer selling

Direct-to-consumer selling lets you sell to end customers who arrive anonymously, browse a public catalogue, pay online and get an order confirmation before they close the tab. Everything else under Commerce describes selling to businesses: dealers, distributors and key accounts who sign in and order on agreed terms.

It runs on the same platform. A consumer order is an ordinary sales order. The same engines price it and the same pipeline fulfils it. Direct-to-consumer adds what a public storefront needs and a B2B portal does not:

• a catalogue that can take heavy anonymous traffic;
• a basket that survives sign-in;
• a checkout that can take money from someone with no account;
• coupons that behave sensibly when many people race for the same code.

Overview

Six building blocks make up a consumer storefront:

The records written by the storefront and by publishing are read-only in the back office: you can open, filter, export and report on them, but not edit them. Commerce screens and records lists every screen.

When to use it

Use a consumer channel when buyers are members of the public who pay up front by card or UPI. Common cases:

• your own brand storefront;
• a mobile app or website built by another team on the storefront API (a headless channel);
• a partner's own storefront selling your range (a microsite).

For dealers who order on credit terms against price lists and schemes, use dealer ordering instead. Both kinds of order end up in the same sales pipeline.

How xMatix handles it

Channels: one selling surface at a time

A Commerce Channel is one place you sell from. Everything downstream is scoped to a channel, so one organisation can run a brand site, a headless app and many partner storefronts from the same catalogue without them interfering. Channels open from the App Launcher: type Commerce Channel. The Fields section lists what a channel holds.

The catalogue is published, not queried

A storefront never reads the item master directly. Publishing builds a versioned catalog publication of a store's range and switches it live in one step. The publication holds the listings, the browse tree, the displayed prices and the stock buckets. The previous Live version becomes Superseded, and the two most recent superseded versions are kept so cached pages still resolve. A build that fails is kept as Failed for diagnosis, and the previous version keeps serving.

This has two benefits:

• Anonymous traffic, much of it bots, is served from the frozen snapshot, so a crawl cannot slow the system your staff are using.
• A half-finished merchandising change cannot leak. Shoppers see the last complete publication until the next one is complete.

For each listing, the publication fixes:

• Price. The store listing's own price, when it is set and above zero. Otherwise, the price list price.
• MRP. Shown only when it is higher than the price.
• Stock bucket. In stock; low at ten units or fewer; out at zero or below; unknown when no stock is read for the item. The storefront shows no stock label for unknown.

Browse prices and stock buckets do not change until the next publish. Nothing republishes automatically: a saved merchandising change never goes public until someone publishes. The cart and the checkout always price against current rules (see below).

Product addresses are assigned once per store and never reused. A link you published, a customer bookmarked or a search engine indexed keeps working across republishes. Renaming a listing does not move its address.

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 the shopper signs in, the guest cart merges into any active basket they already have on that channel:

• a line for the same product adds its quantity to the existing line;
• a new line is carried across.

The guest cart is then marked Merged and kept for audit.

The cart is priced by the same routine as a sales order line, and the same scheme engine applies promotions, so the total a shopper sees is the total the order carries. A line added from a storefront listing uses the listing's own price when one is set, which is the price the catalogue showed. A cart that has not been priced recently is repriced when the shopper reads it again.

Each time the shopper changes the cart, its expiry clock restarts. An untouched cart is marked Abandoned after 4 hours by default, and the cart abandoned event goes to any subscribed system as a remarketing signal. The cart and its lines are kept, but the storefront refuses changes to it with "This basket is no longer active." After 72 hours untouched, the cart is Expired. Both windows are settings (see Configuration). If shoppers often come back to their basket after a few hours, set the abandonment window longer than your typical return gap.

Checkout freezes the deal before the money moves

When the shopper starts paying, the platform:

1. reprices the basket and locks the result on the checkout session;
2. reserves stock on channels whose oversell policy is deny;
3. holds a coupon code that requires reservation;
4. books the chosen delivery window.

Any of these checks can fail. Each failure happens before the customer is charged, and the shopper fixes the problem and tries again:

Then the money moves. The payment provider's signed webhook places the order from the frozen snapshot. Placement never reprices, so it cannot fail on commercial grounds.

The session lasts 45 minutes by default, and its stock and coupon holds last as long; after that, the cart-expiry sweep releases them. A shopper who backs out of checkout cancels the session. It moves to Expired, its holds are released at once and the basket unlocks.

There are three ways to pay:

• Card or UPI through your merchant account. The mechanics, the recovery sweep and the payment event trail are on Payments and gateways.
• Pay on account, for signed-in customers with credit terms. It checks the cart total against the customer's available credit. The order lands as Draft so your approval process can review it.
• Cash on delivery, only on channels that opt in. It needs no sign-in and has no credit check. The order lands as Draft, with no payment record. The cash is receipted later through the normal collection flow.

A paid order lands as Approved when the channel's Auto Approve Prepaid is on, otherwise as Draft.

A guest can verify their email or phone at checkout with a one-time code. A verified order links to their existing customer account. See Consumer self-signup and accounts.

Coupons that behave under load

A Coupon Campaign holds:

• its benefit: a percentage with an optional cap, a fixed amount, or a hand-off to a trade scheme;
• its start and end dates and minimum basket value;
• an optional channel and account-group scope, and a first-order-only switch;
• per-customer and total redemption caps;
• a stacking policy, either exclusive or stackable;
• a budget cap.

Its Codes hold the redeemable codes. Each code must be unique across your organisation.

Two behaviours are worth knowing:

• Scarce codes are held. A code marked as requiring reservation is held for the length of a checkout, so two shoppers cannot both spend the last one. Public codes are counted when they are redeemed.
• The budget never refuses a shopper. An order that takes a campaign past its budget cap still completes. The redemption is flagged as exceeding the budget, for you to review.

When an offer is really a trade scheme, point the campaign at the scheme instead of restating the offer, so the two cannot drift apart.

Where the order goes

A converted cart becomes a sales order and joins the pipeline described under xMatix Sales: allocation, fulfilment, delivery, invoice and collection. Consumer orders appear in the same lists, reports and mobile app as every other order. Record security, customization and analytics apply to them unchanged. The consumer channel is a way in, not a separate business.

Prerequisites

• The Enable Commerce switch is on (Setup → Feature Hub → Commerce → Settings, General group). It is on by default.
• A Store with items in its range. See Stores and Catalogue entries.
• A Payment Gateway Account if the channel takes card or UPI payments. See Payments and gateways.
• For a portal storefront, a portal site to serve it.
• For deny-policy channels, stock that is actually maintained for the items you sell.

Procedure

The back-office lists for channels, gateway accounts, coupon campaigns and microsites have no New button. You create these records in one of three ways:

• ask the Setup Copilot;
• use the Data API;
• open the list's create form directly by adding ?create=1 to the list address, for example /CommerceChannel?create=1.

Their record pages have no Edit or Delete either, so change an existing record through the Setup Copilot or the Data API. An administrator can add the buttons; see Commerce screens and records.

Step 1 — Create the commerce channel

1. In the App Launcher, type Commerce Channel and open the list. The shipped Commerce navigation has no Settings entry; see the Commerce app.
2. Open the create form for a channel (see above). Fill in Name, Channel Type, Store, Currency Iso Code and Oversell Policy.
3. Set Partner Account and Branch to the company and branch that sell. Leave Payment Gateway Account empty to use your default merchant account.
4. For a portal storefront, the channel also needs its Portal Site. That field is not on the shipped create form; set it after saving as described in Portal storefronts. The site then serves the storefront on its home page.
5. Save. The channel is active straight away (Is Active is on by default).

123456 Expand

1. 1

   Channel Type — portal (your own storefront), headless (someone else's front end calling the storefront API) or microsite (a partner's storefront).

2. 2

   Store — the range this channel sells. Nothing is sellable, and nothing publishes, without one.

3. 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. 4

   Payment Gateway Account — the merchant account for this surface; leave empty to use the tenant default. Its environment must match the deployment.

5. 5

   Allowed Origins — headless channels only: the browser origins permitted to call the storefront API with this channel's key.

6. 6

   Route By Pincode — send brand-storefront orders to the partner whose service area covers the shipping pincode, frozen when checkout opens.

Step 2 — Publish the store's catalogue

Publishing is an administrator operation in the commerce API, not a button on a record. Ask whoever runs your operational tooling to publish the store. The new version appears on the store's Catalog Publications with status Live, and the previous one becomes Superseded. Until a store is published, its storefront catalogue is empty.

Publish again every time the range, content, prices or images change.

Step 3 — Add a coupon campaign (optional)

1. In the Commerce app open Coupon Campaigns and create a campaign. Set Status to Draft while you prepare it.
2. Add its codes on the campaign's codes tab. Mark a code as requiring reservation only when it is genuinely scarce.
3. Set Status to Active when you are ready.

Step 4 — Test a purchase

On a channel bound to a Test gateway account, put an item in the cart and complete checkout. Then check the result:

• the cart shows Ordered;
• the checkout session shows Placed;
• the order appears in Orders, as Approved if Auto Approve Prepaid is on.

Step 5 — Follow a shopper's order

Open Checkout Sessions in the Commerce app and find the shopper's session.

• If it is Failed, its failure code says what stopped it. No money was taken.
• If it is Paid but not yet Placed, the money is safe and the order appears when placement runs. See Payments and gateways.

Fields

The commerce channel record, in the order the platform stores it:

The Api Key Hash field holds only a fingerprint of a headless channel's key. The key itself is shown once, when it is issued through the channel's rotate-key operation, and is never stored.

Business rules

• Deny reserves, the others do not. Only deny channels check and reserve stock when payment starts. An item with no stock record is never blocked. A tracked item at zero becomes unsellable, so choose deny only where stock is actually maintained.
• Placement cannot fail commercially. Every price, stock, coupon and slot check runs before payment. After capture, the order is placed from the frozen snapshot.
• Price drift. At payment start, a reprice that differs from the frozen total by more than the accepted drift fails with PRICE_CHANGED. The default drift is 0%, so the shopper confirms any change.
• Order status. A paid order on a channel with Auto Approve Prepaid on lands Approved. Every other order lands Draft.
• Pay on account needs a signed-in customer, and the cart total must not exceed their available credit.
• Cash on delivery is offered only on channels that opt in. It writes no payment record.
• Carts. There is at most one active cart per channel and shopper. Changing the cart restarts its expiry clock.
• Coupons. Codes are unique across your organisation. Budget caps flag redemptions but never refuse them.
• Publications. There is at most one Live publication per store. A failed build leaves the previous one Live.
• Webhooks. A failed delivery is retried up to 8 times with growing gaps, about a day in total. A subscription that keeps failing is switched off; fix the endpoint and switch it back on.

Example

A kitchenware brand opens a web shop next to its dealer business. The administrator:

1. creates a portal channel called Web Shop over the Retail Range store, in INR, with Oversell Policy deny and Safety Stock Buffer 2;
2. sets Partner Account and Branch to the brand's own company and its main branch;
3. leaves Payment Gateway Account empty so the default live merchant account is used;
4. picks the Shop portal site;
5. has the Retail Range store published. Version 1 goes Live.

A shopper adds a pressure cooker listed at 2,499 to a guest cart and enters the code WELCOME10. The code belongs to a 10% campaign capped at 300, first order only. The shopper then signs in. The guest cart merges into the basket they left on the shop last week, which already held a spatula.

At checkout, the platform:

• reprices the basket;
• reserves the cooker from stock;
• books Saturday's delivery window;
• freezes the total.

The shopper pays by UPI. The provider's webhook arrives, and the session moves from AwaitingPayment to Paid to Placed. An Approved sales order appears in Orders, and the warehouse fulfils it like any other order.

Training

Practice exercise

In a sandbox with a published store and a Test gateway account:

1. Create a portal channel with Oversell Policy deny and Auto Approve Prepaid off.
2. Place a test order through the storefront.
3. Find the checkout session and the order.

Expected result: the session is Placed; the order exists with status Draft (Auto Approve Prepaid is off); the cart is Ordered.

Then switch Auto Approve Prepaid on and repeat. The second order lands Approved.

Quick reference

• One channel = one selling surface; everything is scoped to it.
• Shoppers see the Live publication, never the item master. Publish to show changes.
• Low stock means ten units or fewer.
• Carts: Abandoned after 4 hours idle, Expired after 72 hours (both configurable).
• Checkout session: 45 minutes, and its holds last as long.
• An abandoned cart can no longer be changed; set the window to fit your shoppers.
• Every checkout failure happens before payment.
• Paid order + Auto Approve Prepaid = Approved; everything else = Draft.
• deny needs real stock records, or tracked items at zero stop selling.
• Coupon budgets flag, they never refuse.

Permissions

• The Commerce app and its records follow security profiles. As shipped:
  • System Admin has full access to the app and its records.
  • Sales Manager can read them all, and can write campaigns, codes and microsites, but not channels, gateway accounts or webhook subscriptions.
  • Sales Executive has full access to every Commerce record, including channels, gateway accounts and webhook subscriptions.

  See Commerce screens and records.

  • Storefront-written records (carts, checkout sessions, payments, publications, reservations) are read-only for everyone.
  • The administrator operations (publish a store, issue a headless key, register a webhook) require a signed-in internal user. External portal accounts are refused. With Enable Commerce off, they answer "Commerce is not enabled for this tenant."
  • Shoppers need no account to browse, fill a cart or pay by card, UPI or cash on delivery. Pay on account requires signing in.

  Configuration

  Module settings are under Setup → Feature Hub → Commerce → Settings:

  Setting	Group	Default	What changing it affects
  Enable Commerce	General	On	Off removes the Commerce apps from navigation, and the storefront and admin operations answer that Commerce is not enabled
  Expire an untouched cart after (hours)	Carts	72	How long an idle basket survives (1–8,760)
  Mark a cart abandoned after (hours)	Carts	4	When the Abandoned status and the remarketing event fire (1–8,760)
  Reprice a cart read older than (minutes)	Carts	15	How fresh the displayed cart total is; the reprice at payment start is unaffected (1–1,440)
  Checkout session lifetime (minutes)	Checkout	45	How long a checkout and its stock and coupon holds last (5–480)
  Accepted price drift at payment (%)	Checkout	0	How far the reprice at payment may move before the shopper must re-confirm (0–50)
  Reconcile a pending payment after (minutes)	Payments	10	When the recovery sweep asks the provider about an unconfirmed payment (1–1,440); see Payments

  The same page holds the partner leaderboard settings described in Partner microsites.

  Per channel: Oversell Policy, Safety Stock Buffer, Auto Approve Prepaid, Payment Gateway Account and Route By Pincode are fields on the channel record. Cash on delivery is switched on per channel through the payments.cashOnDelivery option in Settings Json.

  Delivery windows come from the branch time-slot capacity your branches already use, with the Delivery transaction type. Shoppers can book up to 14 days ahead, and the portal shows the next 7.

  Webhooks for headless consumers are set up as Webhook Subscriptions (type Webhook Subscription in the App Launcher to open the list). The events are order placed, order status changed, payment captured, payment failed, cart abandoned and catalog published.

  Scheduled work runs on its own:

  • cart expiry;
  • payment recovery;
  • webhook dispatch;
  • partner settlement accrual.

  Settlement accrual normally runs daily. It can also be run on demand: add a schedule for Accrue partner microsite settlements under Setup → Administration → Monitoring → Jobs, then select Run now.

  Common problems

  "This basket is no longer active."

  The shopper is changing a cart that is no longer Active. It has been abandoned, expired, merged at sign-in, or already turned into an order. Carts are marked abandoned after the Mark a cart abandoned after (hours) window, 4 hours by default. Raise that setting if shoppers regularly return later than that.

  "A payment is in progress for this basket. Cancel it before changing the order."

  A checkout session is waiting for payment, so the cart is locked. Finish the payment, or cancel the checkout from the storefront to release the basket.

  "The product is in the item master but not on the website"

  The storefront shows only the store's Live publication. Open the store's Catalog Publications. Check that the item is in the Live version's entries, then publish the store again. A Failed publication leaves the previous one Live; its error message says why the build failed.

  "The website still shows the old price"

  Browse prices are fixed when you publish. Publish the store again. The cart and checkout already use the current price.

  "Item is no longer available in that quantity"

  The channel's policy is deny and the sellable quantity is below what was asked. Sellable means available stock minus the Safety Stock Buffer. Restock, lower the buffer, or set the channel to allow or backorder if stock there is only advisory.

  "The delivery slot on this order has just been taken. Please pick another."

  The chosen delivery window filled up between choosing and paying. The shopper picks another window. Nothing was charged.

  "Sign in to buy on account." / "This order is larger than your available credit."

  Pay on account needs a signed-in customer whose available credit covers the cart total. Sign in, reduce the order, or pay another way.

  "This store does not offer cash on delivery."

  Cash on delivery is not switched on for the channel. Turn on payments.cashOnDelivery in the channel's Settings Json if you want to offer it.

  "A paid order did not appear"

  Open the checkout session. Paid but not Placed means placement has not run yet. The money is safe and the order will appear. A Failed session never captured money. See Payments and gateways.

  "Our system stopped receiving webhooks"

  After repeated failures, the subscription switches itself off. Fix the endpoint, then switch the subscription back on.

  Common questions

  Do consumer orders and dealer orders end up in the same place?

  Yes. Both become the same sales order with the same lifecycle, in the same lists, reports and mobile app. The channel tells you where an order came from; it does not put it in a separate system. A consumer order is allocated, fulfilled, delivered, invoiced and collected exactly like a dealer order, and your record security and analytics apply to it in the same way. The only differences are how it arrived and, for prepaid orders, that the payment was taken before the order existed.

  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. Signed webhooks tell your system when things change: order placed, order status changed, payment captured, payment failed, cart abandoned and catalog published. Deliveries retry with growing gaps for about a day. A subscription that keeps failing is switched off rather than retried forever. List the browser origins your front end runs on in the channel's Allowed Origins.

  Where are payment credentials kept?

  In your own secret store. The gateway account holds only a reference to the secret, never the secret itself. Each account is bound to an environment, Test or Live, and the platform refuses to use a test account on a live channel or the other way round. A test key therefore cannot take real money, and a live key cannot be used by accident while you are testing. See Payments and gateways.

  Can partners sell our range on their own storefronts?

  Yes. A partner microsite is a channel over the store that partner already uses, with its own address and delivery areas. An order placed on a microsite accrues commission to it at the microsite's settlement percentage, even when routing sends the order to another partner for fulfilment. The accrual job runs daily and can also be run on demand. An accrued line keeps the percentage that applied at the time and is never recomputed. See Partner microsites.

  Is there a Publish button?

  No. No commerce record has action buttons. Publishing a catalogue or a microsite and issuing a headless key are administrator operations in the commerce API. Settlement accrual, payment recovery, cart expiry and webhook dispatch are scheduled jobs. Refunds are issued at the payment provider and recorded from its webhook. See Commerce screens and records.

  Related topics

  • xMatix Commerce
  • Payments and gateways
  • Partner microsites and order routing
  • Consumer self-signup and accounts
  • Portal storefronts
  • Commerce screens and records
  • Stores
  • Dealer ordering