Restaurant POS Acceptance Test Kit for AI Phone Orders

Set up the run

Use the vendor’s approved POS and payment sandboxes or a test location with isolated order routing. Never send these scenarios to a live kitchen or a real payment card.
Record the store, test catalog version, provider configuration, currency, local timezone and agreed observation window. Use a fresh run reference per fixture and capture the clock time of each fault.
Set up the exact catalog values and fault conditions listed below, or document how you mapped them to your test system. Reset state between runs. Record a fault case as untested if the sandbox cannot reproduce the fault.
Match each run across the final readback, accepted POS order, kitchen output and applicable tender or handoff records. Redact identifiers before sharing evidence.

Evaluating a specific POS with Loman? Ask to see the order and kitchen ticket in a Loman demo.

Eight reproducible fixtures

POS-01 · Synthetic input

Pin the order to the right location

Sandbox setup: Two test stores share a display name. NORTH sells the lunch bowl for $12 under N-BOWL and routes it to NORTH-HOT. SOUTH sells it for $14 under S-BOWL and routes it to SOUTH-HOT. Disable tax in this fixture.
Steps: Call the test number mapped to NORTH. Ask for one lunch bowl for pickup at North. Confirm the final readback.
Expected outcome: One $12 NORTH pickup order with N-BOWL and one NORTH-HOT ticket. No order or ticket at SOUTH.
Evidence to retain: Final readback, POS order search for both stores, and station output showing the store and item identifiers.

POS-02 · Synthetic input

Honor a sellout after the readback

Sandbox setup: Set SP-SOUP available at $8 and TOM-SOUP available at $7. Use pickup, pay at store, and disable tax. The test catalog supports changing availability mid-call.
Steps: Ask for one special soup. After the first readback and before confirming, mark SP-SOUP sold out at the destination. Allow the configured sync window to elapse, then confirm. If asked for an alternative, choose tomato soup and confirm the revised readback.
Expected outcome: The sold-out soup is never accepted. The replacement is offered explicitly and only the confirmed $7 tomato soup is accepted and sent to the kitchen.
Evidence to retain: Timestamped availability change, both readbacks, POS line items and kitchen output.

POS-03 · Synthetic input

Enforce modifier limits and preserve line identity

Sandbox setup: A $10 bowl requires exactly one protein. Tofu is included and chicken adds $2. Pickles are included. Disable tax. Use two line items under the same base SKU.
Steps: Order two bowls. Ask for tofu and chicken on the first, then choose chicken only when asked to resolve the conflict. Order tofu without pickles on the second. Confirm.
Expected outcome: Two distinct preparations at $12 and $10, $22 total. The first has chicken and standard pickles. The second has tofu and no pickles. The kitchen sees which instructions belong to which bowl.
Evidence to retain: Item and modifier IDs, price breakdown, final readback and kitchen ticket showing two preparations.

POS-04 · Synthetic input

Retry after a committed order loses its response

Sandbox setup: Use an approved sandbox fault that drops the first order response after the POS commits. Use pay at pickup and a unique run reference. Record the request correlation ID if exposed.
Steps: Order and confirm one bowl. Trigger the response loss. Allow the documented retry or reconciliation path to finish. Search the POS and kitchen output across the full retry window.
Expected outcome: Exactly one accepted order and one production instruction. Any retry resolves to that order. The caller hears a confirmation only after the system verifies the accepted state.
Evidence to retain: Fault timestamp, attempt and reconciliation logs, destination order search results and kitchen output count.

POS-05 · Synthetic input

Reconcile a payment timeout without collecting twice

Sandbox setup: Choose a documented test tender and an $18 pickup order with tax disabled. In the processor sandbox, simulate an approved authorization whose first response is lost. Predeclare the provider’s capture point and recovery window.
Steps: Confirm the order and complete the sandbox tender flow. Trigger the lost response. Observe the recovery path before initiating any second payment attempt.
Expected outcome: One successful $18 authorization. On recovery, the POS tender and processor agree by the deadline, with at most one $18 capture at the declared capture point. If the configured workflow abandons the order, void the authorization before capture and tell the caller that the order did not go through.
Evidence to retain: Redacted payment event IDs and state changes, POS tender state, order status and caller-facing outcome.

POS-06 · Synthetic input

Detect a missing kitchen station after POS acceptance

Sandbox setup: A bowl routes to HOT and a bottled drink routes to COLD. In the test environment, suppress output at COLD after the POS accepts the order. Agree who owns recovery and how long to wait.
Steps: Confirm one bowl and one bottled drink for pickup. Verify the accepted POS order. Trigger or observe the COLD routing failure, then follow the documented recovery procedure.
Expected outcome: The accepted order contains both items. The missing COLD instruction is escalated to the named owner within the agreed window. Recovery delivers the drink instruction without sending the bowl twice.
Evidence to retain: Accepted order record, initial HOT and COLD queue checks, escalation record and final station outputs.

POS-07 · Synthetic input

Recover when a requested staff transfer goes unanswered

Sandbox setup: Configure the test policy to transfer a manager request to a staffed-role test number with a 20-second timeout and a recorded callback task as fallback. Use test identities only.
Steps: Start a pickup basket. Before confirming, request a manager to approve a substitution. Leave the transfer endpoint unanswered. Follow the configured callback flow.
Expected outcome: One callback task for the configured role contains the pending request and run reference. The caller receives the agreed fallback. No POS order, charge or kitchen ticket is created for the unconfirmed basket.
Evidence to retain: Transfer attempt and timeout, callback queue entry, caller-facing status and searches of the POS, tender and kitchen systems.

POS-08 · Synthetic input

Validate requested pickup time against local hours

Sandbox setup: Set the store timezone to America/Chicago, close at 9:00 p.m. local and accept scheduled pickups through 8:30 p.m. inclusive. Use a fixed sandbox call time of 7:00 p.m. local on November 12, 2026.
Steps: Ask to pick up one bowl at 8:45 tonight. If offered a valid slot, ask for 8:30 p.m. local and confirm it.
Expected outcome: The 8:45 p.m. request is declined. The readback, accepted order and kitchen fulfillment label agree on November 12 at 8:30 p.m. local (November 13 at 02:30 UTC).
Evidence to retain: Store timezone and cutoff settings, final readback, POS scheduled timestamp and kitchen fulfillment label.

Score the observed result

Mark pass when the expected outcome and its evidence both agree. Mark fail when the observed result differs, unverified when evidence is missing, or untested when you cannot execute the fixture. Report the counts separately. Resolve any wrong-store order, duplicate charge, missing ticket or failed escalation before approving that workflow.

The CSV leaves the observed outcome, result and evidence reference blank for your own run. To customize scenarios in your browser, use the editable acceptance-test builder. For destination-side checks, read the POS handoff guide.

Technical references

Square’s Orders API documentation shows how one POS represents locations, modifiers, payments and fulfillment. Its guide to safe retries explains why a lost success response can cause a duplicate charge. Use your own provider’s documentation to map those records and retry behavior.

For a specific integration example, Toast’s partner directory lists Loman for direct phone order placement. Use your own menu and configuration to verify what actually reaches the kitchen.

Book a Loman demo to review a fixture