Offline POS Transactions: Testing Recovery Sync and Duplicate Charge Prevention

When a shopping mall loses connectivity and customers are waiting at checkout, store teams need to know which transactions they can complete. For international brands deploying stores in China, a supplier’s statement that a POS “supports offline operation” is not an adequate acceptance criterion. Sales capture, payment authorization and recovery synchronization need separate tests, especially when a customer has paid but the POS has not received the result.

Offline operation depends on sufficient local data. Actions requiring live external validation need restrictions or a pending workflow. When connectivity returns, each completed transaction must affect the central records once. Supported payment methods, maximum offline duration and conflict handling should be agreed for the project.

Offline POS transactions and offline payments are different capabilities

A disconnected POS may scan products, calculate a price and save a sale locally. Whether the customer can pay using WeChat Pay, Alipay, a bank card or stored value depends on the payment terminal, provider, member platform and their connectivity. Local sales capture does not establish that payment authorization is available.

Cash does not require online authorization. In a Chinese department-store concession, the department store may collect payment through its own checkout system while the brand’s POS records the sale and collection result. Availability therefore depends on the department store’s system as well as the brand’s POS. Test collection, recording and subsequent reconciliation separately. QR-code payments, bank cards, stored value, loyalty points and coupons each require checks against their own interfaces.

Local data defines the offline operating scope

Before going offline, a logged-in POS generally needs the relevant product, price, promotion and terminal-permission data. Testing one ordinary SKU is insufficient. Inspect the version, effective period and store applicability so that an expired promotion cannot continue indefinitely.

• Check which store products and prices are available locally, and how the system flags a price update that has not reached the terminal.
• Identify downloaded promotion rules and their behavior across start and end times.
• Recognize that local inventory reflects the last known state. Disconnected terminals may not see one another’s sales.
• Restrict points, coupons, stored value and cross-store benefits that require current balances, or use the explicitly agreed validation method.
• Retain the operator, terminal and time for offline price overrides, discounts and voids.

Multiple terminals selling without shared updates cannot guarantee that store inventory will never be oversold. Define minimum local-stock thresholds, whether negative stock is permitted, restricted limited-edition or high-value products, and the point at which offline selling must stop. On reconnection, preserve completed sales and create inventory exceptions rather than overwriting conflicting transactions.

Make unavailable actions clear to store staff. Stored-value redemption, coupon use, electronic invoicing, cross-store returns and online-order collection may require live verification. The POS should explain the restriction and provide a way to resume processing after connectivity returns. Test maximum offline duration, transaction-count limits and expiry of local data; the platform must state which operations stop and why.

An uncertain payment result requires checking the original request

A duplicate charge can arise when the payment provider has collected the money but the success response fails to reach the POS. If the screen simply reports “payment failed,” the cashier may scan the customer’s payment code again.

Keep sales status separate from payment status. An order can remain “awaiting payment confirmation” while preserving its order reference, payment request ID, amount, method and initiation time. Once communication is restored, the POS or payment service should query that original request.

• If payment succeeded, attach the confirmed result to the original sale without creating another payment request.
• If payment definitively failed or the request was closed, allow a new attempt with a new payment request ID.
• If the provider still reports an unknown outcome, retain pending status and route the transaction to reconciliation or manual review. Do not assume success or charge the customer again.

The message at checkout should guide action. When the customer’s phone shows a debit but the POS lacks confirmation, instruct the operator to query the original payment or contact the designated supervisor, rather than displaying a generic request to pay again.

Recovery must preserve the original commercial record

On reconnection, a terminal may upload offline transactions while downloading updated product and promotion data. Whatever the technical sequence, a completed offline sale must retain its original transaction time, price and promotion version. Newly downloaded rules must not reprice it.

Generate a stable transaction identifier locally, for example a business key combining store, terminal, business date and local sequence. The receiving service uses the agreed deduplication key to identify previously processed transactions. A repeated upload returns the original processing result instead of creating another sale.

Sync status needs more detail than success or failure. Store and headquarters teams should distinguish accepted records, duplicate submissions, business conflicts and items requiring manual review. Conflicts can arise when a product is withdrawn during the outage, a coupon is redeemed elsewhere, a member balance changes or concurrent sales leave inventory temporarily negative.

