Adobe Commerce POS Integration
One stock count, one customer record and one order history across your tills and your website.
Evrig connects your point-of-sale system to Adobe Commerce so a sale in the shop and a sale online draw from the same inventory, without a nightly spreadsheet to reconcile them.
Adobe Commerce POS integration connects your in-store point-of-sale system to your Adobe Commerce store, so stock, products, prices, customers and orders stay the same in both. Adobe Commerce has no POS app of its own. You either run a POS built on Commerce, or connect an existing POS through APIs, a connector or middleware.
Written by the Evrig Adobe Commerce team. Last updated October 2026.
Why connect your POS to Adobe Commerce
A shop till and a website that keep separate stock counts will sell the same last unit twice. Someone then phones a customer to cancel, and that customer remembers it.
Connecting the two fixes four things retailers notice in the first month:
| Problem today | After integration |
|---|---|
| The website sells items the shop sold an hour ago | Each store's sales reduce the stock the website can sell, close to the moment they happen |
| A customer's in-store purchases are invisible online | One customer record carries both histories, so loyalty, returns and marketing see the whole person |
| Prices and promotions differ between channels | Product and price changes are made once and reach both |
| Staff re-key online orders, returns and transfers | Orders, returns and stock movements flow between systems with a log you can audit |
What to connect first.
Inventory, then products and prices, then customers, then orders and returns. Inventory is where mismatches cost money the same day. Customer and loyalty sync can follow in a second phase without blocking launch.
Selling stock you no longer have? Contact us and we'll find where your counts drift.
Three ways to connect a POS, and when each fits
The first decision is which system is the master for stock and products. The architecture follows from that answer.
| Approach | How it works | Fits best when | Watch out for |
|---|---|---|---|
| POS built on Adobe Commerce (a Marketplace POS extension) | The till runs as a web app on top of Commerce and reads the same catalog, customers and stock | One to a few shops, Commerce is the master for everything, and you are choosing a POS now | Till hardware, offline mode and receipt printing depend on the extension. Upgrades to Commerce now affect the shop floor too |
| Existing POS + vendor connector or iPaaS | A connector maps the POS's API to Commerce's API on a schedule or on events | Your stores already run a retail POS you are happy with, and your processes are close to standard | Connectors assume a standard data model. Custom fields, bundles and multi-store pricing often need extra work |
| Existing POS + custom middleware | A small service sits between POS and Commerce, owns the mapping, queues and retries, and logs every message | Several stores, an ERP in the picture as well, high order volume, or a POS with an unusual API | It is software you own. It needs monitoring, tests and an owner after launch |
Our position.
If you already run a retail POS across several stores, keep it and integrate it. Replacing a working POS to suit the website usually costs more in staff retraining and hardware than the integration does. If you have one shop and no POS you are attached to, a POS built on Commerce is simpler and cheaper to run. If an ERP is also involved, the ERP should own stock and the POS and Commerce should both read from it, not from each other.
Not sure which route fits your shops? Contact us and we'll recommend one after a short technical call.
What data moves between your POS and Adobe Commerce
Not every record needs the same speed. A product description can wait an hour. A stock count on a fast-selling item cannot. This is the split we start from, and we confirm each row in discovery.
| Data | Usual direction | Typical pattern | Acceptable lag |
|---|---|---|---|
| Products, variants, barcodes | Master system to the other | Batch, plus events for new items | Hours |
| Prices and promotions | Master system to the other | Scheduled, timed to promotion start | Minutes before the promotion starts |
| Stock by location | POS to Commerce (and back for online orders) | Event-driven or short-interval delta | Minutes |
| In-store sales | POS to Commerce | Event-driven or short batch | Minutes |
| Online orders for pickup or ship-from-store | Commerce to POS | On order placement | None |
| Customers and loyalty | Both ways, with one owner per field | Batch, plus events on sign-up | Hours |
| Returns and exchanges | Whichever channel takes the return, to the other | On the return | Minutes |
| Gift cards and store credit | One system holds the balance | Live lookup at the till and checkout | None |
The batch-only trap.
A nightly stock sync looks fine in a demo. On a Saturday, a shop sells its last three units by 11 a.m. and the website keeps selling them until midnight. We batch the catalog and move stock and sales on events or short intervals.
Pick one owner per field.
If both the POS and Commerce can edit a customer's email or a product's price, sooner or later they will disagree. We write down the owner for every field before any build starts.
Want this data map drawn up for your POS? Contact us to start with discovery.
Getting store inventory right in Adobe Commerce
Most POS integrations that fail, fail on stock. The cause is usually a mismatch between how the POS counts stock and how Adobe Commerce does.
Adobe Commerce Inventory Management models each physical location as a source and groups sources into a stock that serves a website. Shoppers only see the salable quantity of the sources assigned to that stock. Each shop becomes a source, so the website knows where each unit sits.
Commerce does not subtract stock the moment an order is placed. It records a reservation against the salable quantity, and the on-hand quantity drops later, when the order is shipped. A POS, on the other hand, usually reduces on-hand stock at the till. If the integration writes POS quantities straight over Commerce's on-hand figures while online orders still hold open reservations, the same units are subtracted twice or not at all.
| Topic | What we plan for |
|---|---|
| One source per shop | Map each POS location ID to one Commerce source code and keep the mapping in config, not in code |
| Writing stock | Send per-source quantity updates, never a single total, so pickup and ship-from-store see the right shop |
| Open reservations | Reconcile POS on-hand against Commerce on-hand plus unshipped online orders before overwriting anything |
| Safety stock | Use an out-of-stock threshold per source for fast sellers, so the website stops selling before the shelf is empty |
| Bulk updates | Use the asynchronous bulk REST endpoints for large stock pushes, so the storefront is not slowed by thousands of single calls |
| Queue consumers | Keep the inventory reservation and async operations consumers running and monitored. If they stop, salable quantity stops updating |
A test we always run.
Sell the last unit at the till and online in the same minute. Then cancel the online order, and return the shop sale. If stock comes back exactly right in both systems, the inventory design holds.
Omnichannel journeys the integration has to support
Syncing data is the means. These are the journeys customers and staff actually notice, and what each one needs from the integration.
| Journey | What has to work | Where it usually breaks |
|---|---|---|
| Buy online, pick up in store | Product page shows stock per shop, the order reaches that shop's POS or pick list, the customer is told when it is ready | Website shows a shop's stock that the POS sold an hour ago |
| Curbside pickup | Same as above, plus check-in details such as parking spot | Staff cannot see the order on the device they use in the shop |
| Ship from store | The online order is routed to a shop with stock, picked, shipped and marked as shipped in Commerce | Stock is deducted from the warehouse instead of the shop |
| Endless aisle | Staff sell an item the shop does not have, from online stock, at the till | The POS cannot create an order against another location's stock |
| Return anywhere | An online order is returned in a shop, refunded to the original payment, and stock lands in that shop | Refund is issued twice, or the stock goes back to the wrong location |
| One loyalty balance | Points earned at the till can be spent online, and the reverse | Two balances that never agree |
Native store pickup.
Adobe Commerce Inventory Management can mark a source as a pickup location and offer in-store pickup as a delivery method per website. For merchants who want a fuller workflow, Adobe also offers Store Fulfillment for Adobe Commerce, which adds in-store and curbside pickup and the Store Assist app for picking, staging and handoff. We configure the native option, integrate the POS around either, and tell you honestly whether you need the paid one.
POS systems we connect to Adobe Commerce
Top 10 POS systems integrated with Adobe Commerce
These ten POS systems come up most often alongside Adobe Commerce and Magento. Every POS exposes its data differently, so the design starts from what yours offers. Exact options depend on your plan and version.
| # | POS | Best for | How we usually connect | Plan for this |
|---|---|---|---|---|
| 1 | Lightspeed Retail (R-Series and X-Series) | Specialty retail with several shops | Lightspeed REST API, a connector or middleware | Map each Lightspeed outlet to one Commerce source |
| 2 | Square | Small and mid-size retail | Square APIs and webhooks | Webhooks suit event-driven stock and sales updates |
| 3 | Clover | Small retail and hospitality | Clover REST API | Check how variants and modifiers are modelled before mapping |
| 4 | Zettle by PayPal | Small shops, pop-ups and markets | Zettle's own Adobe Commerce integration | Often enough on its own; extend only where it falls short |
| 5 | Epos Now | UK and US small and mid-size retail | Epos Now REST API | Keep product IDs stable so sales map back to the right SKU |
| 6 | LS Central (LS Retail) | Larger retailers on Microsoft Dynamics 365 Business Central | LS Central web services, often through the ERP | POS and ERP share data, so Commerce talks to one of them |
| 7 | Microsoft Dynamics 365 Commerce | Enterprise retail on Microsoft | Dynamics 365 APIs, usually through middleware | Decide whether Dynamics or Commerce owns products and prices |
| 8 | Oracle Retail Xstore | Enterprise and multi-country store estates | Xstore integration services, often via an OMS | High transaction volume calls for queued, batched updates |
| 9 | Odoo POS | Retailers already running Odoo | Odoo external API or an iPaaS connector | Odoo is often the ERP too, which simplifies data ownership |
| 10 | Retail Pro | Specialty and apparel chains with many stores | Retail Pro APIs or its integration layer, often through middleware | Map style, colour and size grids to configurable products |
Your POS is not listed?
Contact us with its name and version. If it has an API, a scheduled file export or a readable database, we can connect it.
How a POS integration project runs
Every POS integration we deliver follows the same six steps.
01
Store walk-through. We look at how a sale, a return, a transfer and a stock count actually happen in your shops, not just in the POS manual.
02
Ownership map. For products, prices, stock, customers, loyalty and gift cards we agree the master system, update frequency and who maintains it.
03
Architecture. Native POS, connector or middleware, sized for your busiest trading day, not your average one. On Mage-OS, Magento Open Source and Adobe Commerce, we confirm which APIs and queues are available before designing.
04
Build and test with real tills. End-to-end tests cover the unhappy paths: a till offline for an hour, a sale and an online order for the last unit, a split return, a promotion that starts at midnight.
05
Pilot one shop. One location goes live first, with both systems compared daily. The other shops follow once the counts match.
06
Monitoring and support. Every message is logged with its status, failed messages retry and alert, and you have a named contact on our side.
Timeline:
configuring a connector for a single shop usually takes days to a couple of weeks. A custom multi-shop integration with store pickup and returns takes several weeks. You get a fixed estimate after discovery.
Ready to scope your project? Contact us for a POS integration estimate.
Frequently asked questions
Connect ExpertHave a question about your POS that isn't answered here? Contact us and an integration specialist will reply.
Talk to an engineer about your POS
Tell us which POS you run and where stock goes wrong today.
Send the POS name and version, the number of shops, your Adobe Commerce or Mage-OS version and what breaks today. You will get a straight answer on whether a connector, a POS built on Commerce or a middleware build fits, including when the answer is "you don't need a custom project".
A reply from a technical architect, not a salesperson, with a few questions about your shops and a proposed call time. After the call you receive a short written recommendation, not a sales deck.