Magento POS integration: architecture, sync patterns, and the problems that show up in production

Magento POS integration comes up when a merchant has both an online store and physical retail locations and wants them to operate from a single source of truth. The business case is clear — you don’t want to oversell because a register didn’t know the webshop already sold the last unit. The technical execution has some non-obvious failure modes that tend to surface well after launch.

This is what I cover when scoping or reviewing a Magento POS integration.

What a Magento POS integration actually connects

A POS system that integrates with Magento doesn’t replace Magento’s backend — it reads from it and writes to it via API. The register terminal (whether that’s an iPad, a dedicated terminal, or a browser-based app) communicates with Magento in near-real-time to:

• Pull product catalog, pricing, and inventory from Magento
• Create orders in Magento when a sale is completed at the register
• Update inventory in Magento immediately after each sale
• Apply customer-linked loyalty points, store credit, and discounts

From Magento’s perspective, a POS sale is an order like any other — it has a customer (or guest), line items, a payment method, and a store view. The order appears in the admin, flows through the same fulfilment pipeline, and affects the same inventory records.

This architecture is its strength: one catalog, one customer record, one inventory count. It’s also where the problems appear when the sync is unreliable.

Inventory sync is the critical path

Inventory is where POS integration is most operationally sensitive. If a customer buys the last item in-store and the website doesn’t know for 30 minutes, you may sell that item online and then have to apologise.

The sync model that works reliably:

Write-through on every sale. When the POS creates an order, it immediately calls Magento’s inventory API to decrement stock. The stock update is part of the transaction, not a background job.

Read from Magento for stock checks. When a cashier scans an item or a customer asks if something is in stock at another location, the POS queries Magento’s inventory in real time rather than relying on a local cache.

The temptation to cache inventory locally on the register — to reduce API calls and improve speed — introduces lag. A cache that’s 5 minutes old is usually fine. A cache that’s an hour old because the refresh job failed is how you oversell. If you cache locally, make sure the cache TTL is short and that cache misses (and failed refreshes) are visible and alerted.

Offline mode is not optional

Network connectivity in retail environments is less reliable than in an office. A POS that can’t process sales because the API is unreachable is a major operational problem — queues build up, customers wait, staff get frustrated.

Any POS solution for a physical retail environment needs an offline mode that:

1. Continues to accept sales locally when the API is unreachable
2. Queues those transactions securely
3. Syncs the queued transactions when connectivity is restored
4. Handles inventory conflicts that may have occurred during the offline period

The inventory conflict handling is the hard part. If your POS sold 3 units offline and another location or the website sold 2 more of the same SKU during that window, you may have a negative stock count when the offline transactions sync. The sync process needs explicit logic for this — either a hard stop that flags the conflict for manual review, or an automated adjustment that moves to zero and creates a discrepancy report.

Neither is perfect. The business needs to decide which failure mode is acceptable: sometimes selling something you don’t have, or sometimes declining a sale you could have made. Document the decision and configure accordingly.

Order flow from register to Magento

A POS sale creates a Magento order via the REST API. For this to work reliably, the order payload needs to be complete and correctly formatted — Magento’s order validation is strict, and a malformed payload can cause the order creation to fail silently on the register side if error handling isn’t robust.

Fields that frequently cause issues:

Payment method. The Magento payment method code in the order payload must match a method that exists and is enabled. POS solutions often use a custom payment method (e.g., pos_cash, pos_card) that needs to be configured in Magento before go-live. Don’t assume free or a placeholder method will work in production.

Store view assignment. If your Magento installation has multiple store views (different languages, different brands), orders need to be assigned to the correct store view. Confirm with the POS vendor how store view is determined and test with orders on each relevant store view.

Guest vs customer orders. If your POS captures customer email at checkout, it should link the order to the Magento customer account if one exists. If it creates a guest order instead, the customer won’t see the in-store purchase in their account history, and loyalty point accrual may not work. Test this explicitly.

Tax calculation. Magento calculates tax based on the customer’s shipping address (or billing address, depending on configuration). POS sales don’t always have a shipping address — the customer is standing in the store. Test that the tax calculation is correct for POS orders and that the tax zone applied matches what the register is calculating.

The stock sync drift problem

Even with a well-built real-time sync, stock counts between Magento and physical store systems drift over time. Manual stock adjustments made directly in the ERP or warehouse system don’t always propagate correctly. A receiving event in the warehouse adds 50 units, but the sync job that should update Magento runs into a timeout and silently fails.

The mitigation: a reconciliation process that runs daily or weekly, compares stock counts between Magento and the authoritative inventory source (usually an ERP or WMS), and flags discrepancies above a threshold. The threshold depends on the business — a 1-unit discrepancy on a high-volume SKU might be noise, while a 10-unit discrepancy on a low-volume SKU warrants investigation.

This reconciliation doesn’t need to be automated to be useful. A weekly report that surfaces the top 20 discrepancies and routes them to a stock controller is significantly better than discovering problems when a customer complains.

Extension selection

For Magento Open Source, the most common POS solutions are third-party extensions: Magestore POS, Webkul POS, and several others. For Adobe Commerce, there are additional options that leverage B2B and Commerce-specific APIs.

When evaluating extensions, the questions that matter most in practice:

What’s the offline mode implementation? Ask specifically how it handles inventory conflicts during sync. Vague answers are a red flag.

How does it handle Magento version compatibility? POS extensions touch a lot of Magento internals — order creation, inventory, customer accounts. They tend to break on major Magento version upgrades. Ask about the upgrade path and how quickly compatibility updates follow Adobe’s releases.

What’s the API rate limit strategy? A busy register can generate a lot of API calls. Make sure the extension batches where possible and handles 429 responses gracefully rather than failing immediately.

Does it support multi-warehouse inventory? If you have Magento’s MSI (Multi Source Inventory) enabled, the POS must be aware of which source to decrement when a sale occurs at a specific location. Single-source implementations won’t work correctly with MSI.

Going live

The problems that surface after go-live are almost always in edge cases that weren’t tested: a split payment (part cash, part card) on an order where the customer also wants to use a gift card; a return on an item bought online being processed at the register; a price override by a manager on a configurable product with a custom option.

Before go-live, run a scenario-based test covering at minimum:

• Standard cash sale, guest customer
• Card payment, linked customer account with loyalty points
• Split payment
• Discount applied at register
• Return of an in-store purchase
• Return of an online purchase
• Sale during simulated network outage (offline mode)
• First sync after network restoration, including inventory reconciliation

The offline mode test is the one most frequently skipped and the one that causes the most visible problems in production. Run it before launch, not after.