Rail transit riding fee deduction method and riding fee deduction system

Abstract

The invention discloses a riding fee deduction method and a riding fee deduction system for rail transit. The riding fee deduction method for the rail transit comprises the following steps: acquiring and analyzing an inbound transaction generated by a user at an inbound terminal, marking the inbound transaction as unmatched, and storing the marked inbound transaction to a database; in response to the outbound transaction generated by the user at the outbound terminal, searching a previous unmatched inbound transaction in the database to match a journey from the inbound transaction to the outbound transaction; and calculating the fee of the journey, and initiating fee deduction of the amount corresponding to the journey to the user in response to the fact that the current fee deduction mode is real-time fee deduction. In this way, the rail transit fee error rate can be reduced, and the user experience is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of rail transit electronic payment, in particular to a rail transit fare deduction method and system. BACKGROUND

[0002] With the popularization of rail transit two-dimensional code payment, single code ticketing has become an industry development trend. Single code ticketing only serves as a unique user identity credential, and the entry and exit station status is uniformly managed by the background, which helps to improve system security and compatibility.

[0003] In the prior art, common deduction modes mainly include real-time deduction and delayed deduction. Real-time deduction initiates deduction immediately when the user exits. However, when the gate is offline or transaction uploading is not timely, it will cause abnormal matching of the trip, resulting in incorrect deduction and high user complaint rate. Delayed deduction usually matches the trip and deducts in batches at the end of the day or the next day. Although it reduces the probability of incorrect deduction, it has the problem of deduction delay and poor user experience. Therefore, the existing scheme either cannot balance real-time and accuracy, or needs complex refund and trip reorganization processing, frequent system interaction and large resource consumption. SUMMARY

[0004] The present application mainly provides a rail transit fare deduction method and system to solve the problems of high rail transit fee error rate and poor deduction experience.

[0005] To solve the above technical problems, one technical solution adopted by the present application is to provide a rail transit fare deduction method, comprising: obtaining and analyzing an entry transaction generated by a user at an entry terminal, marking the entry transaction as unmatched, and saving the marked entry transaction to a database; in response to the user generating an exit transaction at an exit terminal, searching for the last unmatched entry transaction in the database to match a trip from the entry transaction to the exit transaction; calculating the cost of the trip, and in response to the current deduction mode being real-time deduction, initiating deduction of the amount corresponding to the trip to the user.

[0006] In some embodiments, the response to the user in the outbound terminal generates outbound transactions, in the database to find the last unmatched inbound transaction, to match the inbound transaction to the outbound transaction after the itinerary, further comprises: in response to the database to increase the outbound transaction and the new inbound transaction between the inbound transaction, according to the time of the new outbound transaction and the new inbound transaction, the itinerary is divided into several new itinerary; the calculation of the itinerary cost, and in response to the current charge mode is real-time charge, to the user to initiate the itinerary corresponding amount of charge, including: respectively calculate the cost of each segment of the itinerary after splitting, and in response to the current charge mode is real-time charge, to the user to initiate each segment of the itinerary corresponding amount of charge.

[0007] In some embodiments, the response to the user to initiate the itinerary corresponding amount of charge, further comprises: in response to the database to increase the new transaction between the outbound transaction and the inbound transaction, to the user to initiate the itinerary corresponding amount of charge; in response to the refund success, according to the time of the new transaction, the itinerary is divided into several new itinerary; re-calculate the cost of each segment of the itinerary, and in response to the current charge mode is real-time charge, to the user to initiate each segment of the itinerary corresponding amount of charge.

[0008] In some embodiments, the response to the user in the inbound terminal generates inbound transactions, the inbound transaction is marked as unmatched, and the marked inbound transaction is saved to the database, comprising: obtaining the inbound transaction through the inbound terminal; in response to the inbound terminal online, the inbound transaction is parsed; the parsed inbound transaction is checked for data duplication; in response to the inbound transaction passing the data duplication check, the inbound transaction is marked as unmatched, and the marked inbound transaction is saved to the database.

[0009] In some embodiments, the response to the user in the outbound terminal generates outbound transactions, in the database to find the last unmatched inbound transaction, to match the inbound transaction to the outbound transaction after the itinerary, further comprises: in response to the database to increase the outbound transaction and the new inbound transaction between the inbound transaction, according to the time of the new outbound transaction and the new inbound transaction, the itinerary is divided into several new itinerary; the calculation of the itinerary cost, and in response to the current charge mode is real-time charge, to the user to initiate the itinerary corresponding amount of charge, including: respectively calculate the cost of each segment of the itinerary after splitting, and in response to the current charge mode is real-time charge, to the user to initiate each segment of the itinerary corresponding amount of charge.

[0010] In some embodiments, the fee deduction mode further comprises delayed deduction; and the method further comprises: in response to the real-time online rate of the inbound terminal and the outbound terminal being less than a preset online rate threshold, setting the fee deduction mode to delayed deduction; or in response to the real-time online rate of the inbound terminal and the outbound terminal being greater than or equal to the preset online rate threshold and the duration being longer than a preset time threshold, setting the fee deduction mode to real-time deduction.

