Offline consumption method under network interruption condition
By introducing TCP communication and asynchronous order reporting mechanisms between offline servers and consumer machines in the cafeteria payment system, the problems of payment failures and long transaction times caused by network interruptions are solved, fast offline transactions and final data consistency are achieved, and payment efficiency and system stability are improved.
Patent Information
- Application Number
- CN202510496004.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-21
- Publication Date
- 2025-09-12
AI Technical Summary
In canteen payment systems in crowded places, network interruptions lead to payment failures and long transactions, affecting consumption efficiency and user experience.
An offline server is used to establish TCP communication with the consumer machine to perform local transaction verification and asynchronous order reporting mechanism to ensure that payment is completed when there is no external network connection, and transaction data is automatically synchronized after the network is restored.
It enables offline transactions during network interruptions, shortens the time required for a single transaction to less than 1 second, ensures the robustness of the payment system and the eventual consistency of data, and reduces transformation costs.
Smart Images

Figure CN120634560A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of electronic payment, and in particular to a method for realizing offline consumption in the case of network interruption or instability. Background Art
[0002] In traditional cafeteria payment scenarios, whether using campus card payments or mobile payments like WeChat and Alipay, transactions rely on a stable network connection. However, during peak dining hours in crowded venues (such as university cafeterias and corporate cafeterias), network congestion, excessive base station load, or external network failures often lead to network interruptions or delays, resulting in payment failures and extended transaction times (up to tens of seconds), seriously impacting consumer efficiency and user experience.
[0003] In existing solutions, offline servers must connect to cloud servers in real time to complete transaction verification and deductions. This completely halts transactions if the external network is disconnected. To address this issue, a solution is urgently needed that can enable offline transactions during network outages and asynchronously synchronize data after network recovery. Summary of the Invention
[0004] The purpose of the present invention is to provide an offline consumption method in the event of network interruption. Through local transaction verification and asynchronous order reporting mechanism, it ensures that payment can still be completed when there is no external network connection, and automatically synchronizes transaction data after the network is restored, thereby improving payment efficiency and system robustness.
[0005] The present invention is implemented as follows: an offline consumption method in the case of network interruption, specifically comprising the following steps:
[0006] S1: The offline server establishes a TCP communication connection with the consumer machine and monitors the transaction events of the consumer machine;
[0007] S2: The staff enters the consumption amount on the consumption machine, and the diner triggers a transaction event by swiping the card or scanning the QR code. The consumption machine pushes the transaction event including the card swiping information or QR code information and the consumption amount data to the offline server;
[0008] S3: After receiving the transaction event and amount data, the offline server first verifies the transaction. The verification includes checking whether the transaction limit and balance of the diner's account meet the current consumption requirements. If the verification conditions are not met, a payment failure result is pushed to the consumer machine. If the verification conditions are met, an order is generated and stored in the offline database. At the same time, a payment success result is pushed to the consumer machine. No communication with the external network is required during the transaction process.
[0009] S4: After completing order storage, the offline server starts an asynchronous reporting mechanism, cyclically calls the cloud consumption interface at preset intervals, and reports the unsynchronized orders in the offline database to the cloud server until receiving the transaction results returned by the cloud server, and updates the status of the corresponding orders in the offline database according to the transaction results.
[0010] Preferably, the consumption machine communicates with the offline server through an intranet, so that the time taken for a single transaction is shortened to less than 1 second.
[0011] Preferably, while monitoring transaction events of the consumer machine, the offline server also reads unsynchronized orders in the offline database in real time, and gives priority to reporting the unsynchronized orders each time the cloud consumption interface is called.
[0012] Preferably, the order status includes not synchronized, synchronizing, successful synchronization and failed synchronization. The offline server updates the corresponding order status to successful synchronization or failed synchronization based on the transaction results returned by the cloud server. For orders with a status of failed synchronization, they will continue to be retained in the offline database and wait for subsequent cyclic reporting.
[0013] Preferably, when the external network connection between the offline server and the cloud server returns to normal, the offline server automatically reports all orders in the offline database that are in the status of not synchronized or synchronization failed until all orders are synchronized successfully.
[0014] Compared with the prior art, the present invention has the following beneficial effects:
[0015] The present invention can support offline transactions: when the external network is interrupted, the transaction can still be completed through local verification and order storage, avoiding paralysis of the cafeteria payment system.
[0016] The present invention improves efficiency: intranet communication + local processing shortens the time required for a single transaction to less than 1 second, significantly reducing queues during peak hours.
[0017] The final consistency of data in this invention: through the asynchronous retry mechanism, all offline orders are ensured to be synchronized to the cloud after the network is restored, ensuring the accuracy of accounting.
[0018] The present invention has compatibility: supports multiple payment methods such as card swiping and QR code, is adaptable to existing consumer terminal equipment, and reduces modification costs. BRIEF DESCRIPTION OF THE DRAWINGS
[0019] Figure 1 It is a flowchart of the use of the present invention. DETAILED DESCRIPTION
[0020] In the present invention, unless otherwise expressly specified or limited, the terms "mounted," "connected," "connect," "fixed," etc. should be understood broadly. For example, they may refer to fixed connection, detachable connection, or integration; mechanical connection or electrical connection; direct connection or indirect connection through an intermediate medium; internal communication between two components or interaction between two components. Those skilled in the art will understand the specific meanings of the above terms in the present invention based on specific circumstances.
[0021] The following is a further description with reference to the accompanying drawings and specific embodiments:
[0022] Example 1
[0023] The following is combined with Figure 1 Specific embodiments of the present invention are described in detail.
[0024] The present invention is an offline consumption method in the case of network interruption. The specific implementation steps are as follows:
[0025] 1. Initialize the connection: The offline server and the consumer machine establish an intranet communication connection through the TCP protocol and monitor the transaction events of the consumer machine (such as card swiping and code scanning).
[0026] 2. Local transaction processing:
[0027] The staff enters the amount at the consumption machine, and the user triggers the transaction by swiping the card or scanning the code. The consumption machine pushes the transaction event (including account identification) and the amount to the offline server.
[0028] The offline server verifies the user's account balance and transaction limits (such as daily spending limit). If the verification is successful, an order (including order number, amount, time, account ID, etc.) is generated and stored in the local database. The status is marked as "unsynchronized" and "payment successful" is returned to the consumer machine. If the verification fails, "payment failed" is returned.
[0029] 3. Asynchronous order reporting:
[0030] The offline server cyclically calls the cloud consumption interface at a preset interval (such as 1 second) and reports orders with a status of "unsynchronized" or "synchronization failed" in the local database to the cloud server.
[0031] After processing the order, the cloud server returns the result (success / failure). The offline server updates the order status to "synchronization successful" or "synchronization failed" based on the result. Failed orders remain in the local database and wait for the next report.
[0032] 4. Network recovery processing: When the external network connection is restored, the offline server automatically reports all unsynchronized or failed orders in batches until all are synchronized successfully.
[0033] The system framework of the method for using the present invention includes:
[0034] Consumption machine: It is equipped with a card reader, a QR code scanner and an input interface. It communicates with the offline server through the intranet, collects transaction data and pushes it to the offline server.
[0035] Offline server: Deploy a local database, including a transaction verification module (checking balances and transaction limits), an order processing module (generating orders and updating status), and an asynchronous reporting module (cyclically reporting orders to the cloud).
[0036] Cloud server: Receives orders reported by offline servers, completes transaction processing such as deductions, and returns results to the offline server.
[0037] When used specifically, system hardware and network configuration
[0038] Consumption machine: It uses an embedded terminal device, equipped with an RFID card swiping module, a QR code camera, a 4.3-inch touch screen, runs the Linux system, and is connected to the offline server through a wired / wireless LAN (intranet). The communication protocol is TCP / IP.
[0039] Offline server: Deployed in the cafeteria's local computer room, configured with a MySQL database to store orders. Hardware parameters include: Intel Xeon E-2224G processor, 16GB memory, 512GB SSD, and connected to the intranet (consumer machine) and the Internet (cloud server) through a router.
[0040] Cloud server: Alibaba Cloud ECS server is used, providing a RESTful API interface (such as / order / upload) for receiving orders. The database is MySQL, which supports high-concurrency transaction processing.
[0041] Offline transaction processing flow
[0042] Step 1: Transaction triggering and data collection
[0043] The staff enters the consumption amount (such as 15 yuan) on the consumption machine interface and clicks "Confirm".
[0044] When the user swipes their campus card (containing an RFID chip, storing the account ID: 20210001) or presents the Alipay payment code, the consumer machine reads the account ID and generates a transaction event {event:"pay",account_id:"20210001",amount:15}, which is pushed to the offline server (IP: 192.168.1.100, port: 8080) via a TCP connection.
[0045] Step 2: Local verification and order generation
[0046] 1. After receiving the data, the offline server calls the transaction verification module:
[0047] Query the balance of account 20210001 in the local database (current balance is 100 yuan) and the daily consumption limit (preset 50 yuan, 30 yuan has been spent on the day).
[0048] Verification logic: Balance ≥ Consumption Amount and the accumulated consumption on the day + the current amount ≤ the daily limit, that is, 100 ≥ 15 and 30 + 15 ≤ 50, the verification passes.
[0049] 2. The order processing module generates an order, and the data structure is as follows:
[0050] The order is inserted into the offline_orders table of the local database, and {result:"success",order_id:"202504160001"} is returned to the consumer machine, which displays "Payment successful".
[0051] Step 3: Asynchronous reporting and status update
[0052] The asynchronous reporting module starts a timer (at intervals of 1 second), queries the offline_orders table for orders with a status of "unsynchronized" and retry_count < 5, and reports them in batches in chronological order (up to 10 orders at a time).
[0053] After receiving the order, the cloud server executes the remote deduction logic (such as deducting 15 yuan from the campus card account) and returns the result {order_id:"202504160001",status:"succes s"} or {error:"Insufficient balance (actual balance is 90 yuan, inconsistent with the local cache)"}.
[0054] The offline server updates the order status based on the cloud results:
[0055] Success: The status changes to "Synchronization successful" and the cloud return time is recorded.
[0056] Failure: The status changes to "Synchronization Failed", retry_count+1. If retry_count ≥ 5, the status is marked as "Waiting for Manual Processing" and the error log is recorded.
[0057] Step 4: Network interruption and recovery
[0058] Interruption scenario: If the external network is suddenly disconnected (such as a router failure), the offline server detects that it cannot connect to the cloud (through the ping command or interface call timeout), suspends asynchronous reporting, and only processes local transactions (steps 1-2 are executed normally, and orders continue to be stored in the local database).
[0059] Recovery scenario: After the external network is restored, the asynchronous reporting module automatically scans all orders with a status of "unsynchronized" or "synchronization failed" and a retry_count < 5, and prioritizes reporting the earliest generated orders until all orders are successfully synchronized.
[0060] Performance optimization and exception handling
[0061] Intranet communication optimization: The consumer machine and offline server are connected through the same local area network. The data transmission time for a single transaction is ≤10ms, the local verification and database operation time is ≤90ms, and the total transaction time is ≤100ms (much lower than the existing solution of more than 2 seconds).
[0062] Balance consistency: If the actual balance in the cloud is inconsistent with the local verification result (for example, the user recharges through other channels and the balance is not synchronized), after the cloud returns a failure, the offline server records the difference and prompts the staff to manually check to avoid overspending.
[0063] Logging: The offline server records all order operation logs (including transaction time, amount, status changes, and error messages) to facilitate post-audit and troubleshooting.
[0064] The above is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Those skilled in the art will readily appreciate that the present invention is susceptible to various modifications and variations. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.
Claims
1. An offline consumption method in case of network interruption, characterized in that: The specific steps include: S1: The offline server establishes a TCP communication connection with the consumer machine and monitors the transaction events of the consumer machine; S2: The staff enters the consumption amount on the consumption machine, and the diner triggers a transaction event by swiping the card or scanning the QR code. The consumption machine pushes the transaction event including the card swiping information or QR code information and the consumption amount data to the offline server; S3: After receiving the transaction event and amount data, the offline server first verifies the transaction. The verification includes checking whether the transaction limit and balance of the diner's account meet the current consumption requirements. If the verification conditions are not met, a payment failure result is pushed to the consumer machine. If the verification conditions are met, an order is generated and stored in the offline database. At the same time, a payment success result is pushed to the consumer machine. No communication with the external network is required during the transaction process. S4: After completing order storage, the offline server starts an asynchronous reporting mechanism, cyclically calls the cloud consumption interface at preset intervals, and reports the unsynchronized orders in the offline database to the cloud server until receiving the transaction results returned by the cloud server, and updates the status of the corresponding orders in the offline database according to the transaction results.
2. The offline consumption method in the case of network interruption according to claim 1, characterized in that: The consumption machine communicates with the offline server through the intranet, which reduces the time required for a single transaction to less than 1 second.
3. The offline consumption method in the case of network interruption according to claim 1, characterized in that: While monitoring the transaction events of the consumer machine, the offline server also reads the unsynchronized orders in the offline database in real time, and gives priority to reporting the unsynchronized orders each time the cloud consumption interface is called.
4. The offline consumption method in the case of network interruption according to claim 1, characterized in that: The order status includes not synchronized, synchronizing, successful synchronization and failed synchronization. The offline server updates the corresponding order status to successful synchronization or failed synchronization based on the transaction results returned by the cloud server. For orders with a status of failed synchronization, they will continue to be retained in the offline database and wait for subsequent cyclic reporting.
5. The offline consumption method in the case of network interruption according to claim 1, characterized in that: When the external network connection between the offline server and the cloud server is restored to normal, the offline server automatically reports all orders in the offline database that are not synchronized or have failed to synchronize until all orders are successfully synchronized.
Citation Information
Cited By
Campus consumption account state intelligent management system based on multi-terminal synchronous verification
CN121921012A
Intelligent Management System for Campus Consumption Account Status Based on Multi-Terminal Synchronous Verification
CN121921012B