Quick answer
Synchronization is integration-specific. Decide which system owns menus, prices, availability, orders, payments, and status; then test each supported direction and recovery path.
Define the authoritative menu, order, payment, and status flow, then prove the exact integration under normal and failure conditions.
Evaluation criteria
- supported POS product, version, account, and territory
- menu, modifier, price, tax, and availability authority
- order injection and acceptance
- payment and refund responsibility
- status, cancellation, retry, and duplicate prevention
- monitoring, reconciliation, support, and fallback
A responsible sequence
- Confirm the exact supported integration.
- Document system ownership for every field and event.
- Configure authentication and mappings.
- Test create, update, cancel, refund, offline, retry, and duplicate cases.
- Train staff on monitoring and fallback.
- Review reconciliation after pilot orders.
Compare the available approaches
| Approach | What it is useful for | What must be verified |
|---|---|---|
| Native provider integration | Using an integration maintained by one product provider | Exact compatibility, supported directions, limitations, release ownership, and support path |
| Integration partner or middleware | Connecting systems through a third party | Data model, latency, retries, monitoring, fees, support boundaries, and failure ownership |
| Custom integration | Implementing a documented API workflow for a specific scope | API availability, engineering ownership, security, versioning, testing, observability, and maintenance |
Questions to settle before selection
Can POS and online orders stay in sync?
Turn the requirement into an acceptance test using the actual catalog, locations, users, payment setup, and fulfillment model; record the demonstrated result and owner in the implementation scope. Verify current provider documentation, plan, territory, fees, exclusions, implementation responsibilities, and contract terms before relying on the result.
Which system should own the menu?
No universal winner is established. Score each approach against supported POS product, version, account, and territory; menu, modifier, price, tax, and availability authority; order injection and acceptance; payment and refund responsibility; status, cancellation, retry, and duplicate prevention; monitoring, reconciliation, support, and fallback. Require dated evidence and a live workflow demonstration for every material requirement. Verify current provider documentation, plan, territory, fees, exclusions, implementation responsibilities, and contract terms before relying on the result.
Does synchronization work both ways?
Turn the requirement into an acceptance test using the actual catalog, locations, users, payment setup, and fulfillment model; record the demonstrated result and owner in the implementation scope. Verify current provider documentation, plan, territory, fees, exclusions, implementation responsibilities, and contract terms before relying on the result.
How are payment and refunds handled?
Turn the requirement into an acceptance test using the actual catalog, locations, users, payment setup, and fulfillment model; record the demonstrated result and owner in the implementation scope. Verify current provider documentation, plan, territory, fees, exclusions, implementation responsibilities, and contract terms before relying on the result.
What happens when the POS is offline?
Turn the requirement into an acceptance test using the actual catalog, locations, users, payment setup, and fulfillment model; record the demonstrated result and owner in the implementation scope. Verify current provider documentation, plan, territory, fees, exclusions, implementation responsibilities, and contract terms before relying on the result.
How should an integration be accepted?
Turn the requirement into an acceptance test using the actual catalog, locations, users, payment setup, and fulfillment model; record the demonstrated result and owner in the implementation scope. Verify current provider documentation, plan, territory, fees, exclusions, implementation responsibilities, and contract terms before relying on the result.
Discuss the operating model Use the current demo page to evaluate these requirements against a specific operating model; submitting elsewhere is not implied.