[0011] In some embodiments, the method further comprises: calculating the fare of the trip and determining the current fee deduction mode; in response to the current fee deduction mode being delayed deduction, marking the deduction state of the trip as not initiated; and in response to the fee deduction mode being switched from delayed deduction to real-time deduction, initiating the deduction of the trip with the deduction state of not initiated and switching the deduction state of the trip from not initiated to being paid.

[0012] In some embodiments, the method further comprises: identifying the identity code of the user through the inbound terminal to generate an inbound transaction corresponding to the user; or identifying the identity code of the user through the outbound terminal to generate an outbound transaction corresponding to the user.

[0013] To solve the above technical problems, another technical solution adopted by the present application is to provide a rail transit fare deduction system, comprising terminal devices, a message server and a background system; the terminal devices comprise an inbound terminal for obtaining an inbound transaction of a user and an outbound terminal for obtaining an outbound transaction of the user, and the terminal devices support generating and uploading transaction data corresponding to each terminal device in an online state or an offline state; the message server is configured to support bidirectional communication between the terminal devices and the background system through an MQTT channel, and the terminal devices and the background system perform data transmission in a publishing mode or a subscribing mode through the message server; and the background system and the terminal devices build an asynchronous communication architecture and a double-channel communication mechanism through the MQTT channel to implement the above-mentioned fare deduction method.

[0014] In some embodiments, the message server is an EMQ X server, and the transaction data comprises a device transaction serial number, a request type, a terminal device number, a device sequence, a software version, a firmware version, a request time and transaction-related information.

[0015] The beneficial effects of this application are as follows: Unlike existing technologies, this application discloses a method and system for deducting fares for rail transit. By acquiring and parsing entry transactions generated by users at the entry terminal, entry transactions are marked as unmatched and saved to the database. The unmatched status provides a clear identifier for matching subsequent exit transactions, avoiding trip confusion. Offline entry transactions are temporarily stored locally and re-uploaded and processed according to the same logic after online access is restored, ensuring no data loss in offline scenarios. In response to a user generating an exit transaction at the exit terminal, the database is searched for the previous unmatched entry transaction to match the trip from entry to exit. Through unmatched status tracking, it is ensured that entry and exit transactions correspond one-to-one, avoiding fare anomalies caused by unilateral transactions. The system calculates the trip cost and, in response to the current real-time payment mode, initiates a deduction for the corresponding amount from the user's account. Real-time payment reduces user waiting time, aligns with seamless payment requirements, and lowers user complaints due to delayed payments. Through dynamic mode switching, it automatically switches to delayed payment when the network is unstable, reducing system interactions such as refunds and duplicate charges caused by untimely transaction submissions, lowering resource consumption, and improving user experience. This solves the core contradiction of high error rates in real-time payment and poor user experience in delayed payment in existing technologies, achieving intelligent payment mode switching based on the online status of the terminal device, balancing accuracy, real-time performance, and system stability. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, wherein: Figure 1 This is a flowchart illustrating an embodiment of the rail transit fare deduction method provided in this application; Figure 2 Is it like this? Figure 1 The flowchart of step 100 of the method shown is a schematic diagram of an embodiment. Figure 3 Is it like this? Figure 1 The flowchart of step 200 of the method shown is a schematic diagram of one embodiment; Figure 4 Is it like this? Figure 1 The flowchart of one embodiment of the method shown is illustrated. Figure 5 Is it like this? Figure 1 The flowchart of step 300 of the method shown is a schematic diagram of an embodiment; Figure 6 Is it like this? Figure 1A flowchart illustrating another embodiment of the method shown; Figure 7 This is a schematic diagram of an embodiment of the rail transit fare deduction system provided in this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0018] The terms "first," "second," and "third" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0019] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0020] See Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the rail transit fare deduction method provided in this application. The rail transit fare deduction method includes the following steps: 100: Retrieve and parse inbound transactions generated by users at inbound terminals, mark inbound transactions as unmatched, and save the marked inbound transactions to the database.

[0021] The inbound terminal sends the transaction data generated when the user enters the station to the back-end system through the MQTT channel. The back-end system parses the transaction data and extracts key information such as user identity, transaction time, and device number.

[0022] The transaction data is uploaded either online in real time or after being restored offline.

[0023] The parsed transaction data is validated. If the validation fails, the process ends directly; if the validation passes, proceed to the next step. Inbound transactions that pass validation are marked as "unmatched," indicating that they have not yet been assembled into a complete itinerary with subsequent outbound transactions, and saved to the database, completing the processing.

[0024] The database includes a relational database and a Redis cache.

[0025] Terminal devices used by users entering the station, such as turnstiles, are the core hardware devices in the rail transit system for collecting entry transaction data. As the entry point for users, they support both online and offline working modes: online, they upload transaction data in real time; offline, they temporarily store data and upload it after recovery, ensuring no data loss. Dynamic QR code scanning verifies user identity, ensuring transaction security and preventing forgery or theft of boarding codes.