A conflict does not justify deleting a paid transaction. Preserve the sale and payment facts, then resolve differences through an exception, inventory adjustment, loyalty correction or refund workflow. At day-end, the teams should be able to explain the status of the money, sale and goods.

Check four forms of duplication

Trace all four effects using the same transaction reference. One customer debit does not establish correctness if the back office contains two sales with duplicate inventory and loyalty effects.

A CNY 220 outage and recovery test

Prepare two POS terminals in the same store, two products and one test member. Terminal A loses its business-network connection; terminal B remains connected, potentially through an independent backup connection. Each product costs CNY 120. Terminal A has already downloaded a promotion reducing the two-item total by CNY 20, so the payable amount is CNY 220. Record opening stock, member points and the terminal’s last synchronization time.

1. Disconnect terminal A, scan both products and verify that the downloaded promotion produces CNY 220 and a local transaction reference.
2. Test every permitted offline payment method and explicitly prohibited method. Restricted methods need clear operator messages.
3. In a payment test environment, have the payment integration provider delay or suppress the response after confirming success. The provider should have a successful transaction while the POS remains pending. The POS must query the original request when communication resumes, rather than immediately issue another one.
4. Restore connectivity, retrieve the original payment outcome and verify that CNY 220 was collected once and linked to the original sale.
5. Upload the same offline transaction three times. Verify one central sale, a one-unit deduction for each product and a single loyalty award.
6. While A is offline, use the same member benefit or sell the same stock through connected terminal B. On recovery, preserve both recorded business events and route coupon or stock conflicts to exception handling. Do not overwrite one with the later record.
7. End the promotion before restoring A’s connection. Upload the offline sale and confirm that it retains its original promotional snapshot rather than recalculating against current rules.
8. Complete store day-end checks. Trace CNY 220 of sales, CNY 220 of payment, both inventory movements and loyalty effects to the same transaction.

Retain the local transaction reference, payment request ID, provider transaction record, first and repeated synchronization results, central sale, inventory ledger, loyalty ledger and day-end reconciliation. Demonstrating that a disconnected terminal can create an order is only the first part of this evidence.

Store procedures need an agreed outage response

Define who decides that offline mode is active, which payment methods pause, who handles uncertain payment results and when staff may return to normal processing. Uncoordinated hotspot changes, repeat payment scans or manual replacement orders can turn a connectivity fault into financial and inventory discrepancies.

A practical store procedure has four steps: confirm network and terminal status, read the POS offline guidance, transact only within the permitted scope, and reconcile pending orders after recovery. Keep local records until synchronization and reconciliation finish. Do not replace an unresolved original sale with a new one.

PEKON Smart Retail System: scope to verify

The PEKON Smart Retail System covers store products, promotions, transactions, split-tender payments and inventory, with integration to ERP, member platforms, payment services and other existing systems. After login, the client can synchronize necessary product and promotion data and continue recording sales when the network is interrupted.

Supported offline payment methods, local-data retention, member-benefit validation, recovery sequencing, conflict handling and original-payment queries require confirmation against the brand’s architecture and project version. Classify each requirement as standard functionality, configuration, integration, custom development or unsupported. Assess offline behavior alongside permissions, inventory, payment and integration responsibilities.

FAQ

Can a disconnected POS still scan products and create a sale?

A terminal that is already logged in and has synchronized the necessary product, price and promotion data may continue capturing sales. First login, missing downloads and expired local data require explicit project rules and testing.

Will WeChat Pay, Alipay and bank cards work during a network outage?

There is no single answer across methods and architectures. These payments depend on their terminals, providers and connectivity. Offline sales capture does not prove offline authorization. Test each method before launch and specify the message shown when it is unavailable.

What if the customer has been debited but the POS reports failure?

Retain the original order and payment request references and query the final status before requesting another payment. Confirmed success belongs to the original sale; confirmed failure may permit a new attempt. Unknown outcomes require reconciliation or manual handling.

Why might recovery deduct inventory twice?

The same local transaction may have been uploaded repeatedly, or both the sales event and synchronization event may trigger deductions. A stable transaction identifier and deduplication rules should ensure that repeated requests return the original result without changing inventory, loyalty or financial records again.

Does an offline sale belong to the trading day or the synchronization day?

Retain the original business date and actual transaction time, recording synchronization time separately. Inventory and accounting posting depend on day-end closure, locked periods and project posting rules. Synchronization time must not replace the original transaction time.