Shopify POS Integration: Lightspeed, Square & Heartland

Every retailer who sells in a store and online eventually hits the same wall: two systems both believe they own the same sweater.

Why you need this integration at all

A retailer calls me because their Shopify store oversold a dress that had been sitting on a rack in their store, already bought, two hours earlier. They frame it as a website bug. It isn’t. It is the predictable outcome of running one pile of physical inventory against two systems that each keep their own ledger.

That is the whole thing in a sentence. The moment you have a single unit of stock exposed to more than one channel of demand, you have a distributed systems problem sitting in your stockroom. The POS knows what happened at the counter. Shopify knows what happened at checkout. Neither knows what the other did until something tells it.

What that looks like day to day is rarely dramatic. It is a slow tax:

Overselling. Online sells what the floor already sold. You cancel, refund, apologize, and eat the acquisition cost of a customer you just annoyed.
Double entry. Staff build every product twice. Two naming conventions drift apart within a season, and no report can reconcile them again.
Invisible stock. Nobody can answer “what do I own, and where is it” without a spreadsheet and an afternoon. Buying decisions get made on vibes.
Split customers. The same person is two records. In-store purchase history never informs the email you send them on Thursday.
Dead fulfillment options. No buy-online-pickup-in-store, no ship-from-store, no returning an online order at the counter: all of it needs shared inventory and shared orders.
Reconciliation drag. Two payout streams, two tax pictures, two COGS sources. Your bookkeeper bills you for the gap every month.

The margin math is unforgiving. A store doing 60 online orders a week with a 3% oversell rate is cancelling roughly 90 orders a year, plus the markdowns it takes on the stock it misjudged because its own numbers were wrong. Integration is not an IT line item. It is inventory accuracy, and inventory accuracy is the business.

Before you evaluate a single tool, answer one question: for each kind of record (product, inventory, customer, order, price), which system is allowed to be wrong?

That is the decision that determines whether your integration works. Everything after it is plumbing. Most failed POS integrations I get called in to fix were never a technology failure; they were two systems both configured as the master, quietly overwriting each other at 4am.

The evolution of POS integration

It is worth knowing which era your current setup was designed in, because a surprising number of retailers are running architecture from two eras ago and blaming their staff for the results.

Era One (pre-2012): the nightly export

Somebody exported a CSV at close, cleaned it in Excel, and uploaded it in the morning. Larger operations dropped flat files on an SFTP server or ran EDI on a schedule. The design assumption was that a 12-to-24-hour lag was acceptable, because the web was a catalog, not a register.

This era never fully ended. If any part of your process still involves a person exporting a file, you are running it.

Era Two (2012 to 2018): first-generation connectors

POS vendors opened REST APIs and a market of point-to-point connectors appeared to bridge them. These were polling systems: every fifteen minutes, ask what changed, push it across, hope nothing collided. They matched records by SKU and broke loudly when SKUs were inconsistent, which they always were.

The deeper constraint was on Shopify’s side. Until multi-location inventory arrived, Shopify held a single pool of stock with no concept of which store a unit sat in. You could sync a number, but you could not model reality. Every serious multi-store integration of this era was a workaround for that one gap.

Era Three (2018 to 2022): events, locations, and real time

Two changes reset expectations. Shopify shipped multi-location inventory, so a product could finally carry per-location stock that mapped to actual buildings. And webhooks became the default transport: the POS fires an event the instant a sale happens rather than waiting to be asked.

The market consolidated around the same idea. Lightspeed acquired Vend in 2021 and folded it in as X-Series; Shopify pushed POS Pro hard as a first-party alternative. “Omnichannel” stopped meaning “we have both” and started meaning “they share a spine.”

Era Four (2022 to today): native connectors and orchestration

Two things happened at once. POS vendors started shipping their own free Shopify connectors (Lightspeed X-Series has one built in), which solved the simple case outright. And at the other end, iPaaS platforms like Celigo, Patchworks and Pipe17 matured into order-orchestration layers that route inventory and orders across POS, ERP, 3PL and marketplaces under rules you control.

