Payment method and system based on multi-account priority deduction and offline secondary verification

Abstract

The present application relates to the field of welfare management and electronic payment technology, in particular to a payment method and system based on multi-account priority deduction and offline secondary verification, comprising: the present application allocates a unique identifier to the user and associates multiple credit accounts, and presets a deduction priority list and card class authority for different consumption scenarios. When paying, first verify the card class authority, then deduct each account in a step-by-step manner according to the priority, if the balance is insufficient, automatically extend to the next account, if still not enough after all accounts are deducted, roll back; after success, generate a transaction record containing a global serial number. When the network is interrupted, switch to offline mode, deduct based on local balance snapshot and store data temporarily, after network recovery, supplement the order and enter the account or mark as abnormal after secondary verification by the central server. The system regularly parses the reconciliation file, checks the transaction details according to the serial number, and if a difference is found, an alarm is generated and a difference report is generated. The present application improves the efficiency of fund utilization, system availability and accounting accuracy.

Description

Technical Field

[0001] This invention relates to the fields of welfare management and electronic payment technology, and in particular to a payment method and system based on multi-account priority deduction and offline secondary verification. Background Technology

[0002] With the advancement of enterprise digital transformation, more and more companies are adopting electronic means for the distribution and consumption management of employee benefits (such as meal allowances, holiday gifts, and labor protection supplies). However, existing benefit management systems typically allocate different types of benefit funds to independent accounts or cards, managed separately by different functional departments. This fragmented management model requires employees to maintain multiple account systems simultaneously, with information not being shared between accounts, making it impossible to achieve combined payment and unified settlement of multiple types of benefit points. At the same time, existing solutions usually bind specific benefit funds to a single merchant or consumption scenario, lacking a flexible deduction mechanism based on priority, resulting in some accounts having idle funds while other scenarios have limited payment capabilities, leading to low fund utilization. In addition, payment terminals often directly reject transactions in weak network or offline environments, lacking effective offline caching and data eventual consistency guarantee mechanisms, resulting in insufficient system availability. Furthermore, the distribution of benefits, the statistics and reconciliation of consumption data still rely on manual or semi-automated methods, with consumption records scattered across various payment terminals, lacking a unified data collection and management platform, resulting in high management costs. Summary of the Invention

[0003] This invention provides a payment method and system based on multi-account priority deduction and offline secondary verification, which solves the problems of existing welfare funds belonging to multiple fragmented account systems, making it impossible to achieve combined payment, and lacking dynamic priority deduction, offline disaster recovery and full-link automated reconciliation mechanism.

[0004] The objective of this invention can be achieved through the following technical solutions:

[0005] The first aspect of this invention is to provide a payment method based on multi-account priority deduction and offline secondary verification, comprising the following steps: S1: Assign a unique identifier to each user and associate it with multiple points accounts subject to consumption rules. The consumption rules include the scope of applicable merchants, consumption limits and account validity period. For different consumption scenarios, a corresponding deduction priority list and card payment permissions are preset. The deduction priority list defines the deduction order of each points account. S2: After receiving a request from the payment terminal, the payment interface subsystem obtains the user identifier, the consumption scenario identifier, and the amount to be paid. Based on the user identifier, it queries the corresponding card type and verifies the payment authority of the card type in the current consumption scenario. If the card type does not have the authority, the request is rejected. If the card type has the authority, it obtains a deduction priority list matching the consumption scenario and performs a tiered deduction operation on each points account in sequence according to the deduction priority list. The transaction status is marked based on the deduction result. After the transaction is completed, a transaction record is generated and written to the database. The transaction record includes a global serial number, user identifier, consumption scenario identifier, deduction details of each involved account, and transaction status code. S3: When the network connection between the payment terminal and the central server is interrupted, switch to offline mode, execute the step-by-step deduction operation in S2 based on the locally cached balance snapshot, and temporarily store the transaction data in the local synchronization table and mark it as unsynchronized. After the network is restored, send a replacement order request to the central server in chronological order. The central server performs a second verification based on the actual balance. If the balance is sufficient, the transaction is officially credited and the status is updated to synchronized. If the balance is insufficient, the transaction is marked as abnormal and a manual processing procedure is triggered. S4: The transaction query subsystem periodically parses the reconciliation file and imports the transaction details into the consumption details table based on the global serial number. It then verifies each transaction record of each account, including the transaction amount, deduction account type, deduction amount for each account, and transaction time. If a discrepancy is found between the account and the actual transaction, an alarm is triggered and a discrepancy report is generated.

[0006] Furthermore, the tiered deduction operation includes: Suppose the deduction priority list contains N accounts, set the loop variable i=1, and the current amount to be paid is P. Perform a tiered deduction operation on each points account in sequence according to the following sub-steps: S21: Read the available balance of the i-th account. ; S22: If If the transaction is successful, the amount P will be deducted from the i-th account, the deduction details including the account identifier, the amount deducted and the remaining balance will be recorded, the transaction status will be marked as successful, and the process will jump to S3. S23: If Then the amount will be deducted from the i-th account. Record the deduction details and update them. , ; S24: If Then return to S21 to continue execution, if and Then roll back all executed deduction operations, mark the transaction status as failed, and terminate the transaction.

[0007] Furthermore, the multiple points accounts in S1 include at least two of the following types of accounts: catering accounts, welfare accounts, subsidy accounts, and general accounts. The general accounts are not limited to the scope of applicable merchants and are used as a backup account to make up the difference in S2.

[0008] Furthermore, the local cached balance snapshot in S3 is obtained from the central server through an incremental synchronization mechanism, and only account balance records that have changed since the last snapshot time are synchronized; the network status is detected through a heartbeat mechanism, and the network is determined to be interrupted when the heartbeat times out for a preset number of consecutive times.

[0009] Furthermore, the unique identifier is either the physical card number or the electronic card number; the physical card obtains the physical card number through a card reader and binds it to the card number printed on the card face, while the electronic card has an electronic card number automatically generated by the system; the same user can hold both a physical card and an electronic card at the same time, and both are associated with the same user record through the user identifier and share the same points account system.

[0010] Furthermore, the consumption limit in S1 includes a single transaction consumption limit and a daily cumulative consumption limit. Before performing the deduction, S2 also includes: querying the corresponding consumption rules according to the current consumption scenario, determining whether the amount to be paid exceeds the single transaction consumption limit, and whether the daily cumulative consumption amount plus the amount to be paid exceeds the daily cumulative consumption limit. If they exceed, the request is rejected.

[0011] Furthermore, the transaction record in S3 also includes a transaction timestamp and a terminal number, wherein the transaction timestamp uses the server time; the global serial number is generated by a combination of date, time and serial number to ensure global uniqueness.

[0012] Furthermore, the step-by-step deduction operation in S2 is executed within a database transaction, and row-level locking ensures that the balance deduction operation of the same account is executed serially; when S24 determines that the transaction has failed, the entire database transaction is rolled back, restoring all account balances that have been deducted to their values ​​before the deduction.