[0026] Inbound transactions are the transaction data generated when a user enters the station through the inbound terminal. These are divided into online and offline inbound transactions, containing only user identification and transaction time, but not entry status information, which is managed centrally by the backend. Online inbound transactions are uploaded to the backend in real time when the gate is online; offline inbound transactions are temporarily stored when the gate is offline and re-uploaded to the backend after the gate becomes online again. Inbound transactions serve as the initial data for trip matching, providing the foundation for assembling a complete trip for subsequent exit transactions and are the core basis for the billing logic. Support for temporary storage of transactions in offline scenarios resolves data loss issues caused by network instability and improves system fault tolerance.

[0027] The database is a persistent storage system for inbound transaction data, comprising a relational database and a Redis cache, used to store inbound transaction data marked as "unmatched". The database ensures long-term storage of inbound transaction data, preventing data loss due to system failures and supporting subsequent trip matching and historical data retrieval. Combined with the Redis cache, the database enables fast querying of high-frequency data, improving trip matching efficiency for outbound transactions and reducing user waiting time. The "unmatched" status clearly distinguishes between completed trips and trips awaiting matching, providing data support for switching between real-time and delayed billing modes.

[0028] By acquiring and parsing inbound transactions generated by users at the inbound terminal, marking inbound transactions as unmatched, and saving the marked inbound transactions to the database, the system achieves reliable end-to-end processing of inbound transaction data. This ensures real-time performance in online scenarios and solves data integrity issues in offline scenarios, laying the foundation for intelligent billing mode switching driven by gate online rate. Ultimately, it aims to reduce erroneous billing, reduce system interaction overhead, and improve user experience.

[0029] Further, see Figure 2 Step 100 also includes the following steps: 110: Obtain inbound transactions through the inbound terminal.

[0030] When a user enters the station, the inbound terminal generates inbound transaction data and sends it to the backend system via the MQTT channel.

[0031] 120: In response to the online status of the inbound terminal, the inbound transaction is parsed.

[0032] The backend system parses the received inbound transaction data and extracts key information such as the user's unique identifier, transaction time, device number, and anti-counterfeiting information.

[0033] 130: Perform data deduplication verification on the parsed inbound transactions.

[0034] Perform data duplication checks and business anti-duplicate checks on the parsed transaction data. If the checks fail, the process ends directly; if the checks pass, proceed to the next step.

[0035] Data deduplication prevention verification is a mechanism used by the backend system to verify the legality and uniqueness of incoming transaction data, including data duplication verification and business deduplication prevention verification.

[0036] Data duplication verification checks whether the current transaction data already exists in the system. It can be based on the unique identifier of the transaction, such as the device transaction number or user ID, combined with a timestamp, to prevent duplicate uploads caused by network retries or device failures. Business anti-duplicate verification is used to verify the business legality of transaction data, such as verifying whether the anti-counterfeiting information of the ride code is valid and whether the user is in a normal state, to prevent forged transactions or illegal operations.

[0037] By performing duplicate checks, the same inbound transaction is prevented from being processed multiple times, thus preventing duplicate records in the database, ensuring the accuracy of subsequent trip matching, and avoiding abnormal scenarios where one inbound transaction corresponds to multiple outbound transactions.

[0038] 140: In response to inbound transactions passing data deduplication verification, mark the inbound transaction as unmatched and save the marked inbound transaction to the database.

[0039] The inbound transaction that passes the verification is marked as "unmatched", indicating that it has not yet been assembled into a complete journey with the outbound transaction, and then saved to the database to complete the processing.

[0040] By filtering out forged or tampered transaction data through business anti-duplicate verification, malicious users are prevented from stealing others' ride codes or forging transactions, thus ensuring payment security.

[0041] Transactions that fail verification are terminated immediately to prevent invalid data from entering subsequent storage and processing stages, reducing database storage pressure and redundant calculations in business logic. This ensures that unmatched inbound transactions are genuine and valid, providing a reliable data foundation for trip assembly and billing logic under subsequent real-time / delayed billing modes, and reducing erroneous or missed billing due to data anomalies.

[0042] 200: In response to a user generating an outbound transaction at the outbound terminal, the system searches the database for the previous unmatched inbound transaction to match it into a journey from the inbound transaction to the outbound transaction.

[0043] When a user exits through the exit terminal, an outbound transaction is generated. After receiving the transaction data, the backend system initiates the trip matching process. The backend system parses the outbound transaction data, such as extracting the user ID, transaction time, and device number, and performs data duplication checks and business anti-duplicate checks. The current outbound transaction is assembled with the inbound transaction into a complete trip, the trip status is marked as "pending deduction," and deduction is initiated according to the current deduction mode.

[0044] Specifically, if the previous transaction was "matched for entry and already charged," the system first initiates a refund for the original trip, then rematches the current exit transaction with the entry transaction to generate a new trip and charge it. If the previous transaction was an exit transaction, it is not processed temporarily, waiting for the user to supplement the entry information or for the offline entry transaction to be re-uploaded before matching. If some turnstiles are offline, resulting in an incomplete trip, the system automatically splits the trip into normal segments and reissues a charging request after the offline turnstiles are restored.

