How Ecommerce Works

The chain, and the three decisions people confuse

An order moves through six stages. The storefront and catalogue present something sellable; the cart holds a changeable selection; checkout validates it and commits it as an order; a payment is attempted and must be matched to that order; stock is allocated and shipped against it; and afterwards part of it may come back as a return and a refund. Keep three planning axes separate while reading that. The business model decides which stage is unusual for you. The platform decides which stages you configure rather than build. The shared components, catalogue, cart, order, payment, inventory, fulfilment and returns, exist in every store regardless. Store projects disappoint most often when the platform is chosen first and the awkward stage is discovered afterwards.

The records behind the storefront

The storefront is the customer-facing layer: pages, search, the product page, the cart and the checkout. It is not the system. Behind it sit records that outlive any page view: a catalogue item and its variants, a cart, an order, a payment, a stock position, an allocation, a shipment, a return and a refund. Two habits make that set workable. Give every record a stable identifier whose meaning never changes, and define the states it can be in and who may move it between them. Both are recommended controls here rather than universal facts, and which system owns which record depends on the architecture you choose. Decide that deliberately instead of inheriting it from whichever tool was installed first.

Products, variants and the catalogue record

A product is the thing you sell. A variant is the version a customer can actually choose, usually identified by a stock keeping unit, or SKU. The distinction matters because an order line has to reference something countable. In the fictional example below, BTL-RED is one variant of an insulated bottle: the catalogue carries its title, description, images, attributes and price, and the order line carries BTL-RED with a quantity. Whether the catalogue also owns the accountable quantity, or merely displays a number another system owns, is a design decision and one of the commonest causes of overselling. Where catalogue structure becomes the real question, covering variant identity, filters and URLs, catalogue and search is the deeper subject.

From a cart to an order record

A cart is a changeable selection with no promises attached. Checkout is the validation and commitment step: it confirms availability, calculates delivery, collects the address and contact details, and produces an order. That order is the durable record operations work from, so it must carry enough context to be matched later: line items with their SKUs and quantities, the merchandise amount, the delivery amount, the total, a customer reference and the delivery promise. If a refund three weeks later cannot be traced to a specific line on a specific order, the record was too thin. How that step gets built, including the unhappy paths, is covered in payment and checkout.

One fictional order, followed across systems

Example Trail Store is an invented small retailer, used to make the handoffs concrete. Order O-101 buys two units of BTL-RED at RM 100 each plus RM 10 delivery, so RM 210. The scenario assumes no tax calculation, and no tax or legal conclusion should be drawn from it. Payment PAY-101 is matched to the order before anything is allocated; allocation ALLOC-101 reserves two units; shipment SHP-101 sends them; the customer returns one unit as RET-101; and after inspection, refund REF-101 records RM 100 against the original payment. The delivery charge is retained, a policy choice here rather than a default or a statement about Malaysian consumer law. Every identifier stays separately traceable while related to O-101, and that is the point: you can answer what was paid, what was shipped and what came back without one answer overwriting another.

The exceptions are why those identifiers exist. One question per handoff is worth writing into your requirements before anyone builds anything.

• Catalogue: the variant sells out, or its price changes between the cart and checkout.
• Checkout: delivery is recalculated after the customer has seen a total.
• Payment: a success signal arrives twice, or arrives with no order attached.
• Inventory: the allocated quantity is not on the shelf.
• Fulfilment: only one of the two units ships.
• Returns: the inspection disagrees with what the customer reported.
• Refunds: a refund fails, or is recorded twice against the same returned unit.

Checkout, payment signal and confirmation

A payment is a separate event with its own identifier, and one rule prevents most ecommerce accounting pain: do not advance the order until a success signal has been matched to the right order and the expected amount. The mechanics vary by provider. Stripe's documentation illustrates the point because it is explicit. Authorising a payment holds the amount on the customer's payment method; the funds must be captured before the authorisation expires; and if it expires first, the funds are released and the payment is cancelled. Stripe states that an authorisation for an online card payment is usually valid for seven days, and about two days for in-person terminal payments, depending on transaction type and card network; that only some methods support separate authorisation and capture, with cards, Klarna and PayPal among those that do and ACH and iDEAL among those that do not; and that a partial capture automatically releases the remainder. Those are Stripe's documented behaviours, read on 19 September 2026. Another gateway will differ, and the store above uses no named provider.