[0013] Furthermore, S2 reads the available balance of the i-th account. Previously, it also included checking the account's expiration date; if the current date exceeded the expiration date, the account was skipped. Then return to S21 to continue execution.

[0014] A second aspect of the present invention is to provide a payment system based on multi-account priority deduction and offline secondary verification, comprising: The database subsystem is used to store user information, data of multiple points accounts subject to consumption rules, and transaction records. The consumption rules include the scope of applicable merchants, single transaction limit, and account validity period. The points processing subsystem is used to perform tiered balance deductions on each points account according to the deduction order defined in the preset deduction priority list, using a loop variable i and the amount to be paid P. If the available balance of the i-th account is... If the amount is not less than P, the full amount will be deducted and the transaction status will be marked as successful. If it is less than P, then deduct. And update Then, increment i and continue execution. If P is still greater than zero after all accounts have been deducted, roll back all executed deductions and mark the transaction status as failed. The payment interface subsystem is used to connect to payment terminals, receive and parse payment requests containing user identifiers, consumption scenario identifiers and the amount to be paid; The management subsystem is used to configure the deduction priority list and card payment permissions for each consumption scenario, and to verify the payment permissions of cards in the corresponding consumption scenarios. The local offline server is deployed on the payment terminal side. It is used to perform a tiered deduction operation based on the locally cached balance snapshot when the network is interrupted and temporarily store the transaction data in an unsynchronized state. After the network is restored, it sends a replacement order request to the central server in chronological order. The central server performs a second verification of the actual balance and then credits the account or marks it as abnormal. The transaction query subsystem is used to periodically parse reconciliation files, import transaction details into the consumption details table based on the global serial number, verify the transaction records of each account one by one, and trigger alarms and generate discrepancy reports when discrepancies are found between the accounts and the actual transactions.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: S1: Each user is assigned a unique identifier and associated with multiple points accounts subject to consumption rules. The consumption rules include the scope of applicable merchants, consumption limits, and account validity period. A corresponding deduction priority list and card payment permissions are preset for different consumption scenarios. The deduction priority list defines the deduction order for each points account. By establishing a multi-account system and preset scenario-based deduction priorities and permissions, a rule foundation is provided for subsequent compliant and flexible combined payments, avoiding the fragmentation of multiple systems. S2: After receiving a request initiated by the payment terminal, the payment interface subsystem obtains the user identifier. The system retrieves the consumption scenario identifier and the amount to be paid. Based on the user identifier, it queries the corresponding card type and verifies the card type's payment permissions in the current consumption scenario. If the card type lacks permissions, the request is rejected. If permissions are granted, it obtains a deduction priority list matching the consumption scenario and performs tiered deductions on each points account sequentially using this list. The transaction status is marked based on the deduction results. After the transaction is completed, a transaction record is generated and written to the database. The transaction record includes a global serial number, user identifier, consumption scenario identifier, deduction details for each involved account, and transaction status code. The system then uses card type permissions... Limited verification and tiered priority deduction ensure that welfare funds are used for their designated purpose while automatically making up the difference, improving payment flexibility and fund utilization; S3: When a network connection interruption between the payment terminal and the central server is detected, the system switches to offline mode, executes the tiered deduction operation in S2 based on the locally cached balance snapshot, and temporarily stores the transaction data in a local synchronization table marked as unsynchronized. After the network is restored, a replacement request is sent to the central server in chronological order. The central server performs a second verification based on the actual balance. If the balance is sufficient, the transaction is officially credited and the status is updated to synchronized. If the balance is insufficient, the transaction is marked as abnormal. This triggers a manual processing flow; through local snapshot deduction and secondary verification after network recovery, it balances offline transaction availability and eventual data consistency, preventing over-deduction risks; S4: The transaction query subsystem periodically parses the reconciliation file, imports transaction details into the consumption details table based on the global serial number, and verifies each account's transaction record one by one. The verification content includes transaction amount, deduction account type, deduction amount for each account, and transaction time. If a discrepancy is found, an alarm is triggered and a difference report is generated; through automatic transaction-by-transaction reconciliation driven by the global serial number, timely detection and alarm of accounting differences are achieved, ensuring data accuracy and traceability. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating the steps of the payment method based on multi-account priority deduction and offline secondary verification provided by this invention; Figure 2 This invention provides a schematic diagram of the module flow of a payment system based on multi-account priority deduction and offline secondary verification. Detailed Implementation

[0018] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0019] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0020] To address the problems existing in the background technology, this invention provides a payment method and system based on multi-account priority deduction and offline secondary verification, aiming to achieve compliant combined payment of welfare points, improve the efficiency of fund utilization, ensure offline availability, and realize automatic reconciliation throughout the entire process.

[0021] like Figure 1 As shown, the first aspect of the present invention is to provide a payment method based on multi-account priority deduction and offline secondary verification, comprising the following steps: Step S1: Assign a unique identifier to each user and associate it with multiple points accounts subject to consumption rules. The consumption rules include the scope of applicable merchants, consumption limits, and account validity period. For different consumption scenarios, a corresponding deduction priority list and card payment permissions are preset. The deduction priority list defines the deduction order of each points account.

[0022] It should be noted that, due to the specific spending rules (applicable merchant scope, single transaction limit, validity period, etc.) of different welfare funds (such as meal allowances and welfare payments), and the different deduction order requirements for each account under different consumption scenarios, as well as the different usage permissions of different card types under different scenarios, in order to automatically identify the availability, compliance scope and deduction order of each account during the payment process, and to provide an execution basis for subsequent tiered deductions, it is necessary to pre-establish a multi-account system for each user and associate it with consumption rules, and at the same time configure corresponding deduction priority lists and card payment permissions for each consumption scenario.

[0023] Specifically, (1) assign a unique identifier (physical card number or electronic card number) to each user and use this identifier as the primary key of the user record; (2) Multiple points accounts are associated under this user identifier. Each points account records the account type (catering account, condolence account, subsidy account, general account, etc.), account name, current balance, frozen amount, validity period and status, forming a unified multi-account system. Among them, the general account is not limited to the scope of applicable merchants and is used as a backup account to make up the difference in the subsequent deduction process. (3) Configure consumption rules for each points account, including the scope of applicable merchants (merchant ID whitelist stored in JSON format), consumption limits (single transaction limit, daily cumulative consumption limit) and account validity period; (4) For different consumption scenarios (such as dining in the canteen, exchanging holiday gifts, shopping in online malls, etc.), respectively preset the corresponding deduction priority list (JSON array, arranged in order of account type identifier) ​​and card payment permissions (marked as allowed or prohibited based on card identifier and scenario identifier as a joint dimension).