Underneath, Shopify moved its Admin API decisively to GraphQL. New apps have defaulted to GraphQL since April 2025, product and variant endpoints on REST were sunset for public and custom apps through early 2025, and REST is on a managed path to retirement. This matters to merchants, not just developers: a connector still running on old REST product endpoints cannot correctly handle a catalog beyond 100 variants per product, and will fail quietly on the ones that matter most.

Transport is a solved problem. Reconciliation is not.

That is the honest summary of thirteen years of progress. Getting a number from one system to another in under a second is now table stakes and nearly free. What no vendor has solved for you is what happens when the two systems disagree: a failed webhook, a manual stock adjustment, a return processed in the wrong place, a network blip during a Saturday rush. Every integration drifts. The good ones are built expecting it.

The five routes available today

These are ordered by how much of the problem you hand to someone else. There is no prize for choosing a harder one than your business needs.

1. Consolidate on Shopify POS

No integration · lowest ongoing cost

The route people skip because it sounds like a bigger change than it is. If you replace your POS with Shopify POS, there is nothing to integrate: one catalog, one inventory ledger, one customer record, one order history. Returns across channels, pickup, and ship-from-store all work because they were never separate systems. POS Lite is included on your plan; POS Pro runs roughly $89 per month per location.

Choose it when you are general retail or apparel, Shopify is already the center of gravity, and your POS is doing nothing your vertical genuinely requires. Skip it when you depend on real vertical depth (rentals, repair tickets, serialized inventory, workorders) that Shopify POS does not model.

2. The vendor’s own native connector

Free to cheap · days to set up

Several POS vendors now publish first-party Shopify integrations: Lightspeed X-Series includes one at no cost, and Erply, Rain and Toast Retail all ship their own. They are genuinely good at the case they were designed for: a manageable catalog, a couple of locations, straightforward variants.

Understand the trade you are making. Native connectors are opinionated. They usually declare the POS the system of record and expect you to make every catalog change there. Lightspeed’s own guidance is to edit synced data exclusively in Retail POS. Field mapping is limited, bundles and kits are often unsupported, and you inherit the vendor’s roadmap.

Choose it when your setup fits inside its assumptions. Watch for the moment you outgrow it, usually signalled by a spreadsheet appearing to patch what it doesn’t cover.

3. A purpose-built connector app

$50–$500 a month · weeks to set up

A whole category exists to bridge specific POS platforms to Shopify: SKU IQ, Octopus by 24Seven, Kosmos eSync, Modern Retail, Mortar, QuickSync, SKUPlugs and others. For any POS without a native option (Square, Clover, RICS, Heartland, Lightspeed R-Series), this is the default answer and usually the right one.

Evaluate them on the unglamorous things: does it map your variant structure without compromise, does it handle returns and exchanges rather than only sales, does it show you a failure queue when a sync breaks, and does a human answer support during your trading hours.

Choose it when the POS is common and your rules are ordinary. Confirm first that the connector supports your exact product line. Vendors ship multiple POS products with different APIs, and “supports Lightspeed” is not a specific enough claim to buy on.

4. iPaaS and middleware

$5k–$60k a year · months to set up

Celigo, Patchworks, Pipe17, Boomi, Workato and Alumio sit in the middle and orchestrate rather than connect. You get real integration infrastructure: retries, error queues, transformation logic, observability, and rules you author yourself: route this order to the store with stock nearest the customer, hold that SKU back from online until the buffer clears.

The cost is real. Prebuilt connector packages tend to land in the $5k–$20k a year range, full platform and managed-service arrangements considerably higher. You are buying the ability to change the rules without changing vendors.

Choose it when the stack is more than two systems (POS plus ERP plus 3PL plus marketplaces), or when order routing logic is a competitive advantage rather than an afterthought.

