POS and ecommerce integration in Kenya: keep shop and online stock consistent

Choose whether the POS, a central inventory service or the ecommerce platform is responsible for the final quantity. Two systems freely overwriting each other can lose transactions even when their screens look correct. Write down which system may create products, change prices, receive stock and approve adjustments.

For a hypothetical shop, the central record may hold 10 sellable units while tills and the website report movements. If the POS instead owns inventory, the online store needs a defined update process and a way to display unavailable or uncertain stock. The right arrangement depends on the actual systems and network conditions; no platform name resolves it automatically.

Create one stable identifier for every sellable item or variation. A shirt in blue, size medium, should not be confused with another size just because the displayed name is similar. Define barcode, SKU, unit, pack and location relationships. Import a representative sample and compare both systems before the full catalogue.

Avoid merging records solely on product titles, which staff may edit. Decide how discontinued items, duplicate barcodes and pack conversions are handled. A carton received into the warehouse may become individual units at the till. The conversion must be recorded once through an agreed operation rather than added independently to both quantities.

Agree whether an unpaid online order reserves units, how long the reservation lasts and which event releases it. A payment timeout should not permanently lock stock. A late payment needs a review rule if the reservation has expired and the last unit has already sold elsewhere.

Returned goods may be sellable, damaged or awaiting inspection. Automatically returning every refund to sellable stock can create orders the warehouse cannot fulfil. Record stock status as well as payment status. WooCommerce documents product stock settings, but cross-channel reservations and return handling still need an implementation-specific design.

Use these checks to compare proposals against your real workflow. Mark each requirement as included, optional or excluded, and record the person responsible.

An offline till can continue recording sales locally, but the public store may not yet know those units have sold. Choose the acceptable risk: hold a stock buffer, temporarily disable uncertain items, or require staff confirmation for scarce stock. Explain the limitation to the business owner instead of promising perfect live synchronisation during disconnection.

On reconnect, the system should identify queued movements, apply each once and show any conflicts that need review. Ask for a demonstration that interrupts the connection during a sale and then reconnects. A screenshot of two matching quantities after a normal transaction does not prove recovery. Include printer, payment and receipt behaviour separately in the test.

Give staff an exception list showing failed updates and unresolved differences. Decide who investigates and how quickly a broken connection should be noticed. Keep useful event history without unnecessarily exposing customer or payment details. Integration credentials belong in the appropriate protected server configuration, not a public page or spreadsheet shared with every cashier.

Our Good Morning Baby Shop POS portfolio provides relevant POS context; it is not a promise that any external till is already compatible. Use the POS buying guide and send the POS team your system names, catalogue sample, branches and offline requirements. Ask for a scoped demonstration before approving a broad integration claim.