[0024] The unique identifier is either the physical card number or the electronic card number. The physical card obtains the physical card number through a card reader and is bound to the card number printed on the card. The electronic card number is automatically generated by the system. The same user can hold both a physical card and an electronic card at the same time. Both are associated with the same user record through the user identifier and share the same points account system.

[0025] Step S2: After receiving a request from the payment terminal, the payment interface subsystem obtains the user identifier, consumption scenario identifier, and amount to be paid. It queries the corresponding card type based on the user identifier and verifies the card type's payment permissions in the current consumption scenario. If the card type lacks permissions, the request is rejected. If permissions are granted, a deduction priority list matching the consumption scenario is obtained. A tiered deduction operation is then performed on each points account sequentially using the deduction priority list, and the transaction status is marked based on the deduction results. After the transaction is completed, a transaction record is generated and written to the database. The transaction record includes a global serial number, user identifier, consumption scenario identifier, deduction details for each involved account, and transaction status code.

[0026] It should be noted that, since payment requests contain core elements such as user identification, consumption scenario, and amount to be paid, different card types are assigned different usage permissions in different scenarios. Furthermore, the balances, priority orders, and consumption rules of multiple points accounts under the same user are different. In addition, the tiered deduction process involves the sequential reading, deduction, and balance update of multiple accounts. Failure in any of these steps may lead to accounting chaos. Therefore, in order to ensure the compliant use of funds, automatically complete the multi-account combination deduction in a preset order, record each transaction detail in real time, and ensure the complete rollback of data when the deduction fails, it is necessary to execute three consecutive operations in sequence: permission verification, tiered deduction, and transaction record persistence. This forms a complete closed-loop processing from request reception to transaction completion.

[0027] Specifically, after receiving a request from a payment terminal, the payment interface subsystem obtains the user identifier, the consumption scenario identifier, and the amount to be paid. It then queries the corresponding card type based on the user identifier and verifies the card type's payment permissions in the current consumption scenario. If the card type does not have the permissions, the request is rejected; otherwise, the permissions are granted. Secondly, after the permissions are granted, the system (points processing subsystem) obtains the deduction priority list matching the scenario, reads the balance of each account in sequence in the database transaction and performs a tiered deduction. If the current account balance is sufficient, the full amount is deducted and marked as successful. If the balance is insufficient, the account is deducted and the deduction is carried over to the next account. When all accounts are deducted and the amount to be paid is still not met, the transaction is rolled back and marked as failed. Finally, after the transaction is completed (i.e., a globally unique serial number is generated after a successful deduction), a transaction record is generated and written to the database; and key information is stored in the cache to complete the real-time persistence of the transaction.

[0028] The transaction records include a global serial number, user identifier, consumption scenario identifier, deduction details for each account involved, and transaction status code (success / failure / cancelled).

[0029] The account deduction details include: detail ID, associated global transaction number, deduction account ID, deduction account type, deduction amount, balance before deduction, balance after deduction, and deduction order (which order).

[0030] The tiered deduction operation includes: Suppose the deduction priority list contains N accounts, set the loop variable i=1, and the current amount to be paid is P. Perform a tiered deduction operation on each points account in sequence according to the following sub-steps: S21: Read the available balance of the i-th account. ; S22: If If the transaction is successful, the amount P will be deducted from the i-th account, the deduction details including the account identifier, the amount deducted and the remaining balance will be recorded, the transaction status will be marked as successful, and the process will jump to S3. S23: If Then the amount will be deducted from the i-th account. Record the deduction details and update them. , ; S24: If Then return to S21 to continue execution, if and Then roll back all executed deduction operations, mark the transaction status as failed, and terminate the transaction.

[0031] Before the deduction is executed, the process includes: querying the corresponding consumption rules based on the current consumption scenario, determining whether the amount to be paid exceeds the single consumption limit, and whether the total daily consumption amount plus the amount to be paid exceeds the daily cumulative consumption limit. If they exceed, the request is rejected.

[0032] In S2, the tiered deduction operation is executed within a database transaction, and row-level locking ensures that the balance deduction operation of the same account is executed serially. When S24 determines that the transaction has failed, the entire database transaction is rolled back, restoring the balance of all accounts that have been deducted to the value before the deduction.

[0033] S2 reads the available balance of the i-th account. Previously, it also included checking the account's expiration date; if the current date exceeded the expiration date, the account was skipped. Then return to S21 to continue execution.

[0034] This involves starting a transaction within a database transaction and adding row-level locks to the balance rows of each account involved.

[0035] The complete payment process for multi-account points management payment in this embodiment of the invention includes the following steps: The payment terminal initiates a payment request. After the user swipes their card or scans a code at the POS terminal, the terminal assembles a payment request data packet, including the card number, transaction scenario identifier, amount to be paid, and terminal number, and sends it to the payment interface subsystem via the HTTPS protocol.

[0036] The payment interface subsystem receives and parses the request. It performs signature verification and replay detection on the request, and extracts key fields such as card number, transaction scenario identifier, and amount to be paid after successful verification.

[0037] Card type permission verification. The system queries the user table based on the card number to obtain card type information. Then, it queries the card type permission table based on the card type and the transaction scenario to determine if the card type has payment permissions for the current transaction scenario. If permissions are not granted, an error code and failure message are returned, and the process ends.

[0038] Retrieve the deduction priority list. Based on the consumption scenario identifier, query the consumption rules table to obtain the deduction priority list (JSON format) matching that scenario, and parse it into an ordered array of account identifiers.

[0039] Perform tiered balance deductions. Call the `cascade_deduct` function of the points processing subsystem to perform deductions for each account sequentially according to the priority list. This step is executed within a database transaction to ensure atomicity.

[0040] Determine the deduction result. If the deduction is successful, generate a transaction record and deduction details containing a global serial number, write them to the transaction record table and deduction details table, update the balance of each account, and commit the transaction; if the deduction fails (insufficient balance), roll back the transaction and return an insufficient balance message.

[0041] Simultaneously write to the local cache. While writing transaction records to the central database, write key transaction information (transaction number, amount, status) to the Redis cache for later querying.

[0042] Return the transaction result. Assemble the transaction status, transaction number, deduction details, and other information into a response message and return it to the payment terminal.

[0043] Step S3: When the network connection between the payment terminal and the central server is interrupted, switch to offline mode, perform the tiered deduction operation in S2 based on the locally cached balance snapshot, and temporarily store the transaction data in the local synchronization table and mark it as unsynchronized. After the network is restored, send a replacement order request to the central server in chronological order. The central server performs a second verification based on the actual balance. If the balance is sufficient, the transaction is officially credited and the status is updated to synchronized. If the balance is insufficient, the transaction is marked as abnormal and a manual processing procedure is triggered.

