2026-09-17 Author : ZCS
An Android POS for courier drivers should connect the parcel, recipient, payment and delivery status in one controlled workflow. A basic card reader may collect money, but it cannot necessarily scan the shipment, capture proof of delivery, print a receipt or tell the dispatch system which order was completed. Courier operations need a mobile terminal that can run the delivery application and give drivers access only to the functions required on their route.
The terminal should help a driver answer four questions at every stop: Is this the correct parcel? Is this the authorized recipient or location? Has the required amount been collected? Did the central system record the final delivery status? Hardware selection therefore begins with the courier workflow, not with a list of payment methods.
Postal operators planning counter and field intake can also review this guide to a POS terminal for postal and parcel collection services. The two workflows share scanning and receipt requirements, but a collection counter often needs a larger screen and customer-facing confirmation.
Document each step from route download to end-of-day settlement. A typical driver signs in, downloads an assigned manifest, scans parcels into the vehicle, navigates to each address, confirms the parcel identifier, records the recipient, collects any cash-on-delivery amount, issues a receipt and uploads the outcome. Failed delivery, partial payment, return-to-sender and damaged-parcel cases need their own status codes and evidence rules.
The POS application should prevent a driver from charging an amount that does not match the shipment record unless a supervisor-approved workflow allows it. It should also prevent the same shipment from being marked delivered twice. Unique parcel and transaction references let customer service trace a case without relying on the driver's memory or a paper note.
Barcode or QR scanning should be fast enough for repeated use and should recognize the symbologies printed by the courier and its marketplace partners. Camera-based scanning may be adequate for clear labels, while an infrared or dedicated scan module can be useful where labels are small, damaged or scanned in poor light. Test real labels rather than a clean sample generated for a demonstration.
Proof of delivery may include a recipient name, signature, delivery photograph, one-time password or identity check. These controls should follow local privacy rules and the courier's risk policy. A camera or fingerprint option does not automatically create a compliant proof-of-delivery system; the application must capture consent where required, protect the evidence and link it to the correct parcel event.
Courier routes frequently cross areas with weak cellular coverage. The terminal should show whether an event has reached the server, is waiting to upload or has failed. A locally captured delivery record needs a timestamp, parcel reference and tamper-resistant queue so it can synchronize when connectivity returns. Drivers must be able to distinguish a saved event from a server-confirmed event.
GPS can support route visibility and location evidence, but it should not be treated as proof that the parcel reached the recipient. Urban canyons, indoor locations and disabled location services can reduce accuracy. The business should define when location is collected, who can see it and how long it is retained. Offline maps or cached route data may be more valuable to drivers than continuous tracking.
Cash on delivery creates two linked records: the parcel outcome and the money collected. The system should bind both to the same order, show the exact amount due and record the payment method. For cash, the driver needs a running collection total and a controlled handover process. For cards or QR payments, the app needs a final response from the payment service and a way to check uncertain transactions before retrying.
A payment screenshot or a customer's message is not reliable settlement evidence. The application should confirm the transaction against the payment provider and preserve the provider reference. Refunds, tips, delivery surcharges and currency differences should be explicitly supported or blocked. End-of-route reconciliation should separate cash, card, QR, failed, reversed and pending items.
A built-in printer allows the driver to issue a receipt without pairing a separate device. The receipt should show the courier, parcel number, collection amount, payment method, transaction reference, date and final status while masking sensitive card or identity data. Paper width, roll availability, printing speed and replacement steps should be tested during a full route.
Some courier workflows also need a return label or collection label. A standard thermal receipt printer is not automatically a label printer. Confirm the media type, adhesive stock, print width and application commands for the intended label. If labels are essential, order and test the exact printer configuration rather than assuming that any 58mm mechanism will work.
The ZCS Z92 Smart POS Terminal brings the functions a courier uses repeatedly into one handheld device. Drivers can run the delivery application on Android 13, use 4G and GPS while moving between stops, scan parcel codes with the optional infrared module, and print a 58mm receipt at the customer’s door. This reduces the need to carry a phone, separate scanner and mobile printer.
The 5.5-inch screen is large enough to review the parcel, COD amount and delivery result without making the terminal cumbersome on a route. A hand strap and silicone case are available for frequent field handling, while the 3020mAh/7.4V battery should be tested against the courier’s real route length, scanning frequency and printing volume. Z92 works best when the courier application connects these hardware functions to dispatch, proof of delivery and reconciliation in one guided workflow.
Each driver should use an individual account. Shared credentials make it difficult to investigate missing parcels or cash differences. Device enrollment can bind a terminal to the courier application, restrict unapproved apps, enforce screen lock and remove access when a device is lost. Payment keys and sensitive credentials should use the controls required by the payment provider.
A terminal management platform can help operations teams monitor app versions, device status and remote updates across a distributed fleet. Review ZCS information about terminal management support alongside the delivery software requirements, because device health records and parcel financial records serve different purposes and should remain in their appropriate systems.
Battery performance should be measured with the production application, normal screen brightness, cellular communication, repeated scanning and the expected number of printed receipts. A capacity figure alone cannot predict a route. Cold or hot weather, poor signal and an aging battery can reduce practical runtime. Define a minimum charge at dispatch and provide an approved vehicle charger or power bank where routes exceed one shift.
Drivers often hold a parcel, terminal and pen at the same time. A hand strap or protective case can reduce drops, while a base can simplify charging at the depot. Test one-handed scanning, camera framing, paper replacement and payment presentation with gloves or wet hands where relevant. Mounts and cables must not interfere with safe driving; transactions should take place only when the vehicle is safely stopped.
The same device should guide failed-delivery and return workflows. Require a reason code, permitted evidence and the next parcel status. If a customer refuses a COD parcel, the application should close the collection attempt without creating a payment receivable. If a payment was taken before a delivery is cancelled, the refund or reversal must reference the original transaction.
Customer service needs a timeline that connects route assignment, scan events, proof of delivery and payment status. Device logs can help diagnose a technical failure, but the courier platform should remain the authoritative parcel record. Restrict manual status changes and require supervisory review for events that could release COD funds or remove driver liability.
Integrate the terminal with the dispatch platform, parcel database, customer notification service, payment provider and finance reconciliation process. Define which system owns the delivery status and which owns the payment status. Retry logic must be idempotent so that resending a request after a network interruption does not duplicate a charge or delivery event.
Pilot with several route types: dense urban drops, rural travel, apartment buildings, business collections and high-COD routes. Measure scan success, payment success, average stop time, battery remaining, synchronization delays, paper use and support calls. Review exceptions with drivers before changing hardware or workflow.
Q1.Can a courier POS work offline?
It can capture approved events locally when the application is designed for offline use, but a card or account transaction may still require online authorization. The screen must show whether each event is pending or confirmed.
Q2.Does the Z92 include a barcode scanner?
An infrared scanning module is available as an option. Select and test the module with the barcode formats and label quality used in the courier network.
Q3.Can the same device print labels and receipts?
Only if the selected printer configuration and media support both formats. Receipt paper and adhesive labels have different handling requirements.
Q4.How should COD cash be reconciled?
The courier should close the route against a system report, count physical cash and record any difference before handover. The parcel and payment references should remain linked.
Q5.Is GPS proof of delivery?
No. GPS is supporting location evidence; recipient confirmation and the courier application’s delivery controls provide the primary record.
The best courier terminal reduces handoffs between scanning, delivery confirmation, payment and receipt issuance. Select the final configuration only after the application, network, accessories and reconciliation process work together on real routes. That approach turns the Android POS into a dependable operational endpoint instead of another device the driver must manage.
Home 
Biometric POS Terminals for Agent Banking: Fingerprint vs Palm Vein Authentication 