Allocation, picking and shipment

Allocation and shipment answer different questions. Allocation says two units are spoken for by O-101 and should no longer be sellable to anyone else. Shipment says two units physically left, on a named consignment, on a date. A store can be right about one and wrong about the other, so collapsing both into one status field is a false economy. Two choices are worth making explicitly: when allocation happens, at matched payment or at picking, and whose number staff trust when storefront and warehouse disagree.

Return inspection and refund recording

A return and a refund are not the same event and should not share a record. The return is goods: one unit received, inspected, then restocked, repaired or written off. The refund is money: an amount recorded against the original payment. Keeping them apart lets you answer the situations that actually arise, such as goods received but no refund issued yet, or a goodwill refund with nothing received. In the example, inspecting RET-101 informs the inventory decision without making it, and REF-101 is recorded only after that inspection.

Which system owns the stock number?

Designate one accountable source for each stock scope, then define how every other system receives and reconciles updates from it. The answer is conditional, so settle it separately for five responsibilities.

• Catalogue identity: which system defines the variant, its attributes and its SKU.
• Available quantity: which system holds the number that decides whether an order can be accepted.
• Reservation and allocation: which system reduces availability when an order is taken, and when.
• Warehouse movement: which system records the physical picks, packs and transfers.
• Customer-facing availability: what the storefront shows, how stale it may be, and what happens at zero.

Timing decides most of the design. If the storefront refreshes availability every fifteen minutes, you have accepted a fifteen-minute window in which an oversell is possible, and you need a defined behaviour for it. Multiple locations, several sales channels, backorders and recovery after a failed synchronisation each add a case to answer rather than assume. When two systems both believe they own the number, the fix is not better software; it is a decision about which one is authoritative.

Money and goods run on different clocks

Fulfilment and settlement are separate timelines, and writing them as one status is where stores lose track of cash. Stripe distinguishes them plainly: the payout schedule determines when funds are sent to your bank account, while settlement timing is how long funds take to become available, varies by country and is typically expressed as T plus a number of days. So goods can be delivered while the money for them is not yet available, and refunds can push a balance negative: Stripe's illustration is receiving 100 in payments and refunding 200 from earlier ones, leaving minus 100, which it recovers by debiting the bank account. That is one provider's arrangement and yours may differ. Reconcile by asking, at every handoff, which identifier, amount, quantity, state and timestamp are supposed to agree.

What the product page owes a search engine

Product structured data is a machine-readable copy of what the product page already shows. Google documents two classes: merchant listing experiences, for pages where a shopper can buy from you, and product snippets, for pages where they cannot buy directly. For merchant listings Google requires a price as a number and a currency in three-letter ISO 4217 format, and notes that these experiences require a price greater than zero; availability, shipping details and a return policy are recommended additions. Only pages where a shopper can purchase are eligible, and Google says it may attempt to verify merchant listing product data before showing it. Two limits matter: the guidelines say not to mark up content that is not visible to readers and that structured data must be a true representation of the page content, and Google does not guarantee a rich result even when a page is marked up correctly. Pages have to be found first, which is the subject of how search visibility works.

How the flow changes by business model

The components above are shared, but each model stresses a different stage. These are planning cues rather than categories.

• Physical B2C and B2B: one catalogue, but business buyers bring accounts, quotations, approvals and payment terms.
• Marketplace: orders split by seller, adding seller responsibility, platform fees and seller settlement.
• Subscription: billing recurs, and an entitlement has to start, pause and end.
• Digital products: no shipment, so fulfilment becomes access, and revocation has to exist.
• Rental and hire: availability is time-based, and the return is an inspection against condition.
• Event tickets: capacity replaces stock, and an attendee and admission state sit beside the order.
• Courses: the purchase creates an enrolment, and access runs over time.
• Supplier fulfilment: availability and shipment sit outside your warehouse, and so does the return.

What to do next

1. 1For catalogue, order, payment, inventory, shipment, return and refund, write down which system owns the record, what identifies it, and which states it can be in.
2. 2Take your last awkward order and trace it through those seven records. Note the first point at which two of them disagree.
3. 3Pull one week from your order export and the same week from your gateway's payout report, and reconcile them by identifier rather than by eye.
4. 4Decide the oversell rule before you need it: what the storefront shows at zero, and what happens to an order taken against stock that is not there.