[0044] It should be noted that since payment terminals are usually deployed in physical locations such as canteens and shopping malls, the network environment is unstable. The online mode of the central server requires payment requests to connect to the database in real time. Once the network is interrupted, the transaction cannot be completed. Furthermore, users may still make purchases on other terminals during offline periods. If offline deductions are simply allowed without post-verification, there is a risk of over-deduction due to multiple channels of consumption during offline periods. Therefore, in order to ensure the continuous availability of transactions in weak or offline environments, and to prevent inconsistencies in accounts caused by concurrent consumption afterward, a local balance snapshot mechanism needs to be introduced to support offline deductions. After the network is restored, the central server will perform a second verification of the actual balance to confirm or reject the offline transaction, thereby achieving a balance between availability and data consistency.

[0045] The specific steps are as follows: (1) Network status detection: The local offline server sends heartbeat packets to the central server periodically (heartbeat cycle is 30 seconds) through a heartbeat mechanism. When the heartbeat times out without response for a preset number of consecutive times (such as 3 times), the network is determined to be interrupted and the system automatically switches to offline mode.

[0046] (2) Local balance snapshot maintenance: When online, the local offline server periodically (e.g., hourly) incrementally synchronizes the account balance snapshots of each user from the central server (only synchronizing account balance records that have changed since the last snapshot time), and stores them in the balance snapshot table of the local embedded database (e.g., SQLite).

[0047] (3) Offline transaction processing: In offline mode, the payment request initiated by the payment terminal is taken over and processed by the local offline server. Based on the local cached balance snapshot, the same step-by-step deduction operation as in online mode is performed. After the deduction is completed, the transaction record is written to the local table to be synchronized, the status is marked as "not synchronized", and the local balance snapshot is updated at the same time.

[0048] (4) Network recovery and automatic order replenishment: The local offline server continuously monitors the network status. When the heartbeat is restored, it determines that the network is connected. The background synchronization service reads the "unsynchronized" transaction records in the synchronization table in ascending order of transaction time, calls the offline order replenishment interface of the central server one by one, and sends the order replenishment request to the central server.

[0049] (5) Secondary verification and accounting by the central server: After receiving the order supplement request, the central server queries the actual balance of each account at the current time according to the user identifier and re-executes the balance adequacy verification; if the balance is sufficient, the deduction is officially executed and the transaction status is updated to "synchronized"; if the balance is insufficient (due to the consumption of other terminals during offline period, the balance is insufficient to cover the transaction), the transaction is marked as "abnormal" and the manual processing process is triggered (an abnormal work order is generated and pushed to the reconciliation personnel).

[0050] The local cached balance snapshot is obtained from the central server through an incremental synchronization mechanism, and only account balance records that have changed since the last snapshot time are synchronized; the network status is detected by a heartbeat mechanism, and the network is determined to be interrupted when the heartbeat times out for a preset number of consecutive times.

[0051] The transaction record also includes a transaction timestamp and a terminal number. The transaction timestamp uses the server time. The global serial number is generated by combining the date, time and serial number to ensure global uniqueness.

[0052] Step S4: The transaction query subsystem periodically parses the reconciliation file, imports the transaction details into the consumption details table based on the global serial number, and verifies the transaction records of each account one by one. The verification content includes the transaction amount, deduction account type, deduction amount of each account and transaction time. If a discrepancy is found between the account and the actual transaction, an alarm is triggered and a difference report is generated.

[0053] It should be noted that, due to the existence of multiple data sources and processing paths in the system, such as online transactions, offline order replenishment, and secondary verification rejections, and the potential differences in the timing and synchronization status of transaction records written by various payment terminals, as well as inconsistencies between account balance changes stored in the database and deduction details uploaded by terminals due to factors such as network jitter, program abnormalities, or human operation, it is necessary to establish an independent asynchronous reconciliation mechanism in order to promptly detect and locate data anomalies such as discrepancies between accounts and actual transactions, missing records, or amount deviations, and to ensure the accuracy and integrity of accounting data. This mechanism will periodically compare the transaction details in the reconciliation file with the database records one by one, and trigger alarms and discrepancy reports when discrepancies are found, thereby achieving automatic auditing and closed-loop correction of system data.

[0054] The specific steps are as follows: (1) Reconciliation file generation: Every day at midnight (e.g., 00:30), the points processing subsystem automatically generates a reconciliation file (CSV format, file name such as recon_yyyyMMdd.csv) for all transactions of the previous day. Each transaction record includes a global transaction number, card number, consumption scenario ID, each deduction account type, each account deduction amount, total transaction amount, transaction time, terminal number and transaction status code.

[0055] (2) Parsing and importing reconciliation files: The transaction query subsystem reads the reconciliation file through a scheduled task (such as 2:00 am every day), parses it line by line, imports the transaction details into the consumption details table according to the global serial number, and establishes a local dataset to be verified.

[0056] (3) Transaction-by-transaction verification: The system uses the global serial number as the primary key to compare each record in the reconciliation file with the corresponding record in the database transaction record table and deduction details table. The verification includes: whether the transaction amount is consistent, whether the deduction account type is matched, whether the deduction amount of each account is equal, and whether the transaction time deviation is within the allowable range (e.g., ±3 seconds).

[0057] (4) Difference determination and classification: Based on the verification results, the difference records are classified as follows: amount mismatch (the transaction amount in the reconciliation file is inconsistent with the transaction record in the database), account type mismatch (the account type in the deduction details does not match), time mismatch (the transaction time deviation exceeds the threshold), and missing record (exists in the reconciliation file but there is no corresponding record in the database, or vice versa).

[0058] (5) Alarm triggering and difference report generation: If a discrepancy is found between the accounts and the actual situation, the system will automatically trigger an alarm (pushed to the reconciliation personnel via email or system message) and generate a difference report in Excel format. The report includes the difference serial number, difference type, expected value, actual value and handling suggestions for the reconciliation personnel to check and correct.

[0059] The offline mode processing flow in this embodiment of the invention includes the following steps: Network status detection. The local offline server uses a heartbeat mechanism to detect the network connection status with the central server, with a heartbeat cycle of 30 seconds. If three consecutive heartbeats time out (i.e., no response within 90 seconds), the network is considered interrupted, and the server automatically switches to offline mode.

[0060] Local balance snapshot synchronization. While online, the local offline server synchronizes a snapshot of each user's account balance from the central server hourly, storing it in the `t_balance_snapshot` table of the local SQLite database. This table contains fields such as `user_id`, `account_type`, `balance`, and `snapshot_time`.

[0061] Offline transaction processing. In offline mode, payment requests sent by the payment terminal are processed by the local offline server. A tiered deduction logic is executed based on the local balance snapshot, identical to the S3 steps in online mode. After deduction, the transaction record is written to the local t_offline_transaction table to be synchronized. This table adds a sync_status field to the transaction record table, marking the status as "not synchronized" (value 1), and simultaneously updates the local balance snapshot.