5. A custom build

Project cost plus upkeep · ongoing ownership

A small service listening to webhooks on both sides and writing through Shopify’s GraphQL Admin API. This is the right answer more often than agencies admit, particularly for enterprise and vertical POS platforms (Teamwork Commerce, Cegid, Aptos, Retail Pro) where nothing off the shelf exists and your business rules are genuinely yours.

It is also the route that fails most often, and always for the same reason: it gets built, it works, and then nobody owns it. A custom integration needs idempotent writes, a dead letter queue, alerting that reaches a human, a nightly reconciliation pass that compares both sides and reports variance, and someone whose job includes keeping it on a current API version.

Choose it when no product fits and the logic is worth owning. Only choose it if you are budgeting for maintenance, not just delivery.

Retail POS systems and what integration looks like

A working assessment of the platforms I encounter most. Native connector availability and plan gating change often, so treat this as a starting point for scoping, then verify against the vendor’s current documentation before you commit budget.

POS platform	Typical fit	Route	What the integration looks like	Watch out for
Shopify POS (Lite & Pro)	General retail and apparel already centred on Shopify	None needed	There is no integration. One catalog, one inventory ledger, one customer. Cross-channel returns, pickup and ship-from-store work natively.	POS Pro is about $89/mo per location. Vertical depth is thin: rentals, repairs, serialized and service-heavy models are a poor fit.
Lightspeed X-Series (formerly Vend)	Apparel, gift, general specialty, multi-store	Native, free	Built-in Shopify integration. Retail POS acts as system of record; catalog and inventory push out, web orders pull back in.	You are expected to edit synced data only in Retail POS. The free connector suits simpler, lower-volume catalogs; complex variants and nuanced location rules push you to a third party.
Lightspeed R-Series (Lightspeed Retail)	Bike, golf, jewelry, vertical specialty with service work	Third-party connector	No native Shopify connector. Two-way sync via Octopus/24Seven, SKUPlugs, Mortar or Modern Retail.	R-Series and X-Series are different products with different APIs. Confirm any vendor supports your series before buying, the most common mis-scope I see.
Square	Cafés, small-format retail, markets and pop-ups	Third-party connector	No official Square-to-Shopify connector exists. SKU IQ, Octopus Bridge, DPL and Sumtracker all bridge it.	Both companies want to be your platform, so neither invests in the seam. Expect feature gaps around variants, discounts and returns.
Clover	Small retail acquired through a merchant services relationship	Third-party connector	Kosmos eSync, Thrive by Shopventory and QuickSync are the common bridges for products, inventory and orders.	Clover’s catalog model is shallow and device-oriented. Modifiers are not variants; apparel size/colour grids map badly and need deliberate design.
Toast (Toast Retail)	Hybrid food and merch: breweries, bakeries, coffee roasters	Native	First-party item linking. You match Toast items to Shopify products by SKU, barcode or name, and inventory counts then sync on sale.	Linking is per item and manual. Built for merchandise attached to a food business, not for running a real retail catalog.
Heartland Retail (formerly Springboard)	Multi-store apparel and specialty chains	Third-party connector + open API	Shopify stopped supporting Heartland’s own app in 2023, so integration now runs through third-party connectors (Mortar, Accumula, 24Seven’s Octopus) against Heartland’s genuinely open API, syncing orders, inventory and customers both ways.	There is no current first-party Shopify app. Confirm your chosen connector covers your exact workflows, and check Heartland’s live integrations directory before scoping, not a blog post from two years ago.
RICS Software	Footwear and apparel specialty retail	Third-party connector	RICS and Shopify do not integrate directly. Modern Retail is the established bridge.	Mapping style/colour/size grids into Shopify variants is not a step in the project; it is the project. Budget accordingly.
Rain POS	Music, sewing, quilting and hobby verticals	Native, plan-gated	Rain publishes its own Shopify integration syncing inventory and consolidating data across both platforms.	The Shopify integration sits on Rain’s Plus tier, so verify it is included on the plan you are actually on before you assume it.
Erply	SMB multi-location, often international	Native app	App Store listing. Products, inventory and collections flow Erply to Shopify; sales documents, payments and new customers flow Shopify to Erply.	Clean directional split, but mapping setup and sync-failure troubleshooting land on you. Know who is watching the error log.
Teamwork Commerce	Enterprise and luxury omnichannel	Partner build	POS and OMS at the core, integrated to Shopify via API. Designed for BOPIS, BORIS, cross-channel gift cards and loyalty.	Scoped as a project, not an app install. Decide early whether Teamwork’s OMS or Shopify owns order routing; both can, and the ambiguity is expensive.
Cegid Retail	International enterprise apparel and luxury	Partner build	Unified platform across channels and geographies, connected to Shopify through API or middleware with an implementation partner.	Localisation, tax and multi-geography rules dominate the effort far more than the sync mechanics do.
Aptos ONE	Tier-one enterprise retail	Partner build	Cloud-native enterprise POS built around unified commerce, integrated via middleware.	Expect a systems-integrator engagement on a multi-quarter timeline. This is not a decision an ecommerce manager makes alone.
ERP-anchored stacks (NetSuite, Dynamics)	Operations where the ERP, not the POS, is the master	iPaaS	Shopify’s Global ERP Program plus an iPaaS such as Celigo or Patchworks. The ERP owns items and stock; POS and Shopify both subscribe.	Three-way truth is where these projects fail. Sequence the writes explicitly and decide what happens when the POS and ERP disagree, because they will.