[0045] Exit terminals, such as exit gates, are the devices used by users when exiting the station. They are the core hardware for collecting exit transaction data and support both online and offline working modes. When online, exit transaction data is uploaded to the backend system in real time via the MQTT channel; when offline, data is temporarily stored and re-uploaded after the network is restored to ensure no data loss. User identity is verified by scanning a dynamic QR code to prevent forged boarding codes or unauthorized exits, ensuring transaction security.

[0046] Outbound transactions are transaction data generated when a user exits the station through an outbound terminal. They are divided into online and offline outbound transactions, and only include user identification and transaction time, without outbound status information. As the "end point" of the journey, outbound transactions are matched with inbound transactions to form a complete journey and are the direct basis for the backend system to calculate fees and initiate deductions.

[0047] Outbound transactions support offline transaction storage and retransmission, resolving data gaps caused by network fluctuations or equipment failures and ensuring the continuity of user travel data. The system dynamically switches between real-time and delayed billing modes based on the gate's online rate. When the online rate meets the target, travel is matched and billed immediately; when the online rate is insufficient, billing is delayed, balancing real-time performance and accuracy.

[0048] Through the outbound transaction itinerary matching process and the collaboration of key components, the system achieves dynamic assembly and accurate billing of itineraries in the stateless single-code mode. This avoids the high error rate problem of traditional real-time billing in offline scenarios and solves the user experience pain point of delayed billing. At the same time, through mechanisms such as anti-duplicate verification and offline retransmission, the system ensures the uniqueness, security and integrity of transaction data.

[0049] Optionally, see Figure 3 The following steps are included before step 200: 201: Obtain outbound transactions through the outbound terminal.

[0050] 202: In response to the outbound terminal being online, analyze the outbound transaction.

[0051] 203: Perform data deduplication verification on the parsed outbound transactions.

[0052] 204: In response to outbound transactions passing data deduplication verification, the outbound transaction is marked as unmatched, and the marked outbound transaction is saved to the database.

[0053] For the processing of outbound transactions, please refer to steps 110 to 140 above for the processing of inbound transactions; it will not be repeated here.

[0054] Further, see Figure 4 Step 200 also includes the following steps: 210: In response to the addition of new outbound and new inbound transactions between outbound and inbound transactions in the database, the trip is split into several new trip segments based on the time of the new outbound and new inbound transactions.

[0055] Some turnstiles were offline, resulting in incomplete user travel records. Once the offline turnstiles were brought back online, historical inbound / outbound transaction data was uploaded to the database, triggering a travel segmentation process. The system uses a scheduled task to scan the database and identify newly uploaded inbound and outbound transactions.

[0056] The system generates independent trip records for the split sub-trips, updates the trip status in the database from "not split" to "split", and reissues a deduction request according to the current deduction mode, pushing the deduction result to the user.

[0057] New entry transactions are entry transaction data that is uploaded to the backend system after the turnstile is restored to online status. The data includes user identification, actual entry time, station number, etc. Since the data is temporarily stored locally when the turnstile is offline, it is uploaded to the database via MQTT channel after restoration.

[0058] The newly added outbound transaction is the outbound transaction data that is re-transmitted to the back-end system after the gate is restored to online status. It includes information such as user identity, actual outbound time, and station number, and is also re-transmitted to the database via the MQTT channel.

[0059] The trip splitting process achieves self-correction of abnormal trips through dynamic re-uploading of new transactions and timeline matching, ensuring that the trip record is consistent with the actual travel behavior and avoiding the cost calculation deviation caused by "long trips across stations". After splitting, the fee is deducted according to the actual interval, reducing disputes caused by "overcharging" and improving users' trust in the payment system. It supports offline transaction re-uploading and dynamic trip reorganization, reducing the impact of gate offline on the overall service and ensuring the stability of the system in complex network environments.

[0060] 300: Calculates the cost of the trip and, in response to the current billing mode being real-time billing, initiates a deduction of the corresponding amount from the user's bill for the trip.

[0061] After a user completes their exit process, the backend system assembles the entry and exit transactions into a complete itinerary based on the user's identity and time sequence, including information such as entry time, exit time, entry station, and exit station. The system automatically calculates the trip fare based on the station range and preset fare rules, and this fare information is linked to the trip record.

[0062] In real-time billing mode, once the trip is assembled, the system immediately calls the payment interface to initiate a billing request and updates the trip billing status to "Payment in progress".

[0063] Real-time deduction refers to a deduction mode that initiates the deduction of fees immediately after the travel assembly is completed when the online rate of the gate meets the preset conditions.

[0064] Users receive a billing notification immediately upon exiting the station, with real-time visibility of their trip and billing results. This avoids the perception of being charged after travel, which can be problematic due to delayed billing, and reduces user uncertainty about fees. In scenarios with high gate online rates and real-time transaction data, real-time billing avoids trip backlogs caused by delays, reduces system batch processing pressure, and improves transaction processing efficiency. Real-time billing relies on complete online transaction data, reducing the need for large cross-station trip splitting due to offline issues, decreasing the frequency of trip reorganization and refund operations, and reducing system interaction overhead. Combined with an automatic switching mode based on gate online rates, real-time billing is enabled when the network is stable, and delayed billing is switched to when the network fluctuates, balancing efficiency and fault tolerance.