[0062] Network recovery detection and automatic synchronization. The local offline server continuously monitors the network status, and determines network connectivity once the heartbeat is restored. The background synchronization service reads records with sync_status=1 in t_offline_transaction in t_offline_transaction according to txn_time, and calls the offline order completion interface of the central server (POST / api / v1 / payment / offline-sync) for each record.

[0063] The central server performs a second verification. After receiving a request to replenish the account, the central server queries the actual balance of each account based on the card number and performs a second verification. If the balance is sufficient, the transaction is officially credited, and the transaction status in the local and central databases is updated to "synchronized" (sync_status=0). If the balance is insufficient (due to consumption through other channels during offline operation), the transaction is marked as "abnormal" (sync_status=2), an abnormal work order is generated, and the manual processing procedure is triggered.

[0064] Data reconciliation. A daily scheduled task (e.g., 2:00 AM) compares the transaction records of the central database with those of the local offline server to confirm that all offline transactions have been synchronized.

[0065] In this embodiment of the invention, the asynchronous reconciliation process includes the following steps: Reconciliation file generation. Every day at midnight, the points processing subsystem generates the previous day's reconciliation file in CSV format. Each line of the record contains: global transaction number, card number, consumption scenario ID, deduction account type, deduction amount, transaction time, terminal number, and transaction status.

[0066] Reconciliation file parsing. The transaction query subsystem reads the reconciliation file through a scheduled task, parses the transaction records line by line, and searches for the corresponding record in the consumption details table based on the global transaction number.

[0067] Verify each transaction individually. For each transaction, verify the following fields: transaction amount (total_amount), account type (account_type), amount deducted from each account (deduct_amount), and transaction time (txn_time) to ensure they are consistent.

[0068] Discrepancy handling. If a discrepancy is found between the recorded and actual amounts, the system will automatically trigger an alarm (pushed to the reconciliation personnel via email or system notification) and generate a discrepancy report, which includes the discrepancy serial number, the discrepancy type (amount discrepancy / account type discrepancy / time discrepancy / missing record), and a comparison between the expected and actual values.

[0069] like Figure 2 As shown, a second aspect of the present invention is to provide a payment system based on multi-account priority deduction and offline secondary verification, comprising: The database subsystem 101 is used to store user information, data of multiple points accounts subject to consumption rules, and transaction records. The consumption rules include the scope of applicable merchants, single transaction limit, and account validity period. The points processing subsystem 102 is used to perform tiered balance deductions on each points account according to the deduction order defined in the preset deduction priority list, using a loop variable i and the amount to be paid P. If the available balance of the i-th account is... If the amount is not less than P, the full amount will be deducted and the transaction status will be marked as successful. If it is less than P, then deduct. And update Then, increment i and continue execution. If P is still greater than zero after all accounts have been deducted, roll back all executed deductions and mark the transaction status as failed. The payment interface subsystem 103 is used to connect to the payment terminal, receive and parse payment requests containing user identifier, consumption scenario identifier and amount to be paid; The management subsystem 104 is used to configure the deduction priority list and card payment permissions for each consumption scenario, and to verify the payment permissions of the card in the corresponding consumption scenario. Local offline server 105 is deployed on the payment terminal side. It is used to perform a tiered deduction operation based on the locally cached balance snapshot when the network is interrupted and temporarily store the transaction data in an unsynchronized state. After the network is restored, it sends a replacement order request to the central server in chronological order. The central server performs a second verification of the actual balance and then credits the account or marks it as abnormal. The transaction query subsystem 106 is used to periodically parse reconciliation files, import transaction details into the consumption details table based on the global serial number, verify the transaction records of each account one by one, and trigger alarms and generate discrepancy reports when discrepancies are found between the accounts and the actual transactions.

[0070] The points processing subsystem ensures atomicity and concurrency safety of the operation by using database transactions and row-level locks when performing tiered balance deductions, and rolls back the entire transaction when the transaction fails.

[0071] The management subsystem includes at least one of the following: a data import module, a card management module, a consumption rule configuration module, and a permission management module. The data import module is used to import personnel information tables by matching welfare distribution templates to achieve batch welfare distribution. The card management module is used to perform operations such as reporting lost cards, unblocking lost cards, replacing lost cards, and recharging cards. The card replacement operation automatically migrates the original card account information and balance to the new card. The consumption rule configuration module is used to configure the deduction priority list and applicable merchant range for each consumption scenario. The permission management module is used to customize management roles and assign operation permissions.

[0072] The subsystems communicate with each other through an internal service bus, using the RESTful API interface specification, with data transmission format in JSON and communication protocol in HTTPS / TLS 1.2 or above.

[0073] The database subsystem uses a relational database (such as MySQL or PostgreSQL) as the primary storage engine, responsible for persistently storing core business data such as user information, account data, transaction records, card permission configurations, and consumption rules. The primary database employs a master-slave replication architecture, with the master node handling read and write operations and the slave nodes providing read-only query services. Read-write separation is achieved through database middleware. Simultaneously, the database subsystem integrates a Redis caching layer to cache frequently accessed account balance data and consumption rule configurations. The cache update strategy uses a timestamp-based incremental synchronization mechanism.

[0074] The points processing subsystem, serving as the core business engine, is deployed in an application server cluster and receives requests through a load balancer. This subsystem is responsible for executing the tiered balance deduction logic and managing the issuance, freezing, unfreezing, and transfer of points. To ensure the atomicity of the deduction operations, the points processing subsystem employs a concurrency control strategy combining database transactions and distributed locks: in online mode, a SELECT FOR UPDATE row-level lock ensures that balance deduction operations for the same account are executed serially; in a distributed deployment scenario, a distributed mutex lock is implemented using the Redis SETNX command, with a lock expiration time set to 3 seconds, a retry interval of 50 milliseconds for acquiring the lock, and a maximum number of retries of 10.

[0075] The payment interface subsystem encapsulates a unified API gateway, interfacing with payment terminals such as POS machines, online stores, and mobile apps. This subsystem is responsible for receiving HTTPS requests from payment terminals, parsing request parameters, performing signature verification and replay attack detection, and forwarding the standardized payment requests to the points processing subsystem. The payment interface subsystem supports both persistent and short-lived connections. For fixed devices such as POS terminals, TCP persistent connections are used to reduce communication latency, while HTTP short-lived connections are used for mobile apps to adapt to dynamic network environments.

[0076] The transaction query subsystem provides functions for querying transaction details, monthly balance snapshots, and account reconciliation. This subsystem parses the reconciliation file generated the previous day through a scheduled task (such as 2:00 AM every day), imports the transaction details into the consumption details table based on the global serial number, and performs a transaction-by-transaction reconciliation.

[0077] The management subsystem provides a web-based management backend, implemented using a B / S architecture, with a responsive frontend to adapt to both desktop and mobile browsers. The management subsystem includes modules for data import, card management, consumption rule configuration, access control, and POS machine management.

