A restaurant POS integration is ready for service when the team can trace an order from its source to the POS and kitchen, verify its contents and total, and recover a failed transfer without losing or duplicating the order. A successful connection screen alone does not prove any of that.
Before launch, agree on the scenarios that must pass, who will check each result, and what happens when a case fails. Run practice scenarios without real card charges, guest messages, or courier dispatches. Then use a controlled live service pilot only after the practice checks pass and the team has a recovery plan.
1. Define the integration boundary
Start with the specific connection you are buying or enabling. This is not a full POS replacement checklist. The question is whether information crosses one boundary correctly: for example, from an online ordering source into the POS and onward to the kitchen.
Write down the source system, destination system, restaurant location, and order channels in scope. If you have two locations, treat each as a separate route until both have been checked. A menu mapped correctly at one store does not prove that the other store has the same mapping.
For every route, agree on which fields should arrive and where staff should see them. At a minimum, consider:
- A unique order identifier and the receiving location.
- Order type, such as pickup or delivery, and the promised time if used.
- Items, quantities, required modifiers, optional modifiers, and preparation notes.
- Item prices, discounts, fees, tax, and the final total.
- Payment status and any reference staff need to reconcile it.
- Order status, cancellations, changes, and refunds, if those are meant to cross the connection.
For each field, name the source of truth. If the online menu changes, does the POS receive the change, or must someone update both systems? If an item is unavailable, which system controls availability? Ask the providers to show the actual direction and timing of each update rather than assuming the connection works both ways.
Also agree on boundaries that do not apply. A connection may transfer new orders but not later edits. That can be acceptable if the team has a workable manual process. Record the limitation and the person responsible for it before service begins.
When reviewing restaurant integrations, confirm the exact source, POS, and location. Availability and setup can vary, and a connection listed on request should not be treated as already enabled for your restaurant.
2. Trace normal orders and menu changes
Give every practice order a unique identifier that staff can find in both systems. Record the identifier, time sent, expected result, and actual result. Follow the same order through the source, the restaurant POS, and the kitchen display or ticket used at that location. One source order should produce one intended POS order and one intended kitchen result, not two copies or none.
Hypothetical example: A pickup order labeled TEST-101 contains two $12 bowls. One bowl has a required protein choice and a $2 extra; the other has a different protein choice and no extra. The order also has a $3 discount, a $1 service fee, and $2 tax. The expected total is $24 + $2 - $3 + $1 + $2 = $26. This example includes those listed charges only; it excludes delivery fees and tips.
Check that both bowls reach the right location, each protein choice stays with the correct bowl, and the extra is attached once. Confirm that the POS total is $26 and that the kitchen receives the preparation details it needs. Separately check that the payment status matches the simulated payment state. A matching dollar total is not enough if the kitchen gets the wrong modifier.
Run another order with multiple quantities of the same item, a preparation note, and the order type you expect to use most often. If delivery is in scope, simulate the order and check the delivery-related fields without sending a courier. If your workflow includes scheduled orders, check that the intended time is visible to the people preparing them.
Next, change one menu item in the system agreed to control it. Mark it unavailable, then check the expected result at the ordering source and destination. Try an order containing that item using the agreed practice method. It should be blocked or handled according to the documented workflow; it should not silently become an order for something else. Restore availability and confirm the team can see the change.
Repeat with a price or modifier change where supported. Record how long the change takes to appear and whether staff must refresh or update another system. Compare that behavior with the timing you agreed is acceptable for service.
3. Rehearse failures, changes, and recovery
Normal orders are only half the decision. Ask the provider how to simulate a failed transfer safely. The goal is to see what staff would notice, where the order remains visible, and who takes the next action. Do not interrupt a live service connection just to create a failure.
For a simulated transfer failure, check the alert or error view the team is expected to monitor. Record who receives the alert, how quickly staff are expected to act, and how they find the source order. If no automatic alert is part of the setup, agree on a manual monitoring interval and owner.
Practice recovery with the same test identifier. Does the agreed process retry the transfer, require a manual resend, or require staff to enter the order in the POS? Before retrying or entering anything, check whether an earlier attempt arrived late. After recovery, reconcile the source, POS, and kitchen records so the team does not prepare the same order twice.
Run a duplicate check as well. Simulate the agreed resend or retry path and verify that the team can identify any duplicate before preparation. If prevention is not part of the connection, document how staff will detect and resolve duplicates. The pass condition is the agreed control working, not an assumption that every system handles retries the same way.
For a changed or canceled order, first establish whether updates are supposed to transfer. If they are, check that the destination shows the change clearly and that kitchen staff can act on it. If they are not, practice the manual handoff: who contacts the kitchen, who updates the POS, and where the action is recorded. A supported change that disappears is a failure; an intentionally unsupported change is a limitation that needs an agreed workaround.
Finally, walk through a simulated refund or adjustment. Confirm where the refund is initiated, what appears in each system, and how the owner reconciles any difference. Do not assume a refund in one system automatically updates every other system. Use a simulated transaction rather than a real card payment.
4. Record results and set the go-live rule
Use one checklist for each location and connection. Replace the example owners below with named people before testing. A pass means the observed result meets the agreed criteria. A fail means it does not, including when the team cannot tell what happened. Keep the test identifier and evidence location with each result so a provider can investigate.
| Scenario | Pass | Fail | Owner |
|---|---|---|---|
| Normal order with required modifier | One matching POS order and kitchen result; items, modifier, location, and total are correct. | Missing, duplicated, misrouted, or incorrect details. | Shift lead |
| Item marked unavailable | Availability changes as agreed; a practice order is blocked or handled by the agreed process. | Unavailable item is silently accepted or changed. | Menu manager |
| Failed transfer and recovery | Staff find the failure, recover the order, and reconcile for duplicates. | Failure is hidden, owner is unclear, or recovery creates an unresolved duplicate. | Integration owner |
| Change, cancellation, or refund | Update appears as agreed, or the documented manual handoff is completed and recorded. | Expected update is missing or the workaround cannot be completed. | Manager on duty |
Keep an exception register beside the checklist. For each failure or accepted limitation, record the affected route, test identifier, impact, workaround, owner, target resolution date, and retest result. For example, if an order edit does not transfer, the register might assign the manager on duty to notify the kitchen and update the POS manually. The manager must confirm that the process is practical during a rush, not merely possible when the restaurant is empty.
Set the go-live rule before reviewing results. A sensible rule is that every critical order, payment-status, and kitchen-routing scenario passes at each participating location. Any remaining exception must have an owner and an approved workaround. If an order can vanish without detection, route to the wrong kitchen, or be duplicated without a usable recovery process, hold launch until the problem is resolved and retested.
After practice checks pass, a controlled live service pilot can expose operational issues that simulations cannot. Choose a limited location, channel, and time window; brief the staff; monitor source and destination records; and designate someone who can pause the connection or use the agreed fallback. Live orders may involve actual guests and payments, so use normal operating controls rather than treating them as practice transactions. Review discrepancies before expanding the rollout.
5. Take the checklist to the provider
Bring your system names, locations, order channels, field list, and acceptance checklist to the buying conversation. Ask the provider to identify which scenarios the connection supports, how failures are surfaced, and what your staff must do manually. Get the setup and recovery responsibilities in writing.
If direct ordering is part of the route, review the restaurant online ordering workflow alongside the POS destination. Request a demo of Fleksa restaurant integrations and bring your requirements and test cases so the discussion stays focused on the connection you need.
Frequently asked questions
What is the most important POS integration acceptance test?
Trace a uniquely identified order from source to POS and kitchen. Verify that it arrives once, at the correct location, with the right items, modifiers, total, and payment status.
Can an integration launch with an unsupported scenario?
Possibly. Record the limitation, assign an owner, and approve a practical workaround. Do not launch if the limitation leaves a critical order or payment issue without a reliable control.
Should every location be tested?
Yes, for each route included in the launch. Locations can have different menus, mappings, or workflows, so record results and ownership separately.
