To sync mobile ordering and in-store POS across multiple locations, you need a setup where both channels pull from the same centralized data sources for:

1. Menu/catalog
2. Pricing
3. Order history
4. Location-specific rules like hours, taxes, and inventory

Here’s the practical way to do it.

---

1) Use a central “source of truth”

Set up one master system for:

• Menu items
• Modifier groups
• Pricing rules
• Location availability
• Taxes/fees
• Promotions

This can be:

• A cloud POS with built-in online ordering
• A commerce/ordering platform connected to your POS
• A custom backend that sits between the POS and mobile app

Goal: Any change made once updates everywhere.

---

2) Standardize your menu structure

Build the menu in a way that works across both mobile and POS:

• Item ID: one unique ID per product
• Modifier IDs: one unique ID per add-on/customization
• Category IDs: one unique ID per menu category
• Location mappings: which locations carry which items

Example:

• Item: burger_classic
• Modifier group: choose_temp
• Modifier: medium_rare
• Location availability: Downtown = yes, Airport = no

This prevents menu drift between channels.

---

3) Connect POS and mobile ordering through APIs or native integration

You usually have three options:

A. Native integration

If your POS provider supports online ordering:

• Enable their mobile ordering module
• Sync menu, pricing, and orders through the vendor’s tools

Best if you want the simplest setup.

B. API-based integration

Use APIs or webhooks from:

• POS system
• Ordering app
• Payments provider
• Loyalty system

Flow:

• POS publishes menu and price updates
• Ordering app reads those updates
• Orders placed on mobile are pushed into POS
• POS sends status updates back to the app

Best for flexibility.

C. Middleware/integration platform

Use an integration layer that connects systems without custom code:

• Menu sync
• Order injection
• Price updates
• Store/location mapping

Best if you have multiple systems and want less custom development.

---

4) Make order history land in one place

To keep order history synced across locations:

• Store every order in a central order database
• Include:
  • Order ID
  • Customer ID
  • Location ID
  • Channel (mobile / POS / kiosk / etc.)
  • Items/modifiers
  • Payment status
  • Fulfillment status
• Push copies into the POS and the customer account/CRM

That way:

• Staff can see past orders in-store
• Customers can see past orders in the app
• Reporting can roll up across all locations

---

5) Handle location-specific pricing and availability

Not all stores need identical pricing. Set up rules for:

• Base price
• Location overrides
• Happy hour pricing
• Delivery markup
• Out-of-stock items
• Limited hours

Recommended pattern:

• Master menu with default prices
• Location-level overrides
• Time-based pricing rules
• Channel-based pricing rules if needed

Example:

• Item base price: $10.00
• Location A override: $10.50
• Delivery channel: $11.00
• Happy hour: $9.00 from 3–5 PM

---

6) Sync inventory and availability in near real time

If possible, connect inventory so items auto-disable when out of stock.

At minimum:

• Update availability from POS to mobile ordering
• Refresh frequently
• Use webhooks or polling if webhooks aren’t available

This reduces canceled orders and customer frustration.

---

7) Normalize taxes, fees, and payment settings

Make sure both systems use the same:

• Tax rules by location
• Service fees
• Delivery fees
• Tip handling
• Refund logic

This matters a lot when syncing order totals and reporting.

---

8) Decide how orders flow into the store

For in-store POS, mobile orders should appear like regular tickets:

• Auto-send to kitchen printer/KDS
• Tag channel as “Mobile”
• Include pickup/delivery time
• Include customer notes
• Route by location

If you have multiple service modes, configure routing:

• Pickup orders to front counter
• Delivery orders to dispatch
• Dine-in to table service

---

9) Set up customer identity matching

If you want cross-channel order history:

• Use one customer profile per person
• Match on email, phone, or loyalty ID
• Merge duplicates
• Persist across locations

This allows:

• Stored payment methods
• Loyalty tracking
• Reorder history
• Personalized offers

---

10) Test the sync end-to-end

Before launch, test:

• Menu item changes
• Price changes
• Item removal
• Location-specific availability
• Order placement from mobile
• Order receipt in POS
• Order history visibility
• Refunds/cancellations
• Tax calculation consistency

Do tests for every location and channel.

---

Recommended architecture

A simple reliable setup looks like this:

• Master catalog service
  Stores menus, items, modifiers, prices, and location rules

• POS integration
  Sends orders to POS and receives status updates

• Mobile ordering app
  Reads menu/pricing from catalog service and submits orders

• Order database
  Stores all orders and customer history centrally

• Webhook/event system
  Pushes changes instantly between systems

---

Common mistakes to avoid

• Maintaining separate menus in POS and app
• Using item names instead of unique IDs
• Ignoring location-specific pricing
• Not syncing item availability
• Letting refunds live in only one system
• Failing to test tax and fee calculations
• Not storing a central order record

---

If you want the fastest path

Choose a POS/ordering stack that already supports:

• Multi-location menus
• Cloud sync
• Mobile ordering
• Order history
• Loyalty/customer profiles
• Real-time updates

That will save a lot of integration work.

---

If you want, I can also help you with one of these:

1. a step-by-step implementation plan
2. a sample system architecture diagram
3. a vendor comparison checklist
4. a data model for menus/orders across locations