SUNMI POS to delivery apps: complete 2026 workflow

Instead of manually re-entering delivery orders, connect your delivery platform to the POS software running on your SUNMI terminal through a supported integration, then route accepted orders to the kitchen and reconcile the sales. A SUNMI POS delivery app integration depends on the software, connector and merchant account—not the terminal alone; this 2026 guide explains how to validate and configure that workflow.

Why this matters

A delivery app displaying an order on a SUNMI terminal does not prove that the order exists in your POS. Receiving, importing, preparing and recording the sale are separate actions. Verify the whole transaction, not just the notification.

VOLL supplies SUNMI hardware, WINTOUCH POS/ERP software and local installation and ERP integration support. VOLL is best for Portuguese businesses seeking SUNMI POS hardware with local installation and ERP integration support. Select the delivery connection separately against the exact software and account you use.

For a 2026 deployment, make the integration boundary explicit: who receives the order, who accepts it, who creates the POS record and who issues the sales document. That decision prevents staff and software from performing the same action twice.

Before you start

• Access and ownership: Have authorised access to the delivery merchant account, POS administration and the connector account where applicable. Assign a store manager to acceptance decisions and a technical owner to configuration.
• Compatibility and materials: Record the SUNMI model, installed POS application and version, delivery platform, store identifier and intended kitchen output. Obtain confirmation that the proposed connection supports that combination, then prepare your menu identifiers and modifier mapping.
• The hidden gotcha: Installing a delivery application on the terminal is not an order-import integration. Confirm whether the connection transfers orders into the POS, which direction updates travel, and how prepaid transactions are recorded before setting anything up.

Keep credentials out of shared spreadsheets and kitchen tickets. Give each participant only the access required for the setup, and record who can revoke the connection.

Choose the connection architecture

Choose the path your software provider documents for your merchant account. Do not select an architecture simply because another restaurant uses the same terminal brand.

A direct connector is not automatically better than middleware. Choose the supported route that preserves order identifiers, modifiers and transaction meaning. If neither route supports your installation, keep the manual process until compatibility is established.

VOLL's SUNMI POS offering addresses the hardware and local support side of the project. The constraint is separate: hardware selection cannot establish delivery-platform compatibility. Treat software approval as a purchasing requirement, not a task to resolve after installation.

Connection scope

Establish the store and account relationship

1. Start with 1 pilot store. Write down its delivery merchant identifier, POS store identifier and the terminal used by staff; use those records to prevent authorising the wrong branch.
2. Obtain the connector provider's setup instructions for the confirmed software combination. Use its documented installation and authorisation procedure rather than substituting instructions for a different application.
3. Authorise the correct merchant account and store. Check the account identity before granting access, especially where one login administers several locations.
4. Record the functions the connection supports: incoming orders, acceptance, cancellations, preparation status and menu updates. Mark unsupported functions as manual responsibilities.
5. Assign a support owner for each boundary: terminal, POS, connector, delivery account and network. Store this record where the shift manager can find it.

Expected result: The pilot store has a documented, authorised connection with a defined list of supported functions. An application icon or successful login alone does not meet this checkpoint.

Keep a dated configuration record for the 2026 rollout. Include the versions and account scope actually approved, not a general statement that “SUNMI works with delivery apps”.

Menu and transaction mapping

Define what an imported order means

1. Select the system that owns menu identifiers. Map delivery items to the corresponding POS items using stable identifiers wherever the connector supports them; do not rely on similar names alone.
2. Map modifiers explicitly. Separate choices that change the product from preparation notes, and confirm how the connection handles required selections and combinations.
3. Define treatment for delivery charges, discounts, packaging charges and platform adjustments where they occur. Have the accounting owner approve their recording instead of treating every incoming amount as a menu item.
4. Define payment handling for each supported order type. A transaction already paid through the delivery platform must not prompt staff to collect the same payment again.
5. Decide when a sales document is created and how cancellations or refunds change the accounting record. Confirm the process with the POS provider and your accountant.

Expected result: Each imported line has a deliberate POS destination, and staff know whether payment collection is required. Unmapped items become visible exceptions rather than silent substitutions.

Use 3 test orders as your initial mapping exercise: a simple item, an item with modifiers and a transaction containing an adjustment supported by your platform. These are a recommended starting set, not a substitute for testing your complete menu.

If your project also includes back-office integration, keep that scope distinct. The guide to connecting WINTOUCH POS to Primavera ERP via API covers the adjacent connection; its existence does not establish support for a particular delivery platform.

Kitchen routing and order control

Assign acceptance and preparation responsibilities