[0078] The local offline server is deployed on the payment terminal side and uses a lightweight embedded database (such as SQLite) to store local data. It periodically (e.g., hourly) synchronizes snapshots of each user's account balance from the central server. In the event of a network outage, the local offline server takes over the processing of payment requests, performs deduction operations based on the local balance snapshot, and temporarily stores the transaction data in a table to be synchronized.

[0079] In this embodiment of the invention, the payment interface subsystem employs the following security mechanisms to ensure communication security: (1) Request signature: All API requests must carry a signature, and the signature algorithm is HMAC-SHA256. The signature rules are as follows: Arrange the request parameters in lexicographical order of the field names, concatenate them into the key=value format, connect them with "&", perform HMAC-SHA256 operation using the pre-allocated key, generate a hexadecimal signature value, and place it in the X-Request-Sign field of the request header.

[0080] (2) Anti-replay attack: Each request carries an X-Timestamp field, and the server verifies that the deviation between the request time and the server time does not exceed 5 minutes; at the same time, the server maintains a cache of serial numbers of processed requests (TTL is 10 minutes), and directly rejects requests with duplicate serial numbers.

[0081] (3) Data encryption: All communications are encrypted using HTTPS / TLS 1.2 or above, and sensitive fields (such as card numbers) are anonymized in the logs.

[0082] The detailed implementation process of the management terminal function is as follows: Batch welfare distribution. Administrators upload Excel files conforming to a template format through the management subsystem. Fields include employee ID, name, welfare type, amount, and distribution time. The system parses the Excel file, matches it to the welfare distribution template, verifies data integrity, and then writes the distribution records to the account table using batch SQL INSERT statements, increasing the corresponding user's account balance accordingly. The distribution process is executed within a database transaction; if any record fails, the entire batch is rolled back.

[0083] Card lifecycle management. The system supports both physical and electronic cards. Physical cards obtain the physical card number (M1 card serial number) through a dedicated card reader and bind it to the 6-digit card number on the card face to complete the database registration; electronic cards are automatically generated with a unique 6-digit electronic card number based on the Snowflake algorithm. Card management operations include: reporting a lost card (marking the card status as "lost" and freezing all associated accounts), unblocking the card (restoring the "normal" status and unfreezing the account), and replacing the card (generating a new card number, updating the card_no field in the account record associated with the original card to the new card number using an SQLUPDATE statement, and automatically migrating the balance to the new card).

[0084] POS terminal management. Each POS terminal is registered in the database via a terminal registration interface. Registration information includes the terminal number, deployment region, and IP address. Each POS terminal can be configured with multiple sets of payment rules, automatically switching the corresponding deduction priority list based on the payment scenario. POS terminals support offline mode, ensuring uninterrupted card transactions during network outages.

[0085] Access Control. The system pre-configures four roles: finance personnel, customer service personnel, operations and maintenance personnel, and reconciliation personnel. Each role corresponds to a different set of functional permissions. Administrators can customize roles and assign fine-grained menu and data permissions. Data permissions are controlled at the department level, ensuring that each role can only view data within its authorized scope.

[0086] In the specific implementation process, the global serial number is generated according to the rule yyyyMMddHHmmss + 6-digit sequence number, such as 20260617134800000001, ensuring global uniqueness. Transaction timestamps are accurate to the millisecond level, using server time instead of terminal time to avoid time inconsistencies caused by terminal clock deviations. Transaction status codes include: 1 - Success (all deduction operations completed), 2 - Failure (insufficient balance or permission denied), 3 - Revoked (transaction revocation operation initiated by the management end). Transaction records are simultaneously written to the central database (t_transaction table and t_deduction_detail table) and Redis cache, with the cache key format txn:{txn_no} and TTL set to 7 days.

[0087] In practice, network status detection is achieved through a heartbeat mechanism with a 30-second heartbeat cycle. Three consecutive timeouts are considered a network interruption. Local balance snapshots are synchronized from the central server hourly, using an incremental update strategy to synchronize only account balance records that have changed since the last snapshot time, reducing data transmission volume. In offline mode, the local offline server performs deduction operations based on an SQLite database, with logic completely consistent with online mode. Offline transaction records are written to the `t_offline_transaction` table, and the `sync_status` field is marked as 1 (not synchronized). After network recovery, the synchronization service reads unsynchronized records in ascending order of `txn_time` and calls the central server's offline transaction completion interface for each record. When the central server performs secondary verification, it checks whether the current actual balance of each account meets the deduction requirements within the database transaction: if it does, the deduction is performed and `sync_status` is updated to 0 (synchronized); if it does not meet the requirements (e.g., balances consumed through other channels during offline operation), `sync_status` is updated to 2 (abnormal), and an abnormal work order is generated and pushed to reconciliation personnel.

[0088] By adopting the above technical solution, through offline transaction storage and automatic synchronization after network recovery, as well as a secondary verification mechanism, the strong dependence of traditional solutions on the network is overcome, significantly improving the availability of the payment system in weak network environments. At the same time, the secondary verification ensures the eventual consistency of the data.

[0089] In some preferred embodiments of this application, an asynchronous reconciliation step is also included: the transaction query subsystem periodically parses the reconciliation file, imports the transaction details into the consumption details table according to the global serial number, checks the transaction records of each account one by one, and if a discrepancy is found, an alarm is triggered and a difference report is generated.

[0090] In practice, the reconciliation file is in CSV format, automatically generated by the points processing subsystem every day at midnight, with the filename format recon_yyyyMMdd.csv. The transaction query subsystem reads the reconciliation file through a scheduled task (e.g., 2:00 AM daily) and parses the transaction records line by line. For each transaction, the corresponding record is searched in the consumption details table based on the global transaction number, and the transaction amount, deduction account type, deduction amount for each account, and transaction time are checked for consistency. Discrepancies include: amount discrepancies (total_amount in the reconciliation file does not match the database record), account type discrepancies (account_type in the deduction details does not match), time discrepancies (txn_time deviation exceeds the threshold), and missing records (transactions that exist in the reconciliation file but not in the database, or vice versa). A discrepancy report is generated in Excel format, including the discrepancy transaction number, discrepancy type, expected value, actual value, and processing suggestions, and is automatically sent to the reconciliation personnel's email address.

[0091] By adopting the above technical solution and using an asynchronous reconciliation mechanism, automatic verification and discrepancy detection of transaction data are achieved, reducing the workload and error rate of manual reconciliation and improving the data reliability of the system.

[0092] In some preferred embodiments of this application, the transaction-by-transaction verification includes: searching for the corresponding item in the consumption database based on the global serial number, and verifying whether the transaction amount, deduction account type, deduction amount for each account, and transaction time are consistent.

