Ecommerce POS Integration: How to Keep Your Store and Website in Sync

Ecommerce POS integration connects the point-of-sale system in your physical stores with your online store, so stock, orders, customers, prices and returns stay consistent across both. Most of the work goes into deciding which system owns each record and what happens when the two disagree or a sync fails.

This guide covers what to sync, how to choose between a native connector, middleware and a custom API layer, and the conflict and failure rules most POS ecommerce integration projects leave until something breaks.

What needs to sync, and in which direction

Start with a list of records, not a list of features. For each one, write down which system owns it, which way it flows and how quickly it has to arrive.

Your table may look different. The point is to fill it in before choosing a tool, because the tool has to support the answers.

Clean up SKUs and barcodes before you connect

An integration matches each product in the POS with the same product in the online store, usually by SKU or by barcode. If the two catalogs disagree on those identifiers, the first sync matches the wrong products or none at all. Stock counts then land on the wrong item, and the website sells sizes the shop does not have.

The two identifiers do different jobs. A SKU is an internal code your business creates. When each catalog was set up separately, the POS and the online store can hold different SKUs for one product. A barcode carries a GTIN, a product number issued through GS1 that stays the same across companies. GS1 US notes that different retailers can sell the same GTIN under their own SKUs. Shopify's help pages separate the two in the same way. Barcodes let staff scan products in Shopify POS and count stock, and SKUs identify products inside your business.

Where every variant carries a GTIN, the GTIN is the safer match key, because it does not depend on how either catalog was built. Where products carry only internal codes, the SKU becomes the key, and both systems have to use the same one.

The cleanup comes before the first sync, in this order:

• Export the product lists from the POS and the online store, including every variant.
• Match them on the chosen key, then on the other identifier, and list every item that does not match on both sides.
• Fix duplicate barcodes, blank SKUs and SKUs that differ only in letter case, spaces or leading zeros.
• Give each variant its own barcode and link it to the matching POS item, so a size or pack sold at the till reduces the right stock online.
• Make the match key a required field in both systems from then on.

GS1 US says each product option, such as a different size or pack, needs its own GTIN. In North America the till usually scans a UPC-A barcode, and the number it carries is a GTIN-12. Own-brand products without barcodes can get them from GS1 US, which licenses a single GTIN or a company prefix for many barcodes.

Store-only items, online-only bundles and discontinued products exist in only one system. Each one should carry a skip flag, or the integration may create it in the other system.

Decide which system owns each product field

A product record is several fields with different owners, which is why the table at the top splits it into rows. A short till name written for a receipt should never replace the product title on your website. A long web description does not belong on the till screen either, where staff need a name they can read at a glance.

Square, which sells both the till and the online store, splits fields in a similar way. It keeps one item library for both channels. An item's name, variations and regular price are entered once. They then appear at the register and on the website, while online sale prices stay on the website only. With stock tracking turned on, Square updates stock from in-person sales and from Square Invoices. Orders shipped from the online store update it too.

Stock needs a second split, between what is on the shelf and what can still be sold. Adobe Commerce, for example, places a reservation when an order is submitted and deducts it from the salable quantity. The physical quantity at the source drops only when the order ships. An integration that sends one stock number to the POS has to say which of the two it sends. Staff who count a shelf compare it with the physical number. The website should show the salable number, so it does not sell units already promised to an order.

The integration should write only the fields its source system owns. A sync that sends the whole product record overwrites the other system's fields. The next sync in the opposite direction may then write the old values back, and the two systems keep trading edits.

Decide which system owns stock

Stock is where most retail POS ecommerce integration projects go wrong. The store sells the last unit at the counter, the website still shows one in stock for a few minutes, and an online customer buys it.

You have three common ways to handle this:

• One owner, others read. The POS or a central inventory system holds the count. The website reads it and never writes its own number. This is the simplest rule to reason about.
• Safety buffer online. The website shows stock minus a buffer per location, so a short sync delay does not cause an oversell. You trade some lost online sales for fewer cancellations.
• Reservations. Online orders place a hold on stock at a location until they are picked or cancelled. This needs the POS to respect holds, which not every POS can do.

