Jan Mikoláš
Glossary
E-commerce store
An online store connects a public catalogue to a transactional ordering process and the company’s real-world operations. A successful click in the frontend is not enough: authoritative server-side sources must confirm the price, availability, payment, and order state.
Short definition
An online store turns a product selection into a controlled order and its fulfilment.
The catalogue describes products, variants, brands, categories, prices, and availability. The commerce layer lets a customer build a basket, complete checkout, choose shipping and payment, and place an order. The backend then coordinates payment, inventory, fulfilment, communication, and, where required, invoicing, returns, or claims.
A product catalogue alone is not an online store if it cannot complete a purchase or hand an order over through a clearly defined process. Nor is a store the same as a payment gateway: the gateway handles a selected payment, while the store owns the basket, commercial rules, and order. An order is its own record of the purchase process and its state; a payment is a financial operation that may be pending, fail, be retried, or be refunded.
What it solves
It connects an online offer to the real fulfilment of an order
A customer can find a product, choose the exact variant, and complete a purchase, while the store’s operations receive consistent data for payment, inventory, shipping, customer support, and accounting.
- selling physical goods with variants, inventory, shipping, and fulfilment
- selling a digital product or service with a different delivery process
- B2B orders with customer-specific pricing, company accounts, and approval workflows
- a multistore setup spanning several domains, languages, currencies, and commercial rules
- integrations with ERP, warehouse, carriers, accounting, payment services, and marketplaces
Practical example
Ordering a black winter jacket
The customer first uses full-text search to find a jacket. They choose the black variant in size M and add it to the basket. The basket may retain an earlier indicative price, but at checkout the server reloads the current price list, tax context, permitted shipping methods, and availability of that exact variant. It never treats a price supplied by the browser as authoritative.
The server validates the address and contact details, calculates the final total, and creates an order with its own line items and a price snapshot in one controlled operation. If the request times out, the client does not blindly create the order again: it reuses the same business identifier or idempotency key. This prevents a duplicate order even when the first HTTP response never arrived.
The customer proceeds to the payment provider. Returning to the “thank you” page merely means that the browser came back; it is not reliable proof of payment. The store receives a signed payment webhook, verifies it, and idempotently moves the existing order to the next permitted state. A duplicate event does not repeat the state change or create another order. The warehouse or ERP then receives the information needed to reserve, pick, and dispatch the item.
How it works
Product → Basket → Checkout → Order → Payment → Fulfilment
This text diagram captures the main sales flow. Payment may complete synchronously or later, but its outcome is always reflected in a separate, consistent order state.
- Product and variant The customer chooses a specific sellable item with an SKU, price, and availability.
- Basket It temporarily holds items and quantities; it is neither final confirmation of the price nor an inventory reservation.
- Checkout The server validates the customer, address, shipping, payment, prices, applicable tax rules, and availability.
- Order A durable record of the items, amounts, customer, and initial state is created under an unambiguous identifier.
- Payment This separate operation succeeds, remains pending, or fails; a server-to-server integration provides the trusted result.
- Fulfilment The warehouse or ERP prepares the goods, the carrier takes over the shipment, and progress is recorded against the order.
- Alternative payment path Cash on delivery, bank transfer, or deferred payment changes when the money is confirmed, but not the need for a controlled order state.
Key components and principles
The catalogue, transactions, and integrations rely on different kinds of truth.
Catalogue reads can be optimised for speed, but creating an order and changing money or inventory require precise server-side rules.
Catalogue and variants
A product carries the shared description; a variant is the exact sellable combination, such as a size and colour with its own SKU. A category supports navigation but is not the same thing as either a product or a variant.
Prices, currencies, and tax
The server selects the valid price list, currency, discounts, and tax treatment for the context. The order stores the resulting amounts and their breakdown so that a later catalogue price change cannot rewrite history.
Availability and inventory
Physical stock describes the units on record. Sellable availability may subtract reservations, apply a safety threshold, or account for other warehouses; it can change between adding an item to the basket and placing the order.
Basket, checkout, and order
A basket is a work-in-progress selection. Checkout revalidates the rules, and the order creates a durable snapshot of the purchase. State transitions should permit only meaningful changes and record why they occurred.
Payment and shipping
The payment gateway confirms a financial operation, while the carrier confirms physical delivery. Their external identifiers and states map to the order, but do not necessarily mean the same thing as its internal state.
Administration and access
Customer support, warehouse staff, and finance teams need different operations. Authentication establishes identity, and RBAC helps restrict who may issue a refund, change fulfilment, or export customer data.
Integrations and sales channels
APIs connect ERP, carriers, accounting, or marketplaces. A marketplace is a separate sales channel bringing together offers from multiple sellers; a merchant’s own store may be one of several connected channels. Synchronisation must tolerate delays, failures, and retries.
Benefits, limitations, and common mistakes
A frictionless purchase depends on precise handling of edge cases.
Practical benefits
- the customer follows one coherent path from finding a variant to a confirmed order
- the administration interface connects sales data to the work of the warehouse, support, and finance teams
- integrations can automate payment, shipping, inventory, and multiple sales channels
- state history helps establish what actually happened to an order
- separating the catalogue from the transactional layer allows each workload to be optimised appropriately
Limitations and common mistakes
- accepting a price, discount, or permission from the client without recalculating it on the server
- treating the customer’s return from a payment gateway as definitive proof of payment
- promising inventory based only on the value shown when an item entered the basket
- creating a second order on retry or processing a duplicate webhook twice
- changing order state to arbitrary text without rules for permitted transitions
- treating a cache or search index as the authoritative source of order data
Scope of use
The sales process determines which capabilities a business actually needs.
A public catalogue may simply present an offer and pass an enquiry to a salesperson; an online store also creates and processes an order. A CMS manages pages, articles, and media and may complement the store, but does not itself provide pricing, checkout, payment, and inventory. A payment gateway is an internal or external payment component, not the entire store.
An online store is a type of web application. The merchant may operate it directly, or a provider may offer it as SaaS to multiple merchants; not every online store is therefore SaaS. A marketplace also facilitates offers and orders for multiple sellers and must distinguish ownership of the offer, fulfilment responsibilities, fees, and state updates.
For a larger catalogue, Elasticsearch may handle search and facets, while a cache speeds up frequently read pages. Both layers may briefly lag behind. Before writing an order, the backend must therefore verify the current price and whether the item can be purchased against authoritative data, not only a search result.
What to consider
The ordering flow must safely handle concurrency, retries, and integration outages.
The highest-risk failures occur at the boundaries between the browser, backend, payment provider, warehouse, and external systems.
- reload prices, discounts, delivery options, and availability from authoritative server-side sources at checkout
- protect order creation with an idempotency key or unique business identifier
- verify payment webhook signatures, record each event, and safely ignore duplicates
- keep order, payment, reservation, and shipment states separate and define permitted transitions
- secure customer accounts, sessions, and server-side administration permissions
- monitor stuck payments, inventory discrepancies, and failed synchronisations with ERP systems or marketplaces
Common questions
E-commerce in practice
Is a product catalogue already an online store?
Not necessarily. A catalogue presents an offer. An online store also lets a customer complete or unambiguously place an order and connects it to payment, shipping, and subsequent processing.
Is a paid order the same thing as an order?
No. An order and a payment each have their own identity and state. An order may await payment, use cash on delivery, have several payment attempts, or include a refund.
Is a successful return from the payment gateway enough?
No. The customer may close or imitate the redirect. The server should obtain the result through a trusted webhook or a payment API request and verify its relationship to the order and amount.
Why does availability differ from physical stock?
Sellable availability may account for reservations, safety stock, multiple warehouses, or incoming inventory. It can also change between adding an item to the basket and checkout.
Is every online store SaaS?
No. A merchant may operate its own application. SaaS describes software operated by a provider for a customer, which is a different property from the ability to sell online.
Hands-on e-commerce experience
I develop online stores as connected systems spanning catalogues, data, orders, and integrations.
I work with product variants, pricing, inventory, order states, multistore platforms, and marketplace integrations in long-running production systems.