The plain version
A typical store runs as a shop front, a spreadsheet, a payment dashboard, a courier portal and an accounting package, held together by one person who knows which screen to open in which order. That arrangement holds until volume rises or that person takes a holiday, and then the gaps between the screens become the customer's problem.
A connected system replaces the person in the middle with data. Your stock figure should exist in exactly one place, and every other screen should be reading it. Once that is true, the same discipline can be applied to orders, payments and the books, and the business stops finding out about its own mistakes from customers.
The five records that have to agree
The catalogue. What you sell, described once. Titles, images, variants, attributes, prices and tax treatment. One system owns it, and channels take their copy from there.
Stock. How many you have, by location. This is the number that causes the most customer harm when it is wrong, because a wrong stock figure creates a sale you cannot fulfil.
Orders. What was bought, by whom, at what price, with what promised delivery, and what state the order is in now. Status changes have to propagate, because the customer email and the picking list read from the same record.
Payments. What was authorised, captured, refunded or disputed, and which payout it landed in. Payment records and order records are separate things and must be matched deliberately.
Customers. Contact details, order history and consent preferences. This one carries the data protection weight, so it deserves the tightest access rules of the five.
When those five agree, the operational questions get answers instead of estimates: what is in stock, what was promised, what was paid, what is owed. When they do not, everyone downstream builds their own spreadsheet, which is how a business ends up with five versions of the truth and no way to choose between them.
How the parts actually talk
Webhooks
A webhook is an event notification the platform sends to a URL you control the moment something happens. WooCommerce documents them as exactly that: notifications covering order, product, customer and coupon events, secured with a secret key used to generate a hash included in the request headers. Shopify describes its own as a way to receive near real-time data about shop events, delivered to a URL, a Google Pub/Sub topic or an Amazon EventBridge ARN.
That is what makes a system feel live. An order is placed, the stock system hears about it within seconds, the courier record is created, and the customer gets a confirmation that reflects the real state of the order. Every one of those steps reads the same order record, so nothing has to be typed a second time.
The failure modes to design around
Two documented limits shape any sensible build.
Shopify states that it does not guarantee ordering within a topic, or across different topics for the same resource, so an update event can arrive before the creation event it belongs to, and recommends using the timestamps in the headers or payload to sequence events yourself. WooCommerce automatically disables a webhook after more than five consecutive delivery failures, which means a run of errors at your end can silently switch off a feed.
Both are manageable. Sequence by timestamp rather than by arrival. Make every handler idempotent, so processing the same event twice changes nothing. Monitor webhook status as a first-class alert. Then run a scheduled reconciliation against the platform's API that compares your copy of stock and orders with the platform's, and reports differences rather than assuming there will be none.
Scheduled reconciliation
The live stream keeps things current. The scheduled job keeps things true. Once a night, pull the authoritative list of orders and stock levels, compare, and produce a short difference report. A connected system that cannot prove it agrees with the platform is a connected system you will stop trusting after the first discrepancy.
One sale, end to end
It helps to trace a single order through a connected system, because the handoffs are where the value sits.
A customer adds an item to the basket. The store checks the stock figure it holds and, if the item is low, checks the authoritative record before promising it. The customer pays, completing an authentication step where the bank asks for one. The payment provider confirms, the order record moves to paid, and only then is stock committed.
The order event fires. Stock is decremented in the system that owns it, and every channel reading that figure updates. A picking record is created. The courier booking is raised and the tracking reference returns to the order. The customer receives a confirmation carrying the real delivery promise rather than a generic one.
Overnight, the reconciliation job compares the store's orders with the internal copy and reports any difference. At settlement, the payout lands in the bank feed and matches back to its constituent orders, fees and refunds. Nobody has typed anything twice, and every step left a record.
Payments and the authentication step
Strong Customer Authentication changed how online card payments complete in the UK and Europe. Stripe documents SCA as a rule in effect from 14 September 2019 under PSD2, and states that card payments require 3D Secure to meet the requirement, with banks liable to decline transactions that do not follow the authentication rules. The UK timetable ran later: the FCA extended the deadline for e-commerce SCA compliance to 14 March 2022, after which firms that failed to meet the requirements were subject to supervisory and enforcement action.
Two practical consequences for a store. First, the checkout has to handle an authentication step that can interrupt the flow, which means the order record needs a state for a payment awaiting authentication and the system must not treat that as a completed sale. Second, a payment successfully authenticated through 3D Secure generally carries a liability shift, with responsibility for a fraudulent-use dispute moving to the card issuer, so the authentication step is worth designing well rather than treating as friction.
Recurring and off-session charges add their own handling. Stripe's guidance is to authenticate the card at the point it is saved and to flag later charges as off-session, and it notes that exemptions are never guaranteed, so the system has to cope with a bank asking for authentication anyway.
Returns, refunds and the law
The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 govern distance selling in the UK. A consumer generally has 14 days from delivery to cancel an order without giving a reason, and then 14 days from cancelling to send the goods back. The trader must refund within 14 days, or within 14 days of receiving the goods back where a return is involved. Where the trader has not provided the required information about cancellation rights, the cancellation period can extend by up to 12 months.
Regulation 35(5) places the direct cost of returning the goods on the consumer, unless the trader agreed to bear that cost or failed to tell the consumer beforehand that the consumer would bear it. Every one of those points is a system requirement as much as a policy one: the cancellation window is a date calculation the order record should hold, the refund deadline is a clock that should be visible, and the returns information has to be in the template rather than in someone's memory.
The books
This is where a connected system pays back most visibly, because month-end is where disconnection turns into manual matching. Xero's Shopify integration page, checked in September 2026, describes sales, payouts and fees syncing into Xero, payouts from Shopify Payments and other gateways matched automatically to the bank account with fees, refunds and taxes handled, and a choice between a daily summary and separate transactions per sale.
The detail worth getting right is payouts. A payment provider settles many orders in one bank deposit, net of fees and refunds. A system that matches that deposit back to its constituent orders automatically removes the single most tedious task in ecommerce bookkeeping. A system that does not will have someone doing it by hand on the first Tuesday of every month.
Where a shop till fits
A business selling in a shop and online has the same problem twice over, because two channels are now drawing down the same stock. The rule stays the same: one system owns the stock number, and the till and the store both read and write to it rather than keeping separate counts. Food businesses have their own version of this, where online, phone and in-store orders all need to land on one screen.
What to connect first
Stock, then orders, then payments, then the books. That order follows the cost of being wrong. A wrong stock figure costs a customer. A late order status costs an email. A slow reconciliation costs internal time. Fix them in that sequence and the value shows up early. Before any of it, write down which system owns each of the five records, because that single document settles most integration arguments before they start and it is the thing you will hand to whoever maintains the system after you.
What to measure afterwards
Four numbers tell you whether the system is working. Stock accuracy, measured as the share of lines where the recorded figure matches a physical count. Order status latency, from event to customer notification. Payment authentication drop-off at checkout. Hours spent on reconciliation at month-end. Take a baseline before the first integration goes live, and check the same four a month afterwards.