[0065] Further, see Figure 5 Following step 210, the following steps are also included: 310: Calculate the cost of each segment of the trip separately, and in response to the current billing mode being real-time billing, initiate the deduction of the corresponding amount for each segment of the trip to the user.

[0066] When some turnstiles are offline, user trips are temporarily stored as large cross-station trips. When the offline turnstiles are brought back online, new inbound and outbound transactions are uploaded to the database. The system detects new transactions through scheduled tasks and triggers trip splitting.

[0067] The system splits the original long trip into multiple consecutive sub-trips based on the timestamp of the new transaction. For each sub-trip, the system independently calculates the cost based on the actual station intervals, calls preset fare rules, binds the calculated cost to the corresponding sub-trip, and stores it in the database.

[0068] The system checks the current billing mode through a scheduled task that runs every minute. For each split sub-trip, the system immediately calls the payment interface to initiate a billing request and updates the billing status of the sub-trip to "Payment in progress".

[0069] For example, in a journey from station A to station B, and then from station C to station D, if the turnstiles at stations B and C are offline, the system will temporarily generate a journey from entering at station A to exiting at station D. At this time, the journey status is "not split and not charged".

[0070] When the offline turnstiles B and C are brought back online, the newly added inbound transaction at station C and the newly added outbound transaction at station B are uploaded to the database. The system detects the new transaction through a scheduled task and triggers trip splitting, splitting the original trip from station A inbound to station D outbound into the first trip from station A inbound to station B outbound and the second trip from station C inbound to station D outbound.

[0071] The system calculates the cost independently for each sub-trip based on the actual station intervals, calling preset fare rules to charge by distance, number of stations, or segment. For example, the fare from station A to station B is 3 yuan, and the fare from station C to station D is 4 yuan. The original total fare from station A to station D was 8 yuan; after splitting, the fare from station A to station B plus the fare from station C to station D is 7 yuan, correcting for fare errors.

[0072] By splitting large cross-station trips into actual sub-trips and calculating fares based on the actual station intervals, overcharging due to offline operations is avoided, reducing user complaint rates. Real-time deductions are only performed when the gate online rate meets the target, ensuring the completeness and real-time updates of the sub-trip transaction data, preventing deduction failures due to data gaps, and improving the deduction success rate. Sub-trip deduction results are pushed instantly, allowing users to clearly view the fare details for each trip, reducing uncertainty and anxiety about large charges, and improving service transparency.

[0073] Automatically splitting trips and deducting fees independently reduces manual intervention and customer service workload; it also avoids redundant operations such as deducting the full amount first and then splitting and refunding, reducing system interaction overhead. It supports dynamic trip reassessment after offline transaction retransmission, ensuring trip data integrity even if some turnstiles are temporarily offline, guaranteeing the normal execution of the deduction logic and improving the stability of the rail transit payment system.

[0074] Furthermore, the billing mode includes real-time billing and delayed billing, and step 300 also includes the following steps: 320: Calculate the cost of the trip and determine the current billing mode.

[0075] After a user completes their exit transaction, the system assembles the entry and exit transactions into a complete trip. Regardless of the current fare calculation method, the system first performs fare calculation. Based on the actual station range of the trip, the system calls preset fare rules to calculate the fare, and the fare information is bound to the trip and stored in the database.

[0076] 330: If the current billing mode is delayed billing, then the billing status of the trip is marked as not initiated.

[0077] The system checks the current billing mode through a scheduled task executed every minute. After the trip cost is calculated, the system marks the trip billing status as not initiated and stores it in the database, and does not execute the billing for the time being.

[0078] 340: In response to the change of the billing mode from delayed billing to real-time billing, initiate the billing for the user's trip that is in the "not initiated" status, and change the billing status of the trip from "not initiated" to "paying".

[0079] If a scheduled task detects that the gate is online for a period of time or longer than the threshold, or if the gate is manually switched to forced real-time deduction, the deduction mode will switch from delayed to real-time.

[0080] Once the delayed payment check scheduled task detects that the current mode has switched to real-time, it immediately queries the database for all trips with a payment status of "not initiated". The system then initiates payment requests in batches for the retrieved trips, updates the payment status to "paying", and pushes the result to the user upon successful payment; otherwise, it triggers a retry mechanism.

[0081] When the gate is offline and the travel record is incomplete, delayed deduction can prevent the system from initiating deduction based on the wrong travel. After the offline gate is restored and the transaction is retransmitted, the travel is split into normal intervals and then deducted, reducing the probability of incorrect deduction.

[0082] Optionally, see Figure 6 After step 300, the following steps are also included: 400: In response to a new transaction added between outbound and inbound transactions in the database, a refund is initiated to the user for the corresponding amount of the trip.

[0083] Once the offline turnstiles are restored to online status, the newly added transactions are written to the database. The system detects through scheduled tasks that these transactions conflict with the original stored cross-site trips in terms of time or site. The system automatically identifies the original trip as an erroneous trip, immediately calls the payment interface to initiate a full refund of the original trip fee to the user, and marks the original trip status as "refunded".

[0084] 500: In response to a successful refund, the trip is split into several new trip segments based on the time of the new transaction.