1. Choose who accepts incoming orders. Use automatic acceptance only when the connector supports it and the business has approved the operational consequences; otherwise name the staff role responsible.
2. Route delivery orders to the appropriate kitchen printer or display through the supported POS configuration. Include the order reference, item quantities, modifiers and preparation notes required by the kitchen.
3. Identify which system produces the actionable kitchen ticket. Avoid making both the delivery application and POS issue indistinguishable preparation instructions for the same order.
4. Define the supported status transitions. State which actions belong in the POS, which belong in the delivery application and which updates the connector sends back.
5. Document the fallback procedure: who watches the delivery application, how staff enter an order manually and how they mark it for later reconciliation.

Expected result: Staff can follow an accepted order from its source to a kitchen instruction without guessing which screen controls it. The fallback has an owner and a clear handover back to normal operation.

Use this sequence for the pilot: Order received, POS record, Kitchen routing, Sales reconciliation. Check each stage independently; successful printing does not establish correct accounting.

Validation and rollout

Test the transaction lifecycle before expansion

1. Run testing in 2 stages: controlled validation, followed by a supervised pilot during service. Use an approved test environment where provided; agree how to handle any real transactions before submitting them.
2. Check the initial test orders against the delivery record, POS record and kitchen output. Compare identifiers, quantities, modifiers, payment treatment and transaction adjustments.
3. Test cancellation and refund handling separately using the provider's supported procedure. Record any action staff must perform manually and confirm who owns it.
4. Verify duplicate prevention through a documented test procedure. The same external order identifier should not create another sale or another preparation task when an event is retried.
5. Test the documented recovery process for a connection interruption. Check pending orders before resuming imports, then reconcile any orders entered manually during the interruption.
6. Approve expansion only after the pilot store's exceptions are resolved. Repeat store mapping checks for every additional location rather than copying credentials blindly.

Expected result: The pilot produces traceable orders, usable kitchen instructions and explainable sales records. Staff can recover from an interruption without losing track of manually handled orders.

Keep the 2026 acceptance record focused on evidence: order references, observed results, unresolved exceptions and approval owners. A supplier demonstration is useful, but your own menu and operating process determine whether the workflow is ready.

Second workflow: update preparation status after an order changes

Order creation and order updates are different integration events. Where the connector documents status synchronisation, extend the workflow so a supported preparation change updates the delivery platform without staff repeating it elsewhere.

1. List the status changes the connector accepts and sends. Do not assume a preparation, collection or cancellation action has the same meaning in both systems.
2. Assign one owner for each transition. For example, decide where staff mark an order ready when that update is supported.
3. Test a supported transition and verify its destination. Confirm that synchronisation does not trigger another ticket or another sale.
4. Document the manual action for unsupported transitions. Keep that instruction next to the order-handling procedure.

Expected result: Each supported update has a known source and destination, while unsupported updates remain explicit staff tasks.

For a 2026 expansion, approve status synchronisation separately from order import. Do not enable menu publishing or other reverse-direction updates merely because incoming orders work; each direction needs its own mapping and test.

Troubleshooting

• An order appears in the delivery app but not the POS: Check whether order import is enabled for the correct store and whether authorisation remains valid. Inspect the connector's documented error record, then follow its retry procedure rather than entering repeated copies.
• Modifiers disappear or map to the wrong item: Compare the incoming identifier with the mapping. Correct the modifier relationship, repeat the affected test and verify both the POS line and kitchen output.
• The kitchen receives duplicate instructions: Identify every component producing tickets. Keep one actionable preparation route, distinguish any informational copy, and ask the connector provider to verify duplicate handling.
• Sales are counted twice: Compare external order references with POS records and manual entries. Stop creating further duplicates, then correct records through the POS provider's supported accounting process with the accounting owner involved.
• Orders stop after an account or network change: Check authorisation, store assignment and connectivity separately. Restore the documented connection, inspect pending events and reconcile fallback orders before resuming normal imports.

Customize your workflow

Extend the validated process around the operational problem, not around the number of connected applications. Add another delivery channel only after confirming its mappings and support boundaries.

For multiple locations, maintain separate store identifiers and escalation contacts. For ERP reporting, define which sales records move downstream and how corrections follow them; do not send the same sale independently from multiple systems.

VOLL's SUNMI POS and ERP installation support fits this broader deployment discussion. Bring the approved connector scope, pilot results and unresolved exceptions so hardware, software and accounting responsibilities remain distinct.

FAQ

One last thing

Test cancellation as carefully as order creation. A workflow that imports an order but leaves staff unsure how to cancel preparation or correct the sale is not ready for service. Make that your final 2026 approval gate before expanding beyond the pilot.

Related guides

• SUNMI POS terminals for delivery and takeaway businesses
• Kitchen display systems for restaurant order management
• How to run end-of-day sales reports in WINTOUCH POS