We will review your sales process and propose an architecture
Catalog, orders, payments and accounting-system data exchange mapped before development begins.
E-commerce
Software for online sales
An e-commerce system manages a product from its catalog page through payment and delivery. Below are the system's modules, the processes it covers, and its connections to CRM, ERP, warehouse and POS systems.
What an e-commerce
software platform is
E-commerce software — a system that stores product, price and inventory data, accepts online orders, processes payments, and sends each order for fulfillment by the warehouse, delivery operation and accounting system.
Unlike a conventional website, it works with business records rather than pages: product, price, inventory, order, payment, shipment and return, each with its own status and history. The same order can originate in an app, a vending machine, through a manager or on a marketplace.
It is the operational layer behind a storefront, not the storefront itself. You can replace the storefront or add another one without rebuilding the underlying records.
What the system consists of
- Storefront — the customer interface: website, mobile app, vending-machine screen or self-service kiosk
- Data core — products, categories, attributes, prices, inventory, customers and orders
- Business logic — rules for pricing, discounts, product availability, delivery charges and taxes
- Process layer — order statuses, reservations, payment operations, shipments and returns
- Integration layer — data exchange with CRM, ERP, warehouse, POS, payment and logistics systems
- Administration panel — the workspace for content managers, order operators and category managers
- Analytics — a data view covering sales, the conversion funnel, inventory and returns
The problems the system solves
Six reasons businesses implement an e-commerce platform. Without one, each task is handled manually through spreadsheets, messages and phone calls.
One source of product data
Specifications, images, prices and inventory are stored in one place and distributed to every sales channel. The website, app and POS always agree.
Orders without an operator
Orders are created, checked and paid automatically around the clock. People step in only when judgment is required, such as an unusual delivery, a disputed return or a wholesale order.
Reliable inventory
Reserving stock at checkout prevents the same item from being sold twice. Cancellations caused by missing warehouse stock become exceptional rather than routine.
Controlled pricing
Prices and discounts are governed by rules instead of manual edits to product pages. Repricing a catalog with thousands of items takes minutes and can be rolled back.
Connection to accounting
Orders, payments and shipments reach accounting and warehouse systems without re-entry. Reconciliation is no longer a separate task.
Measurability
You can see what customers buy, what they search for but cannot find, where they leave checkout, and which products they return. Assortment decisions are based on data.
Which processes
the system automates
Automation does not mean replacing a salesperson with a robot. It means turning repetitive operations into rules that the system applies consistently and records in its history.
A rule remains active until its conditions change. Control is preserved: every automated action has an author, timestamp and previous value in the audit log.
Operations that become automatic:
| Time | What the system did automatically |
|---|---|
| 09:41 | 18% markup: recalculated 1 240 items |
| 10:00 | “15% off tea” promotion started on schedule |
| 10:03 | Order No. 14 190 declined: 2 items returned to stock |
| 10:06 | Low stock for SKU 77-1043: purchasing team notified |
- Publishing products and removing them from sale
- Recalculating prices from rules and markups
- Starting and ending promotions on schedule
- Validating and redeeming promo codes
- Reserving inventory for an order
- Changing order statuses
- Charging and refunding payments
- Calculating delivery charges
- Creating shipping documents
- Sending an order to the delivery service
- Notifying the customer at every stage
- Returning declined items to inventory
- Sending data to CRM and ERP
- Fiscalizing receipts at the POS
- Updating reports and data marts
- Sending low-stock alerts
How the
product catalog works
Catalog — a structured repository of product data: what is sold, how products differ, and which attributes customers use to find them.
A working catalog includes:
- Categories — a section tree; the same product can appear in several branches at once
- Attributes — typed specifications such as number, list, flag or range, used to build filters
- Variants — size, color or volume: one shared product page with separate SKUs and inventory
- Bundles and kits — a sellable item that deducts several component items when ordered
- Media — images, videos, instructions and certificates in several resolutions
- Relationships — alternatives, accessories, related products and replacements for discontinued items
- Item status — draft, published, hidden or archived. Archived items are retained so historical orders keep their context
The catalog's basic unit is a product item with a unique stock keeping unit (SKU): immutable identifiers, an editable description, and linked images, documents, prices and inventory records.
Bulk operations use import and export through a file, an API or an accounting-system feed. Every import is validated first: what will be created, changed or rejected, and why.
412new items
1 268updated
17rejected
Rejected: duplicate SKU — 9, required “Brand” attribute missing — 5, unknown category — 3. No rows are written to the catalog until the import is confirmed.
How
prices are managed
Price — not a field on a product page, but the result of applying rules at the time of a request. A product can have several prices at once, and the system selects the applicable one.
This means prices do not need to be edited across thousands of product pages. Changing a rule or base price list is enough.
Pricing layers:
- Base price — imported from an accounting system or entered manually
- Price lists — retail, wholesale, partner and regional
- Markup rules — a percentage or fixed amount over purchase cost, by category or supplier
- Personalized prices — by customer segment or individual contract
- Volume tiers — the price depends on the quantity ordered
- Currency and rounding — exchange-rate conversion and rounding to a customer-friendly increment
- Taxes — the tax rate per item and prices with or without tax
Every price change is recorded: who made it, when, under which rule and what the previous value was. This history supports margin reports and investigations of disputed orders.
Application order
Rules are resolved by priority instead of being added blindly. A typical item-price calculation follows this sequence:
- Identify the customer's price list
- Take the item's base price from that price list
- Apply the volume tier for the quantity
- Apply the contract's individual terms
- Apply the highest-priority promotion
- Apply a promo code if it is compatible with the promotion
- Award and redeem loyalty points
- Calculate tax and the final item total
Compatibility is explicit: which discounts can be combined, which are mutually exclusive, and the minimum permitted price. The minimum-price rule prevents several individually valid discounts from making an item unprofitable when combined.
- Base price, “Wholesale” price list4 200
- Volume tier, from 10 items−210
- Contract No. 218 terms−120
- SPRING promo code, compatible with promotion−186
- Minimum price — 3 500; limit not triggered3 684
- 12% tax+442
- Final item price4 126
How promotions and promo codes work
Promotion — a rule the system automatically applies to eligible orders. Promo code — the same type of rule, activated by the customer with a code word. Both are defined in the same way: conditions, mechanics, schedule and restrictions.
Trigger conditions
What the order must contain: products, a category or brand, a minimum value, a delivery method, a customer segment, a sales channel, a time of day or a day of the week.
Discount mechanics
Percentage, fixed amount, new price, discount on the cheapest item in a set, free delivery, gift, or points instead of a discount.
Dates and schedule
Start and end dates, recurring windows such as every Friday, and automatic activation and deactivation without staff involvement.
Restrictions
Overall usage limit, per-customer limit, one-time personal codes, exclusion from other promotions, and a minimum item price.
Code generation
One shared code for a campaign or a batch of unique recipient codes. A batch can be exported as a file and tracked code by code.
Performance tracking
For every promotion you can see the number of orders, total discount, revenue and margin after discounts, as well as how many codes were redeemed and how many remain.
How the
cart works
Cart — a draft order: a set of items that creates no commitment for either the customer or the store. Stock is not reserved and prices are not fixed, so the cart is recalculated whenever it is opened.
Recalculation checks four things: each product is still on sale, sufficient stock is available, the price has not changed, and discounts remain valid. The customer sees any changes before paying, not after the charge.
A cart must be able to:
- Move between devices — a cart started in a browser opens in the app after sign-in
- Work without an account — a guest can build an order immediately and signs in only at checkout
- Merge at sign-in — the guest cart is combined with the saved cart instead of overwriting it
- Enforce limits — minimum order value, case-pack multiples and per-customer quantity limits
- Separate unavailable items — discontinued and out-of-stock products are moved into a separate group
- Show the calculation clearly — the total is broken down into item subtotal, discount, delivery and taxes
- Product is on sale4 of 4All items are published; none have been removed from sale
- Sufficient inventory1 item“Whole-bean coffee, 1 kg” — 2 of 3 available; the remainder was moved to unavailable items
- Price unchanged1 item“Electric kettle” has increased by KGS 120 since it was added
- Discounts validYesSPRING promo code is active; promotion ends in 4 days
Checkout total: 3 items, KGS 11 640. Both discrepancies are shown to the customer before payment, not after the charge.
Saved lists
Lists that do not initiate a purchase sit alongside the cart: favorites, waitlist, specification comparison and repeat order. They are intentionally separate so the order total remains unambiguous.
Abandoned cart
Most carts never become orders. The system stores them with timestamps and can bring customers back through an email or messenger reminder, a link that restores the cart, or a personalized offer.
A reminder is sent once per event and does not become a mailing campaign; an unsubscribe costs more than the recovered order is worth.
Metrics to track
- Share of carts that reach checkout
- Checkout step with the highest abandonment
- Average cart composition and value
- Frequency of price changes between adding and paying
- Customers recovered through cart reminders
How
orders are placed
Order — a document that fixes the purchased items, checkout-time prices, customer, delivery terms and payment terms. The order then moves through a finite set of statuses, with every transition recorded.
Prices and discounts are fixed at checkout. A later price change or the end of a promotion does not affect an existing order; otherwise the amount due would no longer match the receipt.
Checkout step by step:
- Cart: recalculate prices and validate availability and limits
- Customer identification: sign-in, registration or guest checkout
- Delivery selection: address, pickup point, time slot and cost calculation
- Payment-method selection and promo-code application
- Reserve inventory for the order items
- Create the order and order number, then send confirmation
- Take payment or confirm payment on delivery
- Send for fulfillment: picking, shipment and delivery
Typical statuses: new → awaiting payment → paid → picking → handed to delivery → delivered → completed. Cancellation and return branches run alongside the main flow. The set is configured for the company's process, but remains finite and explicit.
Editing an order is a separate, permission-controlled operation: adding an item, substituting a product, changing a quantity, collecting an additional payment or issuing a partial refund. Every edit preserves the previous version of the order contents.
- 12New
- 8Awaiting payment
- 34Paid
- 19Picking
- 41Out for delivery
- 5Cancellation and return
How orders are handled
in the contact center
Contact center — not a separate application, but a workspace built over the same order queue. An operator sees the same records as the customer sees in their account, plus restricted operations: editing order contents, granting a discount within an authorized limit, releasing a reservation and issuing a refund.
An inquiry is a record with a status and history, just like an order. It has a channel, subject, related order, assignee and response deadline. A conversation is therefore not lost between shifts, and its outcome remains visible on the customer record.
How an inquiry is handled:
- An inquiry enters one shared queue from any channel: phone call, storefront chat, messenger, email or callback request
- The customer is identified by phone number or email, and their orders, returns and previous inquiries are retrieved at the same time
- The queue is assigned to available operators according to subject, language and customer priority
- The operator opens the order and confirms its contents, address and delivery window
- Changes are recorded as operations: item substitution, additional payment or partial refund, each with an author and previous version
- The order goes to fulfillment, and the customer receives confirmation through the same channel they used to contact the company
- The outcome is recorded on the customer record: subject, resolution, call duration and related order
Outbound work follows the same model: confirming an order before picking, calling about an unusual delivery, recovering an abandoned cart, or following up on a disputed return. Every interaction is written to the same history as incoming inquiries.
Shift roles
- First-line operator — receives inquiries, answers routine questions and places telephone orders
- Product advisor — selects products by specification, compatibility and availability, and suggests an alternative when an item is out of stock
- Order manager — manages an order through shipment, including changes, additional payments, deadlines, wholesale orders and orders from legal entities
- Returns manager — verifies return eligibility, initiates refunds and handles claims
- Shift supervisor — balances workload, joins difficult conversations, and monitors the queue and response deadlines
Metrics to track
- Time to answer and share of unanswered inquiries
- Share of issues resolved during the first contact without a follow-up call
- Conversion rate for outbound order confirmations
- Cancellations and returns after an operator conversation
- Inquiry subjects directly reveal what needs fixing in the storefront and product pages
How payments
The store neither retains card details nor processes a payment itself. It directs the customer to a payment provider, receives the result and links the operation to the order. Everything else concerns managing the payment lifecycle.
| Order | Operation | Amount | Status |
|---|---|---|---|
| 14 208 | Authorization | 12 480 | Authorized |
| 14 201 | Capture | 6 350 | Completed |
| 14 177 | Refund | 2 100 | Completed |
| 14 206 | Authorization reversal | 3 940 | Released |
| 14 209 | Bank decline 05 | 890 | Retry |
Authorization released without a refund transaction because the item was unavailable in the warehouse. Retrying a request with the same idempotency key does not create a second row.
812operations
98,6%successful
42 minaverage authorization hold
0discrepancies
Payment methods
Bank card, QR or instant payment system, digital wallets, payment on delivery, bank transfer for legal entities, installments and credit, or loyalty points.
Two-stage payment
Authorization comes first: the amount is held on the card but not charged. It is captured after the order is picked. If an item is unavailable, the hold is released without a refund transaction.
Provider notifications
The operation result arrives as a separate server-to-server request, not when the customer returns to the website. Closing the browser does not interrupt payment; the status is updated from the notification.
Idempotency
Retrying the same payment request does not create a second payment. Every operation has a key that both the provider and the system use to identify duplicates.
Fiscal receipt
After online payment, the connected POS system creates a fiscal receipt and sends it to the customer. A return receipt is generated for refunded items.
Reconciliation
Operations in the system are matched daily against the provider register and bank statement. Discrepancies enter a separate queue for manual investigation.
How
inventory is synchronized
Available inventory — the quantity available for sale at this moment. It is not the physical warehouse quantity: some units are reserved for orders, in transit, or blocked as damaged.
Available for sale = physical stock − reservations − blocked stock + confirmed inbound stock, where pre-ordering is permitted.
With several warehouses and locations, inventory is calculated separately for each one. The storefront displays the total across warehouses able to deliver to the selected region.
Data exchange methods:
- Full export — the complete inventory reference exported on a schedule, usually overnight
- Incremental exchange — only changes since the previous synchronization, every few minutes
- Events — the accounting system reports a change at the moment it occurs
- Message queue — no data is lost when the warehouse system or website is temporarily unavailable
- Conflict resolution — the authoritative value is defined in advance for every discrepancy
Every reservation has an expiry time. An order that is not paid on time releases the product back for sale; otherwise abandoned carts consume all available inventory.
Benefits of accurate inventory records
- Customers cannot order products that are unavailable
- Operators do not waste time calling customers to cancel orders
- The store avoids refunds caused by its own inventory errors
- Purchasing sees the true rate of consumption by item
- Pre-orders and waitlists can use honest availability dates
- Inventory-turnover reports are based on trustworthy data
Common causes of discrepancies
- An offline-store sale that did not reach the exchange in time
- A reservation with no expiry left behind by an abandoned cart
- A return recorded in the warehouse after the goods physically arrived
- A manual accounting-system adjustment made without recalculating reservations
- Bundles with incorrectly configured component deductions
| Warehouse | Physical | Reserved | Damaged | Available |
|---|---|---|---|---|
| Central | 1 420 | 310 | 24 | 1 086 |
| Vostok store | 96 | 12 | — | 84 |
| Pickup point No. 3 | 40 | 8 | 2 | 30 |
| Inbound stock | 600 | — | — | 600 |
| Available for sale | 2 156 | 330 | 26 | 1 800 |
Physical is the quantity physically in stock; damaged is the blocked quantity. Inbound stock counts as available only where pre-ordering is permitted. The storefront shows the total across warehouses that can deliver to the selected region.
Delivery and returns
Delivery is defined by three objects: delivery method, zone and rate. A return is a reverse process with its own document, not a cancellation backdated after the fact.
Delivery methods
Courier to an address, pickup point, parcel locker, store pickup, freight carrier for oversized goods, or digital delivery for electronic products.
Zones and rates
The price depends on region, weight, volume and order value. Rules define the free-delivery threshold and surcharges for upstairs delivery or oversized items.
Windows and slots
Dates and time windows are calculated from warehouse hours, picking time and the carrier schedule. Full slots close automatically.
Shipment and tracking
The order is sent to the carrier through an API. The system receives a tracking number and movement statuses and displays them in the customer account.
Return request
The customer selects items and a reason. The system checks the return period and eligibility for the product type, then creates a document with instructions.
Receipt and settlement
After receipt, the product is returned to available inventory or written off as damaged. Funds go back to the original payment method and a return receipt is created.
Partial returns are normal: one item out of five may be returned. Returns are therefore calculated item by item, and an order-level discount is allocated proportionally; otherwise the refund would not match the receipt.
How the
warehouse worker app
Warehouse worker — an employee who physically moves products: receives a delivery, places it in a bin, picks order items and hands the packed box to a courier. The system does not learn about these actions from an employee's report; every operation is confirmed by scanning a barcode.
The distinction matters. Marking “done” in a list confirms intent; a scan confirms a fact: a specific SKU, bin, employee and second-accurate timestamp. A mistyped SKU surfaces during inventory a month later; the app rejects an incorrect barcode immediately.
Tasks during a warehouse shift:
- Receiving — matching a delivery to the waybill item by item. Shortages, wrong items and damage are recorded at receipt and sent as a supplier claim instead of being discovered during order picking
- Labeling — an internal label is printed for any product without a readable barcode. Unlabeled products are not accepted into the warehouse
- Putaway — scanning both the product and bin links them, so the system knows where every unit is stored
- Picking — the app builds a route through the bins and guides the worker; a scan at each bin confirms the correct item and quantity
- Packing — box contents are assembled by scanning; anything not scanned cannot enter the box
- Dispatch — the box is handed to the courier by scan, transferring responsibility at the same moment
- Movement and replenishment — moving stock between bins and from storage into the picking area so fast-moving products remain nearby
- Cycle counting — counting bin by bin without stopping the warehouse; each bin is blocked only while it is counted
- Capture — damage, breakage or expiry, with a reason, photograph and responsible employee
How the app works
- One screen, one task: a prominent task line, scan field and confirmation. Lists, filters and reports stay in the administration panel
- Handheld terminal or phone — a handheld laser scanner or smartphone camera supporting EAN-13, Code-128, DataMatrix and QR
- Offline operation — operations enter a local queue and reach the server when connectivity returns, which matters in cold rooms and remote aisles
- Immediate validation — if the product or bin is wrong, the step is blocked and the app responds with sound and vibration. The error is corrected now, not during inventory
- Roles and permissions — warehouse workers see only their tasks and area; writing off stock or adjusting a balance requires a separate permission
- Productivity tracking — every operation has an author and timestamp, so shift output is measured in lines and items rather than estimated
What this provides to the rest of the system
Every scan is an inventory posting: the bin balance changes when the operation happens, not at the end of the day when paperwork is entered. The storefront, POS and contact center read the same inventory, so “available online, missing on the shelf” stops being a normal occurrence.
Picking accuracy — 99.4%: 7 scans were blocked during the shift, and every error was corrected immediately. The figures come from the same inventory postings, not a separate time sheet.
How the
courier app
Courier — the final fulfillment link and the only employee a customer meets in person. The app has two jobs: guide the courier through the route and record handover conclusively, without follow-up calls to establish what happened.
The key operation is scanning a QR code at handover. The code is printed on the order label or shown by the customer on a screen. The scan answers questions that would otherwise become a dispute: was this the correct order, was it handed to the correct recipient, and at what minute?
Dispatcher works at the other end of the same application: building routes by zone, weight, volume and delivery window, assigning couriers, monitoring the shift map, and resolving failures such as delay, unreachable customer or refusal at the door.
Courier shift step by step:
- The courier receives a shift route with stops in driving order, delivery windows and amounts to collect
- At the warehouse, the courier accepts orders by scanning them; responsibility transfers from the warehouse at that moment
- The app guides the courier between stops and recalculates their order when the route falls outside its windows
- At the address, the courier scans the QR code; the order is identified unambiguously and its contents and amount appear on screen
- A partial refusal is recorded at the door: declined items are marked and returned to inventory without a separate request
- Payment is accepted by card, QR or cash, and a fiscal receipt is sent to the customer
- Handover is confirmed by a code from a message, an on-screen signature or a photograph, according to the order type
- At the end of the shift, undelivered orders and collected cash are returned to the warehouse and cashier using the same scanning process
How the app works
- Map and route — shift stops, navigation to the address, recipient notes, entry code and floor
- Status updated at the stop — “en route,” “at address,” “delivered” and “refused” are selected with one button instead of a message to dispatch
- Offline operation — events accumulate in a queue; retrying does not create a second delivery record or deduct inventory twice
- Shift payments — collected amounts are totaled in the app and reconciled when proceeds are handed in, making discrepancies visible immediately
- Location and time — every event includes coordinates and a minute-accurate time, so a disputed delivery can be investigated from the log
- Recipient contact — calls and messages use a masked number; neither the courier's nor the customer's personal number is exposed
What the customer and operator see
The status set by the courier is the same status the customer sees in their account and the operator sees on the order. There is no separate “courier log”: one event is shared by all three parties.
What connects warehouse and delivery
Warehouse workers and couriers use different apps in different places, but manage the same order. They are connected by six shared rules, not end-of-day reports.
One document throughout the chain
The pick task, packing list and route sheet are not independent documents; they are different views of one order. An item added by an operator reaches the warehouse worker without re-entry.
Responsibility transferred by scan
Products pass from warehouse to courier and from courier to customer by scanning. At any moment, the system shows who physically holds the order and since what minute.
Status recorded where the event occurs
The person who performed an action records it at the place it happened. Dispatch does not copy statuses manually, so the fact and its record are not separated by several hours.
Offline operation
Both apps write operations to a local queue and forward them when connectivity returns. Every operation has a key, so retrying does not create a second pick or a second handover.
Discrepancies remain visible
A receiving shortage, wrong item, breakage or partial refusal at the address becomes a separate record with a reason and responsible person, not a silent inventory adjustment.
Measurable shifts
Items picked per hour, picking accuracy, share of deliveries within the promised window, time at the address and partial-refusal rate. Workload and bonuses are calculated from these facts, not impressions.
This determines the implementation requirement: warehouse and delivery must join the system together. A warehouse app without a courier app provides an accurate balance that disappears from view as soon as the order is dispatched.
What the
customer account provides
Customer account — access to the customer's own data without contacting an operator: orders, documents, addresses, payment methods and returns. Every question answered in the account is a call that never reaches support.
The account stores no separate copy of the data. It displays the same records an operator sees in the administration panel, limited to that customer and to operations the customer is permitted to perform.
It includes:
- Order history — contents, amounts, status, documents and receipts for every order
- Tracking — the current fulfillment stage and the carrier's tracking number
- Repeat order — moves a previous order into the cart after checking current prices and availability
- Refund — an item-level request with a reason and review tracking
- Addresses and recipients — saved delivery addresses, contacts and pickup points
- Payment methods — linked cards represented by tokens, with no card number stored
- Points and tier — loyalty balance, expiry date and available offers
- Subscriptions and consent — notification channels and data-processing consent, each revocable with one click
Business customer account
A B2B account is more complex: an organization has several employees with different permissions. A buyer prepares the order, a manager approves it and an accountant retrieves the closing documents. There is one order, but the actions are separated.
- Several users within one organization account
- Contract pricing and individual payment terms
- Order approval before fulfillment
- Invoices, certificates and waybills in the documents section
- Ordering from a SKU list or uploaded file
Sign-in and protection
Sign-in by one-time code or password, a second factor for payments and contact changes, and a session log that can disconnect an unfamiliar device. An email or phone change is confirmed through both the old and new contact.
- Placed12 May, 10:24 · courier delivery, 13 May, 12:00–15:00
- Paid12 May, 10:26 · card ••• 4417 · fiscal receipt sent
- Picked at warehouse12 May, 11:40 · Central warehouse
- Handed to delivery12 May, 15:02 · shipment KG 7741820
- Deliveredexpected 13 May · the courier will set the status at the address
The operator sees the same records on the order: events are shared, with no separate log for the customer account. The receipt and waybill are available under Documents.
How
integrations work
Integration — an agreed data exchange with an external system: what is transferred, in which format, how often, who owns the data and what happens when something fails.
Systems commonly connected:
- CRM — customers, inquiries, deals and segments for personalized pricing and campaigns
- ERP and accounting system — product master data, prices, sales documents and settlements
- WMS and warehouse — inventory by warehouse, reservations, picking tasks and return receiving
- POS systems and fiscal devices — sales and return receipts and data exchange with offline stores
- Payment providers — authorization, capture, refunds and reconciliation registers
- Delivery services — rates, schedules, shipment creation and statuses
- Marketplaces — assortment export, order intake and inventory updates
- Marketing — email and messenger campaigns, web analytics systems and product feeds
The key integration decision is data ownership. An owner system is assigned to every entity: product master data and prices come from ERP, customers from CRM, inventory from the warehouse, and orders originate in e-commerce. Editing one field in both systems creates permanent discrepancies, so bidirectional ownership is avoided.
| System | Data transferred | Messages | Result |
|---|---|---|---|
| ERP | product master, prices | 4 120 | No errors |
| Warehouse | inventory, reservations | 18 640 | 2 retries |
| CRM | customers, segments | 1 305 | No errors |
| Marketplace | orders, inventory | 2 470 | 1 under review |
Rules for reliable data exchange
An integration does not usually fail at launch; it fails six months later when an external system is updated, a channel goes down for an hour, or an unexpected value enters a reference list. Six rules determine whether the exchange survives such events.
Asynchronous processing
Checkout does not wait for an external system. A message enters a queue and is processed separately, so an unavailable warehouse does not stop sales.
Redelivery
A failed delivery is retried at increasing intervals. A message that still fails after every attempt enters an investigation queue instead of disappearing.
Idempotency
A redelivered message does not create a second order or deduct inventory twice. The recipient identifies a duplicate by its operation key.
API versioning
A format change is released as a new version while the old one continues working. External consumers migrate on their own schedule.
Exchange log
Every message is stored with its body, time, result and attempt count. Incident investigation relies on the log, not memory.
Reconciliation controls
Key figures are reconciled regularly: orders, payment amounts and inventory. A discrepancy becomes a task instead of being discovered during inventory.
Catalog and orders
Payments
Inventory and warehouse
Analytics
What data
analytics provides
Analytics is built from first-party sales and behavior data, not only external traffic counters. A traffic counter knows about page views; the system knows about money, products and returns.
Reports can be sliced by period, sales channel, category, brand, warehouse, region, customer segment or promotion. Every metric is available in each dimension and can be exported to a file or data warehouse.
4.8 millionrevenue, KGS +12%
1 240orders +8%
3 870average order value, KGS +4%
7,1%conversion +0.6 pp
Sales and revenue
- Revenue, order count, average order value and items per order
- Cost, gross profit and margin by item and category
- Discount impact: total discounts and revenue with and without them
- Payment-method mix and share of failed payments
Products and inventory
- Sales ranking and dead stock with no movement
- Inventory turnover and days of demand coverage
- Lost demand: product visits when inventory is zero
- Search queries with no results, providing direct assortment insight
Customers and behavior
- New and returning customers, purchase frequency and recency
- Checkout funnel: whether orders are abandoned at delivery, payment or registration
- Abandoned carts: contents and value
- Returns by reason, product and supplier
The steepest drop is between cart and checkout. Registration, delivery calculation and payment methods are the first areas to investigate.
How security is maintained
Security rests on three principles: payment data never enters the store's system, personal data is stored sparingly and under control, and every action involving money or orders leaves an audit trail.
Payment data
Card numbers are entered on the certified provider's side and never enter the store's system. A token, not a card number, is stored for repeat charges.
Encryption
All traffic uses HTTPS. Sensitive database fields are encrypted, and encrypted backups are stored separately from the production environment.
Access permissions
Role-based access: a content manager cannot see payments, and an operator cannot change prices. Administrative access requires two-factor authentication.
Audit log
Who changed a price, canceled an order or exported the customer database. Records are immutable and stored separately from operational data.
Personal data
Only the minimum necessary data is collected, with a retention period, deletion on request, and dated, sourced consent for processing and campaigns.
Abuse prevention
Rate limiting, protection against form enumeration, controls on promo-code reuse, and order fraud checks before picking.
Recovery is a separate discipline. Backups are useless until restoration has been tested: a test deployment runs on a schedule, not for the first time during an incident.
How the system
scales
Scaling is the ability to grow without a rewrite. Three quantities grow: catalog size, concurrent visitors and orders per hour.
The catalog is limited by search and filtering, peak traffic by page delivery, and order volume by the database and external integrations. Each requires a different solution, introduced when necessary.
Techniques used in practice:
- Caching — catalog pages and expensive query results are served from cache and refreshed when a product changes
- Dedicated search — the search index runs separately, so filtering by dozens of attributes does not burden the main database
- Separating reads and writes — the storefront reads from replicas while orders are written to the primary database
- Horizontal scaling — several application instances behind a load balancer, with capacity adjusted to demand
- Queues — expensive operations run in the background and do not block checkout
- CDN — images and static files are served from the node nearest to the customer
- Modularity — search, recommendations and payments scale and update independently
What to test before peak demand
- Load testing the “catalog → cart → payment” journey, not just the home page
- Behavior when the payment provider or delivery service is unavailable
- Full catalog reindexing speed
- Time to restore from backup
- External-system limits: requests per minute supported by ERP and warehouse systems
Areas of growth
- New sales channels: app, vending machines, marketplaces and kiosks
- New warehouses and pickup points
- New currencies, languages and legal entities
- New sales models: subscription, pre-order and B2B contracts
| Metric | Measured | Threshold |
|---|---|---|
| Catalog response, p95 | 180 ms | 400 ms |
| Peak orders per hour | 3 000 | 2 400 |
| Responses served from cache | 86% | 70% |
| Catalog reindexing | 9 min | 20 min |
| Backup restoration | 22 min | 60 min |
System modules
The system is assembled from modules, each responsible for its own data and operations, with explicit connections between them. It can launch in stages: catalog and orders first, followed by loyalty, analytics and external channels.
Product catalog
Product items, SKUs, descriptions, publication statuses, product-page versions and an archive of discontinued products.
Categories and navigation
Section tree, products linked to several branches, sorting, and landing pages for collections and seasonal sections.
Attributes and specifications
A typed property directory with display rules, forming the basis for filters, comparison and marketplace exports.
Variants and bundles
Sizes, colors and volumes on one product page with separate SKUs and inventory. Bundles that deduct several component items.
Media library
Images, videos and documents, automatic generation of formats and resolutions, watermarks and product associations.
Price management
Price lists, markup rules, volume tiers, personalized and contract prices, currencies, rounding, taxes and history.
Discounts, promotions and promo codes
Trigger conditions, discount mechanics, schedules, limits, code-batch generation, compatibility and minimum price.
Cart and checkout
Cross-device cart, price and availability recalculation, checkout steps, guest orders and abandoned-cart recovery.
Order management
One order queue for every channel, statuses and transitions, content changes, additional payments, split shipments and cancellations.
Payments
Provider connections, authorization and capture, partial and full refunds, notification handling and reconciliation.
Fiscal receipt
Sales and return receipts, online POS exchange, receipt delivery to the customer and monitoring of unsent documents.
Warehouse and inventory
Inventory by warehouse, expiring reservations, damaged-stock blocks, delivery and return receiving, and low-stock thresholds.
Delivery and logistics
Delivery methods, zones, rates, windows and slots, shipment creation, status tracking and document printing.
Returns and claims
Item-level requests, eligibility and deadline checks, receiving, refunds, return to inventory or damaged-stock write-off.
Customers and profiles
Accounts, addresses, legal entities and contracts, order history, segments and consent to data processing.
Loyalty program
Points, tiers, earning and redemption rules, point expiry, personalized offers and referrals.
Search and filtering
Search index, morphology and synonyms, typo handling, attribute filters, sorting and zero-result queries.
Recommendations and collections
Related and similar products, “frequently bought together,” curated collections and order-history-based rules.
Content and SEO
Pages, articles, banners, meta tags and page URLs, product structured data, sitemap and product feeds.
Notifications
Event-driven email, SMS, messenger and push notifications, message templates, scheduling and delivery log.
Analytics and reports
Sales, margin, inventory, funnel and return reports, custom dimensions, exports and data marts.
Integrations and API
Exchange with CRM, ERP, warehouse, POS, payment and logistics services, and marketplaces. API, webhooks and queues.
Access control and audit
Roles and permissions by section and operation, two-factor authentication and an employee activity log.
Multiple operating models
Several storefronts on one core, multiple languages and currencies, several legal entities and warehouses, and regional support.
Implementation sequence
The entire system is not launched in one release. The sequence below reflects dependencies: every step relies on data created by the previous one.
Audit and data model
Current processes, reference data and data-owner systems. The result is an entity model and integration map.
Catalog and inventory
Product-master migration, attribute and category configuration, and price and inventory exchange. Validation against real data.
Orders and payments
Checkout, statuses, payment provider, fiscal receipts and handoff to fulfillment. Initial launch with part of the assortment.
Expansion
Delivery and returns, loyalty, analytics and new sales channels. Each area is a separate, measured release.
Our Clients
Let's discuss your e-commerce project
Contact us today
Tell us what is already in place: accounting system, warehouse, POS and current storefront. We will review the process and propose a solution architecture.
