B2C commerce is selling to the person who will actually use the thing. They arrive without an account, from a link or a search result, on a phone, with no patience. They are one of thousands, most of whom will leave. And the ones who do buy expect the order to be certain the instant their money leaves — no "we will confirm by email".
That audience puts different pressure on a system than a dealer ordering a hundred lines against agreed terms. Three things have to hold.
The catalogue has to survive the traffic
Anonymous traffic is unpredictable and frequently not human. A crawler working through your range at three in the morning must not slow the system your staff use during the day.
So a storefront never queries live master data. Publishing builds an immutable, versioned projection of a store's range — listings, browse tree, prices, stock buckets — and flips it live in one step. Shoppers read the projection; the item master is left alone.
Two useful consequences fall out. A half-finished merchandising change cannot leak: shoppers see the last complete publication until the next one is complete. And product URLs are assigned once and never reused, so a link you published, a customer bookmarked or a search engine indexed keeps resolving across every republish.
The basket has to survive the shopper
A consumer fills a basket before you know who they are, and may sign in halfway through. The cart belongs to the channel and to an anonymous token; when they sign in it merges into whatever they already had, rather than replacing it — losing a basket at the sign-in step is a self-inflicted abandonment.
Cart maths is order maths. The routine that computes a cart line is the routine that computes a sales order line — the same code path, not a parallel one kept in step by convention. The total a shopper sees is the total the order carries, because there is no second implementation to drift.
The money has to be certain
The hard moment in consumer commerce is the gap between "pay" and "paid": the shopper is at their bank, and meanwhile a price changes or the last unit sells.
xMatix freezes the deal at payment-init. The basket is repriced, the stock reserved, scarce coupon codes held, and the result hashed and locked — and only then is the gateway asked for money. The consequence is worth stating plainly: a captured payment can always be placed. Order placement converts a snapshot that was already validated, so every checkout failure in the system is a pre-payment outcome. There is no state in which a customer has been charged and has no order.
Behind that, every payment attempt carries its own append-only event trail written from the gateway's signed callbacks — initiated, intent created, webhook received, signature verified, captured. When support is asked what happened to a payment, the answer is recorded facts with timestamps rather than an inference. And when a webhook never arrives, a reconciliation job polls for anything unresolved, so a payment nobody told you about still becomes an order.
Promotions that behave under load
Coupon campaigns carry a benefit, a window, a minimum basket value, per-customer and total caps and a budget. Two behaviours matter at consumer volume. Scarce codes are reserved for the duration of a checkout, so two shoppers cannot both spend the last one. And a campaign crossing its budget cap does not start refusing people mid-checkout — the order completes and the redemption is flagged for review. A shopper is never rejected for arithmetic they cannot see.
And then it is just an order
A consumer order becomes an ordinary sales order the moment it is placed, and joins the same pipeline as everything else: allocation, fulfilment, delivery, invoice, collection. It appears in the same lists, the same reports and the same mobile app, under the same record security. The consumer channel is a way in, not a parallel business — which is why turning it on does not start a second integration project.
Common questions
Do consumer orders go into a separate system?
No. A converted cart becomes the same sales order document as every other order, with the same lifecycle, reports and security. The channel records where it came from; it does not change what it is.
What stops a customer being charged without getting an order?
The commercial snapshot is frozen before the gateway is asked for money — repriced, stock reserved, coupon held, hashed and locked. Placement then converts a snapshot that was already validated, so it cannot fail on commercial grounds. Every checkout failure is a pre-payment outcome.
Can shoppers buy without creating an account?
Yes. A cart belongs to the channel and an anonymous token, so guests can shop and check out. If they sign in later, the guest basket merges into their existing one rather than replacing it.
Where are payment credentials stored?
In your key vault. The tenant holds a reference, never the secret. A merchant account is bound to an environment, so a test key cannot be used on a live channel.
Does the storefront slow down when traffic spikes?
Storefront reads come from a published catalogue projection rather than the operational tables, so anonymous traffic — including crawlers — does not compete with the people running your business.