[0093] In practice, each transaction is checked individually, with the global transaction number as the primary key. Since the global transaction number is unique within the system, it serves as a reliable matching criterion. During the verification process, the system compares transaction amounts down to the cent to avoid floating-point precision issues; the deduction account type and the amount deducted from each account are verified by comparing records in the deduction details table; a deviation of plus or minus 3 seconds is allowed for transaction time verification to compensate for clock discrepancies between different servers. For transaction records that cannot be matched, the system marks them as "orphaned records," and the number of orphaned records on both the reconciliation file and database sides is counted for reconciliation personnel to investigate.

[0094] By adopting the above technical solution and using a transaction-by-transaction verification mechanism with a global serial number as the unique matching key, the accuracy and completeness of the reconciliation are ensured, and the omission and tampering of transaction data are effectively prevented.

[0095] In some preferred embodiments of this application, the unique identifier is a physical card number or an electronic card number; the physical card obtains the physical card number through a card reader and binds it to the card number printed on the card face, and the electronic card has an electronic card number automatically generated by the system.

[0096] In practice, the physical card uses an M1 contactless IC card, storing a unique physical card number (UID). After the card reader reads the UID via radio frequency induction, the system queries a binding relationship table to confirm the printed card number corresponding to that UID, thus linking it to the user record. The electronic card number is generated by the system based on the Snowflake algorithm, ensuring uniqueness in a distributed environment. The electronic card is displayed as a QR code in the mobile app, and the payment terminal obtains the electronic card number by scanning the QR code. The same user can hold both a physical card and an electronic card simultaneously; both are linked to the same user record through the user_id field and share the same points account system.

[0097] By adopting the above technical solution, which supports both physical and electronic cards, it adapts to the payment needs of different scenarios. Physical cards are suitable for fast card swiping in fixed places such as canteens, while electronic cards are suitable for mobile payment scenarios such as online shopping malls, thereby improving the applicability of the system and the user experience.

[0098] In some embodiments of this application, a multi-account points management payment system is provided, including a database subsystem, a points processing subsystem, a payment interface subsystem, and a management subsystem. The database subsystem stores user information, data for multiple points accounts, and transaction records. The points processing subsystem performs balance deduction operations for points accounts, deducting balances from each account sequentially according to a pre-defined deduction priority list. The payment interface subsystem connects to payment terminals, receiving and parsing payment requests. The management subsystem configures deduction priority lists and consumption rules for each consumption scenario and verifies the payment permissions of cards in the corresponding consumption scenarios.

[0099] In practice, the subsystems communicate via an internal service bus. The database subsystem uses a MySQL master-slave architecture, with the master node handling write operations and the slave nodes providing read services. The points processing subsystem is deployed on an application server cluster, using Nginx load balancing to distribute requests, with the core deduction logic executed within database transactions. The payment interface subsystem acts as an API gateway, uniformly managing terminal access, signature verification, and request routing. The management subsystem's web backend is implemented using the Spring Boot framework, while the frontend uses the Vue.js framework, providing a responsive management interface.

[0100] By adopting the above technical solution and through modular system architecture design, the responsibilities of each subsystem are clear and the coupling is low, which facilitates independent deployment and expansion, and improves the maintainability and scalability of the system.

[0101] In some preferred embodiments of this application, the system further includes a local offline server deployed on the payment terminal side, with a built-in lightweight embedded database, used to perform deduction operations based on locally cached balance snapshots and temporarily store transaction data when the network is interrupted, and to synchronize and reconcile data with the database subsystem after the network is restored.

[0102] In practice, the local offline server uses small computing devices such as Raspberry Pi or industrial PCs, running a Linux operating system and an SQLite database. Balance snapshot synchronization employs an HTTP long polling mechanism, with the central server maintaining the snapshot version number for each terminal and proactively pushing incremental updates when balances change. Offline transaction data is temporarily stored in the `t_offline_transaction` table in SQLite, with a structure consistent with the transaction record table in the central database, plus an additional `sync_status` field. The synchronization process after network recovery adopts a "first-in, first-out" strategy to ensure the timeliness of transactions.

[0103] By adopting the above technical solution and deploying local offline servers, transaction continuity is guaranteed in the event of network interruption, while the automatic synchronization and secondary verification mechanism ensures eventual data consistency.

[0104] In some preferred embodiments of this application, the management subsystem includes at least one of a data import module, a card management module, a consumption rule configuration module, and a permission management module; the data import module is used to import personnel information tables by matching welfare distribution templates to achieve batch welfare distribution; the card management module is used to perform card loss reporting, unblocking, card replacement, and recharge operations; the card replacement operation automatically migrates the original card account information and balance to the new card; the consumption rule configuration module is used to configure the deduction priority list and applicable merchant range for each consumption scenario; and the permission management module is used to customize management roles and assign operation permissions.

[0105] In practical implementation, the data import module supports importing files in both Excel and CSV formats. Before importing, it automatically validates the data format (e.g., whether the employee ID is a number, whether the amount is positive, and whether the welfare type is valid). Records failing validation generate error reports for administrator correction. The card management module's card replacement operation is executed through database transactions. First, a new card record is created. Then, the `card_no` field in the account records associated with the original card is updated in batches to the new card number. Finally, the original card status is marked as "replaced." The consumption rule configuration module provides a visual drag-and-drop interface, allowing administrators to adjust the account order in the deduction priority list via drag-and-drop. The configuration results take effect in real time. The permission management module is based on the RBAC (Role-Based Access Control) model, supporting three-level configuration: role-permission-menu. Data permissions are implemented through SQL WHERE condition injection.

[0106] By adopting the above technical solution and through the modular design of the management subsystem, the entire process of welfare distribution, card management, rule configuration and permission management has been digitized, which significantly reduces the cost of manual operation and management risks.

[0107] In some embodiments of this application, an electronic device is provided, including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the multi-account points management payment method as described in the first aspect of the present invention.

[0108] In specific implementation, mobile electronic devices can be, for example, mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network-attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. This application embodiment does not impose specific limitations. The electronic device used for multi-account points management payment in this application embodiment can be an electronic device with an operating system. This operating system can be Android, iOS, or other possible operating systems, which this application embodiment does not specifically limit.

[0109] In some embodiments of this application, a readable non-transitory storage medium is provided, on which a program or instructions are stored, which, when executed by a processor, implement the steps of the multi-account points management payment method as described in the first aspect of the present invention.

[0110] In practice, readable non-transitory storage media may be used, including computer-readable non-transitory storage media such as computer read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0111] This invention achieves unified management and flexible payment combinations of points from multiple sources by linking multiple points accounts to a single user identifier and combining this with a dynamic priority deduction mechanism based on consumption scenarios. Card validity verification and tiered sequential deduction automatically ensure the compliant use of welfare funds. Offline transaction storage and automatic synchronization after network recovery, along with a secondary verification mechanism, significantly improve the availability of the payment system in weak network environments. A unified transaction record format and a transaction-by-transaction reconciliation process enable end-to-end data traceability from welfare distribution and consumption to settlement. This concludes the embodiment.

[0112] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, optical storage, etc.) containing computer-usable program code.

