POS integration testing checks whether delivery-app orders reach the correct restaurant POS, branch, and kitchen workflow before a live rollout. A successful API connection alone does not verify item mapping, paid modifiers, Arabic instructions, financial reconciliation, or retry safety. This user acceptance testing (UAT) checklist gives Saudi restaurant operations, finance, and technical teams concrete scenarios, expected results, owners, and actions when a case fails. Use it for connected channels such as Jahez and HungerStation only where their integration features are supported.
What data must be checked in POS integration?
Define the data validation scope for each delivery platform and branch before placing test orders. A delivery order combines product identifiers, financial information, fulfillment details, and instructions; each field needs a named owner and an expected receiving-system result.
When using restaurant integrations, validate field mappings against approved connector documentation rather than assuming every field can be written to the POS database. Unmapped required data should produce a visible error and a traceable order reference.
Core data elements requiring rigorous verification include:
- Order and branch identifiers: Source channel, external order ID, connected merchant-store ID, POS branch ID, and relevant timestamps. Check that one branch cannot receive another branch's order.
- Financial details: Product and modifier prices, discounts, delivery charges, payment indicators, and applicable tax fields. Marketplace commissions and settlement deductions should be reconciled separately from customer order totals.
- Product identifiers: POS PLU or SKU, external item ID, nested modifiers, and location-specific availability. Confirm the connector's scope before assuming ingredient-level inventory synchronization.
- Special instructions: Verify that relevant kitchen notes and Arabic text survive transfer without truncation, while unnecessary customer information is not shared.
For a technical explanation of the architecture, see API integration for POS and delivery apps. This checklist focuses instead on pass/fail acceptance testing and safe release decisions.
Map items, modifiers and taxes
Reliable POS mapping means that each published delivery-app item and branch maps to a correctly identified POS item. An item name alone is not a safe identifier when brands reuse names, sizes, or product variations.
Testing teams must execute a three-point mapping audit:
- Product mapping: Test standard meals, bundles, beverages, and seasonal items against active POS identifiers and actual kitchen output. For one POS example, see Foodics integration for restaurant ordering. Provide a clear exception for any unmapped product.
- Modifier groups: Verify nested extras, required choices, size variants, and price adjustments on both the POS record and kitchen ticket.
- VAT and totals: Verify the restaurant's applicable Saudi tax and rounding configuration for taxable items, discounts, and relevant fees. Review ZATCA e-invoicing requirements with finance. Connecting a delivery channel does not automatically establish tax compliance.
How do you test modifiers?
Modifier cases are especially useful in UAT because a typical unmodified order may work while nested choices or special instructions fail. Test both accepted selections and invalid combinations under the menu's published rules.
To ensure robust modifier processing across delivery channels, test against the following rigorous scenarios:
- Free modifiers: Confirm a required but free choice displays correctly without changing the order total.
- Paid nested add-ons: Combine extras and size options; check each identifier and price, not only the final total.
- Selection constraints: Try an invalid combination in a controlled test and check for a visible, meaningful validation response.
- Arabic and English notes: Test “بدون بصل” and “صلصة على جنب” on real KDS displays or printers, checking font direction and character handling.
Accept, cancel and refund test cases
Run the supported order-state tests for each connected provider, including Jahez and HungerStation where approved. The expected transitions depend on the delivery API, POS, and restaurant configuration; do not assume every platform offers the same refunds or statuses.
- Accepted order: One supported, accepted order should reach the intended branch and kitchen without duplication. Measure timing against the agreed integration criteria, not an unsupported three-second promise.
- Cancellation before preparation: Cancel a test order and verify its POS and kitchen status without creating an extra ticket.
- Cancellation during preparation: Confirm staff receive the correct notification and can record what was already prepared; keep an audit trail.
- Partial refund: Verify the authorized POS or payment provider handles the refund and associated reconciliation; the integration itself may only transfer supported status updates.
What happens after cancellation?
Cancellations require coordinated state changes across the order channel, branch, kitchen, and financial system. A cancelled order should not remain an active kitchen job or silently disappear from accounting records.
Test these separate outcomes, subject to supported provider capabilities:
- POS status: Keep the original order reference and an auditable cancellation or adjustment state, using the POS's approved workflow.
- Kitchen alert: Verify that staff can see when preparation should stop. The exact screen banner or sound depends on the installed KDS.
- Inventory treatment: Restore reserved stock only if supported and appropriate before preparation; track consumed ingredients as waste where inventory accounting exists.
Retry and timeout simulations
Test how temporary network loss, timeout responses, repeated events, and invalid payloads affect pending orders. Run disruptive tests in a safe environment or controlled release window.
- Connection interruption: Simulate POS unavailability and confirm pending orders remain visible and can be recovered and reconciled. Queuing and retries are implementation-dependent.
- Duplicate event: Re-send one order reference and confirm the POS and kitchen process it once. The provider may use different response codes or deduplication methods.
- Invalid payload: Test an unmapped modifier or malformed message and verify it triggers a visible error without silently discarding later valid orders.
When is the system safe to launch?
Go-live readiness requires documented critical test passes and an accountable sign-off, not a promise of a flawless launch. Define acceptance and exception rules for every in-scope branch and delivery provider.
Go-live readiness criteria include:
- Catalog readiness: Every active item and mandatory modifier in the launch scope is mapped, or its exclusion is explicitly agreed.
- Representative load: Run realistic busy-period order volumes chosen for the business and investigate all lost or duplicate orders and reconciliation issues.
- Multilingual checks: Supervisors validate Arabic and English instructions on the production hardware.
- Front-of-house readiness: Cashiers and supervisors know order references, exception alerts, and the approved fallback procedure.
Go-live owner and rollback trigger
Assign a go-live owner authorized to pause rollout, plus technical, finance, and branch operations contacts. Set and document acceptable failure thresholds before the release.
Illustrative rollback triggers include:
- Sustained failed or missing order transfers above the threshold agreed with the business.
- Material price, VAT, or discount discrepancies identified during order reconciliation.
- POS, register, kitchen, or connectivity failures that prevent safe order handling.
The go-live owner should activate the tested fallback: suspend affected integrations where supported, avoid double order intake, use approved backup procedures, and reconcile outstanding orders before resuming. Do not promise recovery in a fixed time without testing.
UAT matrix: test case, expected output, owner and failure response
Use the matrix for every launch branch and supported channel. Record Pass / Fail / Not Supported, test order references, timestamps, and the outcome of each corrective action.
| Test scenario | System or channel | Expected result | Owner | Failure response |
|---|---|---|---|---|
| Standard order injection | Supported delivery app + POS | One accepted order at the correct POS branch and kitchen with matching totals | Integration lead | Inspect connector errors and branch IDs; stop rollout |
| Complex paid and free modifiers | POS + KDS | Modifier IDs, quantities and prices match the source order | Menu specialist | Correct mappings and rerun the test |
| Arabic preparation notes | Kitchen printer or KDS | Arabic instructions display legibly and completely | Branch supervisor | Fix rendering settings and retest |
| VAT, price and discount validation | POS + finance | Configured tax and item totals reconcile with source order | Finance lead | Review tax configuration and fee ownership |
| Pre-cook cancellation | POS + kitchen | Supported cancellation updates order status and staff workflow | QA engineer | Review event and status mapping |
| Partial refund or mid-prep cancellation | POS + payment workflow | Correct operational status and authorized financial record | Operations / finance | Escalate exception and reconcile source records |
| Network interruption | POS connection | Pending orders visible and safely reconciled after reconnection | Technical lead | Activate fallback and resolve pending queue |
| Duplicate request or event | Order hub + POS | One transaction and one kitchen ticket for the same order reference | Integration lead | Check deduplication and source IDs |
| Sold-out menu item | Menu integration | Correct branch and supported channels show availability change | Menu owner | Check mapping and republish settings |
| End-of-day reconciliation | POS + marketplace settlement | Sales reconcile with source orders after accounting for fees and timing | Finance manager | Investigate transactions, refunds and commissions |
To compare connector scope and operating responsibilities, review LYNNC integrations. Do not treat general vendor descriptions as proof of individual supported capabilities or latency.
POS integration UAT: final go-live decision
A reliable rollout begins with item and modifier validation, supported cancellation and refund scenarios, defined error recovery, and a documented fallback. The owner should only approve expansion when critical tests pass and remaining exceptions have been accepted.
The LYNNC restaurant operations platform offers connected restaurant operations. Confirm the POS, delivery channels, and supported synchronization functions during onboarding, then test the agreed workflow before production.
Simplify POS Integration: Discuss restaurant POS integration testing with LYNNC to review supported channels, branch mappings, and an operational acceptance plan.
Frequently asked questions about POS integration testing
How do you test the POS and delivery-app integration flow?
Trace one order from the delivery app through the approved connector to the correct POS branch and kitchen. Validate order IDs, item selections, totals, and each supported status or error transition.
How should restaurant teams validate POS item mapping?
Match each live product and modifier to a stable POS identifier for the appropriate branch, then verify that sample orders appear correctly in register and kitchen records.
Which modifier and tax tests are required?
Test free and paid extras, selection limits, Arabic notes, discounts, and relevant VAT and rounding rules. The finance lead should sign off on material differences.
Which order statuses should be tested?
Verify the accepted order states supported by the connected provider, including acceptance, rejection, preparation, readiness, cancellation and completion where available, without inventing unsupported transitions.
How do cancellations and refunds affect the POS?
Test cancellation before and during preparation, then verify the supported order status and kitchen response. Confirm that any refund is executed and recorded by the responsible POS, payment, or accounting system.
What should trigger an integration rollback?
Use documented triggers for missing orders, duplicated tickets, significant financial mismatches, or a service-blocking outage. Activate an already rehearsed backup and reconcile pending records.
What should be monitored after POS integration goes live?
Monitor order counts, retries, errors, cancellations, kitchen tickets and financial reconciliation by branch and channel during the first operational shifts, and repeat focused tests after major integration changes.