[0085] After a successful refund, the system splits the original trip based on the timestamp of the new transaction, generating multiple new trips that match the actual travel segments. The information of the new trips, including the entry time, exit time, station, and user ID for each segment, is written into the database, and the status is marked as "no charge".

[0086] 600: Recalculate the cost of each segment of the trip and, in response to the current billing mode being real-time billing, initiate a separate deduction for the user for each segment of the trip.

[0087] The system calls the preset fare rules to calculate the cost independently for each new trip based on the actual station intervals.

[0088] The current billing mode is checked via a scheduled task. If the gate's online rate is greater than or equal to the threshold and remains so for a specified period, or if it is manually set to force real-time billing, the real-time billing process begins. A billing request is immediately initiated for all new trips that are "not yet billed," updating the billing status to "Payment in Progress." Upon successful completion, billing details are pushed to the user.

[0089] By triggering refunds through new transactions, the system corrects overcharging issues for incorrect trips, ensuring users only pay for the actual travel segment and reducing complaints about overcharging. It also supports automatic trip splitting after offline transaction retransmission, correcting abnormal trips without manual intervention, resolving trip gaps caused by offline turnstiles, and ensuring the stable operation of the rail transit network in complex network environments.

[0090] The billing model also includes delayed billing.

[0091] Optionally, the billing mode can be manually set to the highest priority. If manually set to "0", delayed billing will be enabled regardless of the online rate; if manually set to "1", real-time billing will be enabled; if manually set to "2", the automatic rule will be used to switch.

[0092] Optionally, the fare deduction method for this rail transit system also includes the following steps: If the combined real-time online rate of both inbound and outbound terminals is less than a preset online rate threshold, the billing mode will be set to delayed billing. Alternatively, if the combined real-time online rate of both inbound and outbound terminals is greater than or equal to a preset online rate threshold and the duration exceeds a preset time threshold, the billing mode will be set to real-time billing.

[0093] The system uses a scheduled task executed every minute to statistically analyze the online status of all turnstiles in real time: Online rate = (Number of currently online turnstiles / Total number of turnstiles) × 100%. The calculation result serves as the core basis for switching the billing mode.

[0094] When the gate online rate is greater than or equal to the preset threshold and continues for a specified period of time, the deduction mode is switched to real-time deduction; when the gate online rate is less than the threshold, the deduction mode is switched to delayed deduction.

[0095] The system will switch to real-time billing mode only after the "gate online rate ≥ preset threshold" status has been maintained for a specified time. This ensures that all transactions generated during the offline period are uploaded and avoids situations where large trips require refunds to be split into smaller trips.

[0096] For example, if the gate's online rate is ≥90% and continues for a specified time of 20 minutes, that is, the online rate from the 20 minutes before the check to the present is ≥ the threshold, the deduction mode will be switched to real-time deduction.

[0097] Delayed deduction is a mode in which, when the online rate of the gate is lower than a preset threshold, the system does not immediately deduct fees after the travel assembly is completed, but automatically initiates the deduction once the online rate recovers.

[0098] When a turnstile is offline, resulting in incomplete trip records, delayed deduction prevents the system from initiating charges based on incorrect trips. The trip is split into normal segments after the offline turnstile is restored and the transaction is re-transmitted, reducing the probability of erroneous charges. Users will not receive notifications of excessive charges due to turnstile offline; instead, charges are deducted based on the actual segment after the trip is split, reducing complaints arising from fee disputes and avoiding the cumbersome process of charging first and then refunding. Manual forced activation is supported, combined with an automatic switching mechanism, to meet operational needs in different scenarios.

[0099] Optionally, the fare deduction method further includes: identifying the user's identification code through the entry terminal to generate a corresponding entry transaction for the user; or identifying the user's identification code through the exit terminal to generate a corresponding exit transaction for the user.

[0100] Users present a dynamic QR code at the scanning area of ​​the entry terminal. The terminal device scans and parses the QR code information using its camera. The terminal device extracts the user's unique identifier and anti-counterfeiting information from the QR code, verifies the validity of the anti-counterfeiting information, and prevents forgery or tampering. After successful verification, the terminal device generates entry transaction data, including the user's unique identifier, entry time, entry terminal number, station information, etc., and also generates a device transaction serial number.

[0101] Users present a dynamic QR code at the exit terminal's scanning area. The terminal scans and parses the QR code information, following the same process as when entering the station. The terminal verifies the validity of the QR code's anti-counterfeiting information. Upon successful verification, it generates exit transaction data, including the user's unique identifier, exit time, exit terminal number, station information, and device transaction serial number.

[0102] A user's identification code is a unique identifier carried within a dynamic single-code QR code for public transportation. It contains a unique user identifier and is used by the backend system to link the user's account and transaction records. The user's identification code only contains identity verification and anti-counterfeiting information; it does not include entry / exit status information. The user's entry / exit status is managed centrally by the backend system.

[0103] See Figure 7 , Figure 7 This is a schematic diagram of an embodiment of the rail transit fare deduction system provided in this application. The rail transit fare deduction system includes a terminal device 10, a message server 20, and a back-end system 30.