[0113] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, systems, and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0114] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0115] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0116] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the present invention.

Claims

1. A payment method based on multi-account priority deduction and offline secondary verification, characterized in that, Includes the following steps: S1: Assign a unique identifier to each user and associate it with multiple points accounts subject to consumption rules. The consumption rules include the scope of applicable merchants, consumption limits and account validity period. For different consumption scenarios, a corresponding deduction priority list and card payment permissions are preset. The deduction priority list defines the deduction order of each points account. S2: After receiving a request from the payment terminal, the payment interface subsystem obtains the user identifier, the consumption scenario identifier, and the amount to be paid. Based on the user identifier, it queries the corresponding card type and verifies the payment authority of the card type in the current consumption scenario. If the card type does not have the authority, the request is rejected. If the card type has the authority, it obtains a deduction priority list matching the consumption scenario and performs a tiered deduction operation on each points account in sequence according to the deduction priority list. The transaction status is marked based on the deduction result. After the transaction is completed, a transaction record is generated and written to the database. The transaction record includes a global serial number, user identifier, consumption scenario identifier, deduction details of each involved account, and transaction status code. S3: When the network connection between the payment terminal and the central server is interrupted, switch to offline mode, execute the step-by-step deduction operation in S2 based on the locally cached balance snapshot, and temporarily store the transaction data in the local synchronization table and mark it as unsynchronized. After the network is restored, send a replacement order request to the central server in chronological order. The central server performs a second verification based on the actual balance. If the balance is sufficient, the transaction is officially credited and the status is updated to synchronized. If the balance is insufficient, the transaction is marked as abnormal and a manual processing procedure is triggered. S4: The transaction query subsystem periodically parses the reconciliation file and imports the transaction details into the consumption details table based on the global serial number. It then verifies each transaction record of each account, including the transaction amount, deduction account type, deduction amount for each account, and transaction time. If a discrepancy is found between the account and the actual transaction, an alarm is triggered and a discrepancy report is generated.

2. The payment method based on multi-account priority deduction and offline secondary verification according to claim 1, characterized in that, The tiered deduction operation includes: Suppose the deduction priority list contains N accounts, set the loop variable i=1, and the current amount to be paid is P. Perform a tiered deduction operation on each points account in sequence according to the following sub-steps: S21: Read the available balance of the i-th account. ; S22: If If the transaction is successful, the amount P will be deducted from the i-th account, the deduction details including the account identifier, the amount deducted and the remaining balance will be recorded, the transaction status will be marked as successful, and the process will jump to S3. S23: If Then the amount will be deducted from the i-th account. Record the deduction details and update them. , ; S24: If Then return to S21 to continue execution, if and Then roll back all executed deduction operations, mark the transaction status as failed, and terminate the transaction.

3. The payment method based on multi-account priority deduction and offline secondary verification according to claim 1, characterized in that, The multiple points accounts in S1 include at least two of the following types of accounts: catering accounts, welfare accounts, subsidy accounts, and general accounts. The general accounts are not limited to the scope of applicable merchants and are used as a backup account to make up the difference in S2.

4. The payment method based on multi-account priority deduction and offline secondary verification according to claim 1, characterized in that, The local cached balance snapshot in S3 is obtained from the central server through an incremental synchronization mechanism, and only account balance records that have changed since the last snapshot time are synchronized; the network status is detected by a heartbeat mechanism, and the network is determined to be interrupted when the heartbeat times out for a preset number of consecutive times.

5. The payment method based on multi-account priority deduction and offline secondary verification according to claim 1, characterized in that, The unique identifier is either the physical card number or the electronic card number; the physical card obtains the physical card number through a card reader and is bound to the card number printed on the card face, while the electronic card has an electronic card number automatically generated by the system; the same user can hold both a physical card and an electronic card at the same time, and the two are associated with the same user record through the user identifier and share the same points account system.

6. The payment method based on multi-account priority deduction and offline secondary verification according to claim 2, characterized in that, The consumption limit in S1 includes a single transaction limit and a daily cumulative consumption limit. Before performing the deduction, S2 also includes: querying the corresponding consumption rules according to the current consumption scenario, determining whether the amount to be paid exceeds the single transaction limit, and whether the daily cumulative consumption amount plus the amount to be paid exceeds the daily cumulative consumption limit. If they exceed, the request is rejected.

7. The payment method based on multi-account priority deduction and offline secondary verification according to claim 1, characterized in that, The transaction record in S3 also includes a transaction timestamp and a terminal number. The transaction timestamp uses the server time. The global serial number is generated by combining the date, time and serial number to ensure global uniqueness.

8. The payment method based on multi-account priority deduction and offline secondary verification according to claim 2, characterized in that, The step-by-step deduction operation in S2 is executed within a database transaction, and row-level locking ensures that the balance deduction operation of the same account is executed serially. When S24 determines that the transaction has failed, the entire database transaction is rolled back, restoring all account balances that have been deducted to their values ​​before the deduction.

9. The payment method based on multi-account priority deduction and offline secondary verification according to claim 2, characterized in that, S2 reads the available balance of the i-th account. Previously, it also included checking the account's expiration date; if the current date exceeded the expiration date, the account was skipped. Then return to S21 to continue execution.

10. A payment system based on multi-account priority deduction and offline secondary verification, used to implement the payment method based on multi-account priority deduction and offline secondary verification as described in any one of claims 1-9, characterized in that, include: The database subsystem is used to store user information, data of multiple points accounts subject to consumption rules, and transaction records. The consumption rules include the scope of applicable merchants, single transaction limit, and account validity period. The points processing subsystem is used to perform tiered balance deductions on each points account according to the deduction order defined in the preset deduction priority list, using a loop variable i and the amount to be paid P. If the available balance of the i-th account is... If the amount is not less than P, the full amount will be deducted and the transaction status will be marked as successful. If it is less than P, then deduct. And update Then, increment i and continue execution. If P is still greater than zero after all accounts have been deducted, roll back all executed deductions and mark the transaction status as failed. The payment interface subsystem is used to connect to payment terminals, receive and parse payment requests containing user identifiers, consumption scenario identifiers and the amount to be paid; The management subsystem is used to configure the deduction priority list and card payment permissions for each consumption scenario, and to verify the payment permissions of cards in the corresponding consumption scenarios. The local offline server is deployed on the payment terminal side. It is used to perform a tiered deduction operation based on the locally cached balance snapshot when the network is interrupted and temporarily store the transaction data in an unsynchronized state. After the network is restored, it sends a replacement order request to the central server in chronological order. The central server performs a second verification of the actual balance and then credits the account or marks it as abnormal. The transaction query subsystem is used to periodically parse reconciliation files, import transaction details into the consumption details table based on the global serial number, verify the transaction records of each account one by one, and trigger alarms and generate discrepancy reports when discrepancies are found between the accounts and the actual transactions.

Images