Write the rule down for the awkward cases too. What happens when the counter sells an item the system says is out of stock? Some retailers allow it and reconcile later, because the item is physically in the customer's hand. What happens when an online order is allocated to a store that then finds the item damaged? Decide whether it moves to another location, waits, or gets cancelled, and who is told.

Track stock by location, not as one total. Store pickup, ship-from-store and accurate online availability all depend on knowing where the units are.

Three integration patterns

Most ecommerce integration with POS falls into one of three patterns. Each fits a different situation.

Check the native option first. If both systems already support each other and the connector handles your stock rule, returns and gift cards, that is usually the cheapest path. Move to middleware or custom work when you hit a specific limit, and write that limit down so you can test whether the new approach actually solves it.

Orders, returns and refunds across channels

Customers will buy online and return in store, and the reverse. A good integration lets staff at the counter find the original order, whichever channel it came from.

That means a few things in practice:

• The POS can look up online orders by order number, email or receipt.
• A return records which items came back, to which location, and whether they are resaleable, so stock goes to the right place.
• The refund goes back through the system that took the payment. A card charged online usually has to be refunded through the online payment provider, not the store's card terminal.
• The original sale stays on record. A return or cancellation should add reversing entries, not edit or delete the original, so your reports still match what happened on the day.

Exchanges are where these rules get tested hardest, because they combine a return, a new sale and sometimes a price difference. Walk through a few real exchange scenarios with store staff before you build.

Customers, gift cards and loyalty

Customer records are easy to duplicate. Someone shops online with one email and gives a phone number at the till, and now you have two people. Decide on a matching rule (email, phone or loyalty number) and what happens when two records match.

Gift cards and loyalty points need a stricter rule than stock. Selling one unit too many is a nuisance you can fix later; letting the same gift-card balance be spent twice, once online and once in store, is lost money. Keep one balance ledger, and check and deduct the balance in a single step, so two channels cannot both trust the same old balance.

Failure handling: duplicates, ordering and reconciliation

Every sync will fail sometimes. Networks drop, APIs rate-limit, and one system goes down for maintenance. Plan for three problems.

Duplicates. Events can arrive more than once. Shopify's webhook guidance, for example, tells developers to ignore duplicate deliveries using a webhook ID. If your integration creates a sale or an order each time it sees a message, a duplicate becomes a double sale. Make each write safe to repeat. Payment APIs use the same idea: Stripe's idempotency keys let a client retry a request after a connection error without creating a second object.

Out-of-order events. Shopify also states that it does not guarantee ordering within a webhook topic, so an update can arrive before the create it refers to. Use timestamps or version numbers, and ignore an update that is older than what you already hold.

Missed events. Shopify notes that webhook delivery is not always guaranteed and recommends reconciliation jobs that periodically fetch data. That advice applies to any POS integration. Run a scheduled job that compares stock and order totals between systems, fixes the safe differences automatically, and flags the rest for a person.

Then make failures visible. A queue of failed syncs that nobody checks is how a website ends up selling stock that left the shop floor yesterday. Alert on sync failures and growing backlogs as well as outages.

Go-live test before you switch on

Each rule in this guide can be tested with a real transaction before customers depend on it. The tests run first in a staging setup, then with a small set of products in one store. Each one has an expected result, and the result you actually saw goes into a test record next to it.

The offline test depends on how your POS behaves. Shopify says a POS device that was offline should sync its orders and stock on its own once it reconnects. Staff can also start a manual sync. Shopify also says Bluetooth and USB barcode scanners keep working offline while connected to the device. The scan test can therefore run in both modes.

The tests stay useful after launch. An update to the POS, the store platform or the connector can change what syncs, so the same tests should run again after each update.

An example from a POS we built

We built a browser-based point-of-sale system for a private client. It is a till rather than an online-store integration, but its design applies several of the rules above. You can read the retail sales, inventory and point of sale case study for the full write-up.

A few of its rules are directly relevant to integration design:

• One transaction for the sale. Saving a sale wrote its lines, payments, taxes and stock movements in one database transaction. If any part failed, everything rolled back, so the reports and the counter never described different sales.
• Different rules for stock and stored value. The till allowed a sale even when stock showed a warning, for the item already on the counter, and staff reconciled the discrepancy afterward. Gift-card and loyalty spending ran through a conditional update that deducted the amount only while enough balance remained, so two tills could not spend the same balance.
• Returns by receipt. A receipt number found the original sale for a return. A cancellation kept the original sale and added reversing stock movements.
• Card payments stay on the terminal. Card charging happened on a separate terminal, and the till recorded the terminal's reference instead of processing the card itself.

If you connect a till like this to an online store, those are the boundaries the integration has to respect: do not split a sale across partial writes, do not let a sync bypass the balance check, and refund through the system that holds the payment.

When a custom integration is justified

Custom work costs more to build and you will own its upkeep, so it should solve a problem you can name. It is usually justified when:

• Your POS has an API but no maintained connector for your ecommerce platform.
• You need a stock rule the connector cannot express, such as per-location buffers or reservations for store pickup.
• Gift cards, loyalty or store credit must share one balance across channels, and the connector syncs them on a delay.
• An ERP or warehouse system also owns part of the data, and you need one place to decide conflicts.
• You need monitoring, replay and reconciliation that the connector does not offer.

If none of those apply, a native connector or middleware is probably the better choice. Our API integration and development services page explains how we approach the custom case.

FAQ

What is ecommerce POS integration?

It is the connection between your in-store point-of-sale system and your online store, so products, stock, orders, customers and returns stay consistent across both.

Which system should own inventory?

Usually the POS or a central inventory system, with the website reading from it. Pick one owner and write down how you handle sales that happen during a sync delay.

Is real-time sync necessary?

Not for everything. Stock for fast-moving items and gift-card balances need to be close to immediate. Product content and reports can usually wait.

Can I process online returns at the store?

Yes, if the POS can find the online order and the refund goes back through the online payment provider. Plan how returned stock is assigned to the store's location.

What happens when a store goes offline?

It depends on the POS, and each vendor sets out its own limits. Shopify POS can keep selling offline, but it cannot sync orders or stock with Shopify admin until the device reconnects. Shopify lists several features that need a connection. These are the ones that affect an integration:

• returns, exchanges and voids
• selling or accepting gift cards
• finding, editing or adding customers
• discount codes and automatic discounts, but manual discounts still work
• fulfilling buy online, pick up in store (BOPIS) orders

Shopify captures offline card payments only after the device reconnects, so a declined card may show up later. It recommends reconnecting as soon as possible, ideally within 24 hours. It also warns that logging out or turning off the device might lose offline orders.

Square's offline mode does not support Square Gift Cards, and loyalty points have to be added by hand after the payments upload. The seller has 72 hours from the start of the offline session to upload the payments taken in it. Any payment still pending after that expires and cannot be recovered. An offline sale is complete at the till before its payment is final, so the integration can record a sale whose payment later fails. Square makes the seller carry the cost of any expired, declined or disputed offline payment. The payment also cannot be refunded until it has uploaded, so a refund to the card used for that sale has to wait for the upload as well.

On both platforms the merchant sets the limits for offline card payments. In Shopify, the merchant sets a daily total for each device and a limit for each order. In Square, the seller sets a maximum for each payment.

For the integration, the website keeps showing stock the shop has already sold until the queued sales arrive. A stock buffer for that location reduces oversells during the gap. When the sales do arrive, the integration should accept them with their original sale times and ignore any it has already recorded. The reconciliation job then catches whatever is left. While the store is offline, the till cannot check gift-card or store-credit balances against the shared ledger. A custom till has no built-in gift-card block like Shopify's or Square's. The team building it sets a rule in advance, either to refuse those spends offline or to accept them up to a limit.

Should I use middleware or build a custom integration?

Use middleware when several systems need connecting and the rules are fairly standard. Build custom when your stock, balance or conflict rules do not fit what the tools support.

For the wider picture of pricing, ordering and back-office sync, see our guide to B2B ecommerce best practices for pricing, ordering and ERP sync. Our ecommerce development for B2B and enterprise sellers and software for retail and commerce businesses pages cover what we build. When you are ready for a number, you can get a range for your integration project.