[0104] Terminal device 10 includes an inbound terminal 11 for acquiring user inbound transactions and an outbound terminal 12 for acquiring user outbound transactions. Terminal device 10 supports generating and uploading transaction data corresponding to each terminal device 10 in online or offline states.

[0105] It includes an inbound terminal 11 for acquiring user inbound transactions and an outbound terminal 12 for acquiring user outbound transactions, supporting both online and offline working modes. When a user scans an identification code, the terminal device 10 generates inbound / outbound transaction data containing the user's unique identifier, transaction time, site number, and device number, and performs anti-counterfeiting information verification.

[0106] When online, terminal device 10 uploads transaction data to backend system 30 in real time via MQTT channel; when offline, terminal device 10 temporarily stores transaction data in local storage and re-uploads it to backend system 30 after the network is restored.

[0107] Terminal device 10 sends heartbeat information to the backend system 30 to indicate online status (normal network communication) or offline status (abnormal network communication).

[0108] The message server 20 is configured to support bidirectional communication between the terminal device 10 and the backend system 30 via the MQTT channel. The terminal device 10 and the backend system 30 transmit data through the message server 20 in publish or subscribe mode.

[0109] Message server 20 is a message middleware based on the MQTT protocol, serving as the communication hub between terminal device 10 and backend system 30. Message server 20 establishes an MQTT channel between terminal device 10 and backend system 30, enabling bidirectional interaction for uploading transaction data and issuing instructions.

[0110] Terminal device 10 subscribes to a dedicated topic, such as / device / terminal number, and receives response instructions from the backend system 30; the backend system 30 subscribes to a global topic, such as / afc / +, where "+" is a wildcard, and receives transaction data uploaded by all terminal devices 10.

[0111] The message server 20 is used to ensure the real-time transmission and confirmation of transaction data and instructions, and supports offline message storage and retransmission.

[0112] The backend system 30 and the terminal device 10 establish an asynchronous communication architecture and a dual-channel communication mechanism through the MQTT channel to realize the fare deduction method described above.

[0113] The back-end system 30 is the core system for processing transaction data, trip matching, fee control, and trip reorganization. It adopts an asynchronous architecture combined with a dual-channel communication mechanism.

[0114] The backend system 30 parses the inbound / outbound transaction data uploaded by the terminal, performs data duplication verification and business anti-duplicate verification; and marks the transactions that pass the verification as "unmatched" and stores them in the database.

[0115] When the terminal is online, the backend system 30 matches inbound and outbound transactions in real time, assembles complete trips and marks the deduction status; when the terminal is offline, it temporarily stores large cross-station trips, and splits and reassembles them into normal trips after the offline terminal is restored.

[0116] The backend system stores transaction data, trip information, and deduction status, supporting efficient querying and status updates; it supports forced real-time deduction, forced delayed deduction, or disabling manual settings; it calculates the gate online rate through a scheduled task executed every minute, and switches to real-time deduction when the online rate is greater than or equal to a preset threshold and continues for a specified time, otherwise it switches to delayed deduction.

[0117] The delayed deduction of the backend system 30 is achieved by checking transactions that have not been deducted through a scheduled task, and initiating deductions in batches after switching to real-time mode; after the offline terminal is restored, the cross-site large process is split into normal sub-processes, and deduction requests are resent and results are pushed.

[0118] Terminal device 10 collects transaction data and uploads it to message server 20 via MQTT channel. Backend system 30 subscribes to message server 20 topics to obtain data, processes it, and performs trip matching, deduction control, and status storage. Ultimately, it realizes dynamic switching between online real-time deduction and offline delayed deduction to ensure transaction accuracy and user experience.

[0119] Optionally, message server 20 is an EMQ X server.

[0120] EMQ X is a message server 20 based on the MQTT (Message Queuing Telemetry Transport) protocol. It supports bidirectional communication between terminal device 10 and backend system 30, and features low code and low bandwidth consumption. It is suitable for remote device message transmission in rail transit scenarios.

[0121] Specifically, the transaction data includes the device transaction serial number, request type, terminal device ID, device sequence, software version, firmware version, request time, and transaction-related information.

[0122] The transaction data covers transaction uniqueness, device legality, user identity, time and site information, providing complete data support for the back-end system's trip matching, billing mode control and anomaly handling, ensuring that transactions are traceable, verifiable and reconfigurable.

[0123] Unlike existing technologies, this application uses a stateless single-code user identification code, unifying the entry and exit status of dynamic QR codes under the management of the backend system. Dynamic anti-counterfeiting information prevents forged boarding codes, and data deduplication verification avoids duplicate uploads and illegal transactions, ensuring the legality and uniqueness of transaction data and reducing the risk of ticket fraud. Dynamic switching driven by the gate's online rate enables real-time deduction when the online rate meets the target and switches to delayed deduction when the online rate is insufficient. Combined with trip reorganization logic, it automatically corrects abnormal trips caused by offline activity, ensuring that the deducted amount matches the actual travel distance and reducing user complaints. In real-time deduction mode, users receive immediate deduction notifications; in delayed mode, the trip is split and deducted according to the actual distance. Combined with deduction result push notifications, this improves the user's perception of the payment process transparency and reduces the cumbersome experience of deducting first and then refunding. The rail transit fare deduction system of this application also achieves bidirectional reliable communication between the terminal and the backend through an asynchronous architecture combined with MQTT / EMQ X, supporting online real-time transmission and offline retransmission. Combined with an offline transaction processing mechanism, it ensures that transaction data is not lost under extreme network conditions, improving system fault tolerance.

