A multi-location jewellery business looks like one company from the outside. Operationally, each showroom was running its own pricing strategy with no coordination — and the consequences were compounding daily.

• 🏪 5 locations, 5 separate Shopify POS stores — each updated manually and independently. Gold rate applied 2 hours earlier at one showroom was still active at another, creating inter-location pricing inconsistency that customers could exploit by calling ahead to different stores.
• 💱 Dubai required AED pricing; India locations used INR — but the exchange rate came from a WhatsApp group. Staff used FX rates that were 2–6 hours stale, causing systematic margin errors on the Dubai store. On days of INR/AED volatility, every Dubai sale was priced on yesterday's conversion.
• 📋 Each location had different markup rules with no system to enforce them. Dubai carried an 8% higher making charge; the Jaipur showroom had a seasonal 5% festive surcharge. Both were applied from memory by store managers — inconsistently, and with no audit trail.
• 🧾 GST treatment was inconsistent across the India–Dubai boundary. GST at 3% applies to gold jewellery at Indian locations but not in Dubai — but the base price calculation treated all locations identically, causing persistent tax-inclusive vs. tax-exclusive pricing errors on the India stores.
• 🔍 No audit trail — price disputes were unresolvable. If a pricing discrepancy caused a customer dispute across locations, there was no way to reconstruct what rate was applied, when, and at which showroom. Every dispute became a trust problem, not just a pricing problem.

KLYX proposed a centralised pricing API — independent of any individual Shopify store — that all 5 Shopify POS locations subscribe to. Rather than each store managing its own pricing logic, the engine becomes the single owner of all pricing configuration across every location.

The engine holds each location's pricing config — currency, markup rules, tax treatment, and seasonal adjustments — as structured data. When gold rates update, the engine calculates the correct price for every location's rules and pushes to all 5 via Shopify's Admin API in parallel. No manual syncing. No per-location spreadsheets. No WhatsApp group exchange rates.

The key architectural choice: the pricing config is not stored in Shopify. It lives in the central engine, owned and versioned there. Shopify becomes a display and transaction layer — not a pricing source of truth. This separation is what makes multi-location coordination possible at all.

Every location runs the same formula against the same spot rate — but with its own local_markup, tax_adjustment, and FX_conversion values pulled from its config record. Location-specific rules are enforced programmatically — not from memory.

1. Mapped all 5 locations' pricing rules into a config schema. Each location record: {location_id, currency, markup_pct, making_charge_pct, tax_inclusive (bool), seasonal_rules[]}. This config becomes the single source of truth for all pricing logic — editable only through the admin dashboard, never directly in Shopify.
2. Built a central pricing API (Node.js, Railway) ingesting live MCX/COMEX gold rates and serving calculated prices per location on-demand and on a configurable sync schedule. The API is the only component that talks to the bullion feed — all 5 Shopify store connections consume from it.
3. Integrated Frankfurter API for real-time INR/AED exchange rates — updated hourly, replacing the WhatsApp group rate source entirely. The Dubai store's AED price is now always derived from the same base INR spot rate used by the India stores, converted at the current hourly FX rate.
4. Built per-location price calculators that apply each location's markup, making charge, currency conversion, and GST treatment independently using the same base spot rate. The Jaipur GST calculation and the Dubai AED conversion are separate code paths — neither can contaminate the other.
5. Implemented a multi-store sync worker. On each rate update cycle, the worker loops through all 5 Shopify store connections (each with its own API credentials stored securely in environment config) and fires productVariantsBulkUpdate in parallel — all 5 stores receive the new prices within the same 2-minute window.
6. Added a location override feature. Store managers can set a temporary local price adjustment — for example, +2% for a 3-day Diwali festive sale — that stacks on top of the central formula without altering the global config. Overrides expire automatically at a set date, reverting to the standard formula with no manual cleanup required.
7. Built a full audit log. Every price update recorded with: timestamp, gold spot rate used, FX rate used, formula version applied, and resulting price per variant per location. The log is queryable by date range, location, or variant ID — making any price at any point in time reconstructable in seconds.
8. Delivered a simple admin dashboard (Next.js) where the business owner sees all 5 locations' current prices side-by-side in a single view, triggers manual syncs outside the schedule, manages location configs and overrides, and reviews 30-day price history for any location or variant.

• The Dubai store's AED pricing was corrected from systematically wrong to accurate within the first sync cycle. The first run after go-live corrected prices that had been mis-converted for months — the difference was immediately visible in the side-by-side dashboard view.
• Location overrides allowed the Jaipur showroom to run its Diwali surcharge without any manual Shopify editing. The manager set the override in the dashboard; it applied automatically at the start of the festive period and reverted at the end — zero store-level Shopify Admin access required.
• First use of the audit log: settled a ₹12,000 customer pricing dispute. A customer claimed they had seen a lower price earlier in the day. The audit log showed the exact gold rate active at that timestamp, the formula version applied, and the resulting price — the dispute was resolved in under 3 minutes without any back-and-forth.

• Multi-location pricing requires a central truth — not distributed management. Syncing 5 stores manually means 5 independent chances for divergence every single update cycle. A central pricing engine with per-location config rules is the only scalable architecture once you have more than 2 locations. The complexity of distributed management compounds faster than the number of locations.
• Currency conversion must be live, not from a WhatsApp group. If your Dubai store is using yesterday's AED/INR rate while your Jaipur store is using today's MCX price, your cross-location margin reporting is meaningless — and your Dubai pricing is structurally wrong every day FX moves. An hourly FX API refresh costs essentially nothing compared to the margin errors it prevents.
• The audit log justifies itself in the first customer dispute. Before the audit log existed, the owner had no way to reconstruct what price was active during a specific transaction. The ability to answer "what was the price at 3:47 PM on March 12th at the Jodhpur showroom?" is worth the 2-day engineering build — and it pays for itself the first time a ₹12,000 dispute gets closed in 3 minutes instead of 3 days.