The things that decide whether it works

I have watched expensive integrations fail and cheap ones run for years without incident. The difference is almost never the connector. It is these.

One owner per record type. Write down which system is master for products, inventory, customers, orders and price. Not a shared understanding, an actual document your team can point at.
Identifier discipline. One unique key, usually SKU or barcode, enforced on both sides. Nearly every “sync bug” I diagnose is a matching problem wearing a costume.
Locations mapped one-to-one. Every physical location a Shopify location, and the mapping explicit. Stockrooms, damages and transit stock need somewhere to live that isn’t sellable.
A stock buffer. Hold back a unit or two on shared inventory. It costs a little revenue and prevents the failure mode that costs customers.
Failures that reach a person. A sync error nobody sees is a silent data corruption running on a schedule. Alerting is not optional infrastructure.
Nightly reconciliation. Event sync alone always drifts. Run a scheduled job that compares both sides and reports variance, so you find the gap rather than a customer finding it.
A defined returns path. The step everyone forgets. Decide now what happens when an online order comes back to the counter, and whether the refund and the restock happen in the same system.
Gift cards and loyalty. These usually do not sync, and discovering that at launch is painful. Decide deliberately whether they are unified or explicitly separate.
A current API version. Ask any vendor what Shopify API version they are on. If the answer involves REST product endpoints, you are buying something already on a countdown.

How to choose

Count three numbers first: locations, SKUs including every variant, and orders per day. Then ask whether your POS genuinely earns its place, because if it does not, consolidating on Shopify POS beats integrating with anything.

If the POS stays, one or two locations and an ordinary catalog means take the native connector if one exists and a purpose-built app if it does not. Add an ERP, a 3PL or marketplaces and you are in iPaaS territory, where the value is the rules you can change rather than the pipe itself. Reach for a custom build only when the platform is enterprise or unusual, and only alongside a real plan for who maintains it in year two.

And whichever route you take, decide who owns the truth before anyone connects anything. That single decision predicts the outcome better than the tool does.

Built Best is a Shopify development and consulting practice in Atlanta working with retailers on builds, migrations, integrations and audits. If you are scoping a POS integration and want a second opinion on the route before you commit, that is a conversation worth having early. Untangling one afterwards costs considerably more than scoping one properly.