[0124] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for deducting fares for rail transit, characterized in that, include: Acquire and parse inbound transactions generated by users at inbound terminals, mark the inbound transactions as unmatched, and save the marked inbound transactions to the database; In response to the user generating an outbound transaction at the outbound terminal, the system searches the database for the previous unmatched inbound transaction to match the inbound transaction with the outbound transaction. Calculate the cost of the trip, and in response to the current billing mode being real-time billing, initiate a deduction of the corresponding amount for the trip to the user.

2. The fare deduction method according to claim 1, characterized in that, After responding to the user generating an outbound transaction at the outbound terminal, searching the database for the previous unmatched inbound transaction to match it into a journey from the inbound transaction to the outbound transaction, the method further includes: In response to the addition of new outbound and new inbound transactions between the outbound and inbound transactions in the database, the trip is split into several new trip segments based on the time of the new outbound and new inbound transactions; The calculation of the trip cost, and in response to the current billing mode being real-time billing, initiating a deduction of the corresponding amount for the trip to the user, includes: The cost of each segment of the trip is calculated separately, and in response to the current billing mode being real-time billing, the corresponding amount of each segment of the trip is deducted from the user.

3. The fare deduction method according to claim 1, characterized in that, After initiating the deduction of the corresponding amount for the trip to the user, the process also includes: In response to the addition of a new transaction between the outbound transaction and the inbound transaction in the database, a refund for the corresponding amount of the trip is initiated to the user; In response to a successful refund, the trip is split into several new trip segments based on the time of the newly added transaction; The cost of each segment of the trip is recalculated, and in response to the current billing mode being real-time billing, the corresponding amount for each segment of the trip is deducted from the user.

4. The fare deduction method according to claim 1, characterized in that, The step of acquiring and parsing inbound transactions generated by users at inbound terminals, marking the inbound transactions as unmatched, and saving the marked inbound transactions to the database includes: The inbound transaction is obtained through the inbound terminal; In response to the inbound terminal being online, the inbound transaction is parsed; Perform data deduplication verification on the parsed inbound transactions; In response to the inbound transaction passing the data deduplication check, the inbound transaction is marked as unmatched, and the marked inbound transaction is saved to the database.

5. The fare deduction method according to claim 1, characterized in that, The response prior to the user generating an outbound transaction at the outbound terminal further includes: The outbound transaction is obtained through the outbound terminal; In response to the outbound terminal being online, the outbound transaction is parsed; Perform data deduplication verification on the parsed outbound transactions; In response to the outbound transaction passing the data deduplication check, the outbound transaction is marked as unmatched, and the marked outbound transaction is saved to the database.

6. The fare deduction method according to claim 1, characterized in that, The billing mode also includes delayed billing; The fare deduction method for rail transit also includes: In response to the fact that the combined real-time online rate of the inbound terminal and the outbound terminal is less than a preset online rate threshold, the billing mode is set to delayed billing. Alternatively, in response to the fact that the real-time online rate of the inbound terminal and the outbound terminal is greater than or equal to a preset online rate threshold and the duration exceeds a preset time threshold, the billing mode is set to real-time billing.

7. The fare deduction method according to claim 6, characterized in that, The step of calculating the cost of the trip and, in response to the current billing mode being real-time billing, initiating a deduction of the corresponding amount for the trip to the user, further includes: Calculate the cost of the trip and determine the current billing method; If the current billing mode is delayed billing, then the billing status of the trip is marked as not initiated; In response to the billing mode switching from delayed billing to real-time billing, the system initiates a billing for the trip whose billing status is "not initiated" to the user, and switches the billing status of the trip from "not initiated" to "paying".

8. The fare deduction method according to claim 1, characterized in that, The fare deduction method also includes: The user's identification code is identified by the inbound terminal to generate an inbound transaction corresponding to the user; Alternatively, the user's identification code can be identified through the outbound terminal to generate an outbound transaction corresponding to the user.

9. A fare deduction system for rail transit, characterized in that, This includes terminal devices, message servers, and backend systems; The terminal device includes an inbound terminal for acquiring user inbound transactions and an outbound terminal for acquiring user outbound transactions. The terminal device supports generating and uploading transaction data corresponding to each terminal device in online or offline states. The message server is configured to support bidirectional MQTT channel communication between the terminal device and the backend system, and the terminal device and the backend system transmit data through the message server in publish or subscribe mode. The backend system and the terminal device establish an asynchronous communication architecture and a dual-channel communication mechanism through the MQTT channel to implement the fare deduction method as described in any one of claims 1-8.

10. The fare deduction system according to claim 9, characterized in that, The message server is an EMQ X server; The transaction data includes the device transaction serial number, request type, terminal device number, device sequence, software version, firmware version, request time, and transaction-related information.

Images