2026-09-14 Author : ZCS
A cash on delivery POS terminal records payment at the moment a parcel reaches the customer. The payment may be physical cash, a card transaction, a dynamic QR payment or a combination permitted by the merchant. The terminal links the amount to the order, driver, route and time so finance teams can determine what was collected, what settled electronically and what cash the driver must return.
Collecting the money is only the first step. Cash remains with the driver until handover, card payments settle through an acquirer, and QR payments may arrive through a different provider on a different schedule. Returns, refused parcels, partial deliveries, tips and failed payment attempts create further differences. Accurate reconciliation needs a shared transaction identity that follows every order from dispatch to bank settlement.
A COD POS terminal supports this control by presenting the assigned order, capturing the chosen payment method, confirming external payment status and issuing a receipt. The delivery application, order management system and accounting platform remain responsible for balances, settlement matching and financial reporting.
A reliable process compares several records rather than trusting a single device total. The order system says what should have been collected. The driver's shift report says what the terminal recorded. The cash handover proves what was physically returned. Processor and QR reports show electronic transactions, fees, reversals and settlements. The bank statement confirms what ultimately arrived.
The order number should be the commercial reference, while every electronic attempt also keeps the provider's transaction ID. A route, driver and device identifier make operational investigation possible. Without these links, finance staff can see that money arrived but cannot confidently determine which delivery it settled.
Before departure, the application assigns orders to an authenticated driver and downloads the amount due, allowed payment methods and delivery instructions. At the customer location, the driver opens or scans the order rather than typing an amount from memory. This prevents a valid payment from becoming an unidentified credit.
After the customer chooses cash, card or QR, the application creates a payment attempt tied to the order. Cash is marked collected only after the driver confirms the amount received and any change. Card and dynamic QR payments should be marked paid only after the provider returns a successful status to the merchant system. A screenshot on the customer's phone or the driver's visual judgment is not enough evidence of settlement.
The terminal then prints or sends a receipt containing the order reference, amount, method, date, delivery provider and final status. At shift close, the driver submits cash and the terminal or application closes the route. Finance matches electronic reports and later bank credits using transaction and settlement references.
Cash creates custody risk because the driver holds merchant funds between delivery and remittance. The system should calculate expected cash as successful cash deliveries minus approved cash refunds, change advances or other documented adjustments. The cashier counts the actual handover and records any difference against the shift before the driver leaves.
Each correction needs a reason and user identity. A supervisor may approve an overage, shortage, counterfeit note, wrong change or deposit made at another location, but the original record should remain visible. Editing the order total after collection destroys the audit trail. The application should use adjustment entries instead.
Cash limits can reduce exposure. Once a driver reaches a threshold, the operation can require a depot drop, bank deposit or transfer to an authorized collection point. The terminal can show the expected cash position, but physical controls and supervisory procedures remain necessary.
Card reconciliation begins with approved transactions, not the gross order total. The processor report may include voids, reversals, refunds, chargebacks and fees. Settlement can combine many transactions into one bank deposit, so finance needs the batch or settlement ID that connects individual payments to the net credit.
Connectivity loss is a common source of duplicates. If the response does not reach the terminal, the driver should use a transaction-status enquiry rather than immediately charging the card again. The application should preserve an idempotency key or unique attempt reference so a retry cannot create a second collection for the same order.
Card acceptance also requires an approved payment path. NFC hardware alone does not make a general Android POS a certified card terminal. The selected device configuration, payment application, processor and acquirer must satisfy the rules in the deployment market. Where a separate certified payment terminal is used, the delivery application should still capture its reference without exposing sensitive card data.
A static QR code identifies the merchant but may not carry the order amount or reference. That forces the driver to inspect a customer screen or search an account feed, increasing the risk of wrong amounts and payments sent to the wrong account. A dynamic QR code generated for the order can include an amount and merchant reference, making automatic matching much easier.
The application should wait for server-side confirmation from the QR provider. A customer screenshot can be old, edited or associated with another recipient. If confirmation is delayed, the payment should remain pending and the workflow should define whether the parcel may be released. This is a commercial risk decision, not something the terminal can decide alone.
Finance should reconcile the QR provider's transaction file to orders first, then reconcile its settlement batches to the bank. Provider fees, refunds and delayed credits should remain separate fields so the net bank amount can be explained without changing the original customer payment.
A failed delivery should close with a controlled reason such as customer unavailable, refused, wrong address or payment failure. It should never appear as an unexplained zero collection. If the parcel returns to the depot, the order and inventory systems must record custody and condition.
Returns after collection require a refund linked to the original payment. Cash refunds, card reversals and QR refunds follow different approval and settlement paths. The system should not simply delete the original sale. Split payments need the same discipline: each component must have its own method, amount and reference while the combined total closes the order.
The ZCS Z108 dual-screen Android POS can serve as a delivery collection or depot terminal when operators need a larger interface, customer confirmation and integrated printing. It combines an 8-inch operator display with a 3.95-inch secondary screen, Android 14, 4GB RAM and 32GB storage, 4G, Wi-Fi, Ethernet, GPS, a 3600mAh battery and 58mm/80mm printer options. NFC and barcode scanning are optional configurations.
At a doorstep or service counter, the employee can select the order on the main screen while the customer-facing display shows the amount or payment prompt. The printer can issue a receipt, while barcode scanning can retrieve the parcel instead of relying on manual entry. Ethernet and ports also make the Z108 suitable for a depot station where it may connect to local peripherals and operate from fixed power.
The Z108 is the hardware layer, not a ready-made COD reconciliation platform. Order assignment, dynamic QR generation, provider callbacks, cash balances, settlement matching and accounting exports require integrated software. Optional payment and scanning modules should be confirmed in the quotation, and any card-acceptance configuration must be validated with the applicable payment partners.
A delivery device may lose signal in lifts, basements or remote areas. Offline operation should distinguish data capture from payment authorization. The terminal may record proof of delivery and queue an update, but card or QR payment cannot be assumed successful without an approved offline process or provider confirmation.
Queued records need encryption, sequence controls and clear visible status. After reconnection, synchronization should be idempotent: sending the same record twice must not create two payments or two deliveries. Supervisors need a report of unresolved transactions rather than a silent retry process.
At route close, the system should freeze the driver's shift totals and separate cash, card, QR, refunds and unresolved attempts. The cashier counts cash against the expected amount. Operations reviews failed and returned deliveries. Finance imports provider reports, matches individual electronic transactions and later confirms settlement batches against the bank.
Exceptions should enter a queue with an owner and deadline. Examples include a cash shortage, successful provider payment with an open order, paid order without provider confirmation, duplicate charge or settlement amount that does not match its transactions. Aging these exceptions is as important as counting them; an unresolved difference becomes harder to investigate once the driver, customer and parcel history are no longer fresh.
Each terminal should be assigned to a driver or station, run only approved applications and receive controlled updates. Lost devices must be disabled. The management platform can track software and device status, while payment data should remain within the authorized transaction systems.
Useful operational measures include successful collection rate, cash variance, unmatched electronic payments, duplicate attempts, refund aging, time to remit cash and time to resolve exceptions. A low headline shortage can still hide a weak process if many transactions remain pending or are manually adjusted.
Give every order, payment attempt, driver, route and terminal a persistent identifier.
Use the assigned order amount instead of unrestricted manual amount entry.
Generate order-specific dynamic QR codes and rely on provider confirmation.
Define status enquiry, retry, duplicate prevention and offline release rules.
Reconcile cash at shift close and electronic payments through provider settlement to bank.
Preserve original transactions and record refunds or corrections as separate entries.
Pilot the device and application under real routes, signal gaps, returns and shift handovers.
Q1.What is a COD POS terminal?
It is a field or counter device that records payment for a delivery and links the collection to the order, driver and payment method.
Q2.Should a driver accept a QR payment screenshot?
No. The merchant system should receive confirmation from the authorized QR provider before treating the order as paid.
Q3.How is cash reconciled?
Expected cash from completed orders is compared with the physical handover, and every variance is recorded and approved.
Q4.Why does the bank deposit differ from card sales?
Processors may settle batches net of fees, refunds, reversals or chargebacks and on a later date.
Q5.Can the Z108 process COD payments?
It can run an integrated Android collection application and provide display, printing, network and optional reader functions. The payment and reconciliation services must be supplied by compatible software and providers.
Q6.Can COD work offline?
Proof and order data may be queued, but payment release rules must reflect provider support and the merchant’s risk policy.
Reliable COD operations do not treat cash, card and QR as interchangeable labels. Each method has different evidence, custody and settlement timing. A good POS workflow links them to the same order while preserving those differences for audit and accounting.
Delivery platforms and system integrators can evaluate the ZCS Z108 Android POS as a dual-screen, printable hardware platform for delivery collection and depot reconciliation. Request the required NFC, scanning, printer and connectivity configuration, then test it with the actual order system and payment providers before rollout.
Home 
Trusted POS Manufacturer Delivering Robust Biometric & Android Payment Terminals for Global Businesses 
