Recharge processing method, device and equipment of traffic card and storage medium

Abstract

Embodiments of the present application provide a traffic card recharging processing method, device and equipment and a storage medium, belonging to the technical field of data processing. The traffic card recharging processing method comprises: obtaining a consumption record generated after a payment operation initiated by a vehicle-mounted machine to a target traffic card account, and determining balance information of the target traffic card account; triggering an automatic recharging operation when it is detected that the balance information meets a preset condition, and storing a recharging task message in a delay queue; taking the recharging task message from the delay queue according to a preset delay time length and executing the automatic recharging operation to increase a preset amount of resources to the target traffic card account; after executing the automatic recharging operation, writing a recharging record in a transaction record of the target traffic card account, and setting a value of a recharging type identification field corresponding to the target traffic card account to a first state value. The embodiments of the present application can accurately implement payment processing on the condition that the automatic recharging of the traffic card is completed after consumption.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, specifically to a method, apparatus, device, and storage medium for recharging a transportation card. Background Technology

[0002] In Near Field Communication (NFC) mobile payment scenarios for transit cards, the in-vehicle terminal can use NFC communication to read the transit card account in the terminal device (such as a mobile phone) to complete the transaction. When the account balance is insufficient, the backend system will trigger automatic top-up, adding a preset amount of funds to the transit card account, thus improving travel convenience.

[0003] However, in the recharge processing schemes adopted by related technologies, for scenarios where mobile phone NFC automatic recharge is executed immediately after consumption, since the automatic recharge operation and card swiping interaction occur within the same time window, if the terminal device is not moved away from the vehicle's sensing area in time and the communication link is not disconnected before the recharge is completed, the vehicle's terminal may initiate a payment request again, resulting in duplicate deductions and easily causing payment conflicts. Therefore, how to provide a transportation card recharge processing method that can accurately process payments after automatic recharge of the transportation card following consumption, preventing payment conflicts caused by repeated swiping by the vehicle's terminal, has become an urgent technical problem to be solved. Summary of the Invention

[0004] The main objective of this application is to provide a method, apparatus, device, and storage medium for recharging a transportation card, which can accurately process payments after automatic recharging of the transportation card has been completed, preventing payment conflicts caused by re-swiping the card reader.

[0005] To achieve the above objectives, a first aspect of this application proposes a method for recharging a transportation card, the method comprising: Obtain the consumption record generated after the first payment request initiated by the target transportation card account to the vehicle-mounted terminal. The balance information of the target transportation card account is determined based on the consumption record, and an automatic recharge operation is triggered when the balance information meets the preset conditions. When the automatic recharge operation is triggered, a recharge task message is generated and stored in a delay queue. The recharge task message contains the identification information of the target transportation card account. The recharge task message is retrieved from the delay queue according to the preset delay time and the automatic recharge operation is executed to add a preset amount of resources to the target transportation card account; After the automatic recharge operation is performed, a recharge record is written into the transaction record of the target transportation card account, and the value of the recharge type identifier field corresponding to the target transportation card account is set to a first status value. The first status value is used to indicate that the target transportation card account has completed automatic recharge.

[0006] To achieve the above objectives, a second aspect of this application proposes a method for recharging a transportation card, applied to a security chip in a terminal device, the method comprising: In response to the completion of the automatic recharge operation, the recharge record is obtained, which includes the amount of recharged resources; The value of the recharge type identifier field of the target transportation card account in the terminal device is set to a first status value, which is used to indicate that the target transportation card account has completed automatic recharge. The transaction records of the target transportation card account, including the recharge records, are stored in the security chip.

[0007] To achieve the above objectives, a third aspect of this application proposes a method for recharging a transportation card, applied to an in-vehicle terminal, the method comprising: When the vehicle-mounted unit reads the transaction record for anti-duplicate verification, it returns the transaction record to the vehicle-mounted unit. Anti-duplicate verification is performed based on the value of the recharge type identifier field of the most recent record in the transaction history.

[0008] To achieve the above objectives, a fourth aspect of this application provides a transportation card recharge processing apparatus, the apparatus comprising: The record acquisition module is used to acquire the consumption record generated after the first payment request initiated by the target transportation card account to the vehicle terminal. The triggering module is used to determine the balance information of the target transportation card account based on the consumption record, and to trigger an automatic recharge operation when the balance information is detected to meet a preset condition; The message generation module is used to generate a recharge task message when the automatic recharge operation is triggered, and store the recharge task message in a delay queue. The recharge task message contains the identification information of the target transportation card account. The recharge module is used to retrieve the recharge task message from the delay queue according to the preset delay time and execute the automatic recharge operation to add a preset amount of resources to the target transportation card account; The first field setting module is used to write a recharge record into the transaction record of the target transportation card account after the automatic recharge operation is performed, and to set the value of the recharge type identifier field corresponding to the target transportation card account to a first status value. The first status value is used to indicate that the target transportation card account has completed automatic recharge.

[0009] In some embodiments, the triggering module specifically includes: The payment scenario type corresponding to the payment operation is determined based on the attribute information of the consumption record; Obtain the communication connection status information corresponding to the target transportation card account; Obtain historical payment operation data corresponding to the target transportation card account, wherein the historical payment operation data includes the duration of the communication connection for each payment operation; The preset delay duration is determined based on at least one of the payment scenario type, the communication connection status information, the communication connection duration, and the default delay duration.

[0010] In some embodiments, the triggering module further includes: Determine a first recommended delay duration corresponding to the payment scenario type, and determine a second recommended delay duration corresponding to the communication connection status information; The maximum duration is determined based on the communication connection duration of each payment operation, and a third recommended delay duration is determined based on the maximum duration and a preset safety margin. The preset delay duration is determined based on at least one of the first recommended delay duration, the second recommended delay duration, the third recommended delay duration, and the default delay duration.

[0011] In some embodiments, the first field setting module specifically includes: If the communication link between the terminal device corresponding to the target transportation card account and the vehicle-mounted unit is not disconnected after the automatic recharge operation is completed, a second payment request initiated by the vehicle-mounted unit will be received. Based on the second payment request, the vehicle-mounted unit sends the transaction records of the target transportation card account to the vehicle-mounted unit, so that when the vehicle-mounted unit detects that the recharge type identifier field of the most recent record in the transaction records is the first status value, it performs anti-duplicate verification based on the consumption records before the most recent record.

[0012] In some embodiments, the first field setting module further includes: Obtain multiple consumption records generated by the vehicle-mounted unit; The multiple consumption records are checked for duplicates according to preset deduplication conditions, which include identical transportation card account identifiers, identical vehicle-mounted device identifiers, identical payment resource amounts, and payment time intervals less than preset time thresholds. When a first consumption record and a second consumption record that meet the preset duplicate detection conditions are detected, the second consumption record is marked as a suspected duplicate record, and the payment resources corresponding to the second consumption record are returned to the corresponding target transportation card account.

[0013] To achieve the above objectives, a fifth aspect of the present application provides an electronic device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the methods described in the first, second, and third aspects.

[0014] To achieve the above objectives, a sixth aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described in the first, second, and third aspects.

[0015] The transportation card recharge processing method, apparatus, device, and storage medium proposed in this application can first obtain the consumption record generated after the target transportation card account completes the payment operation of the first payment request on the vehicle-mounted terminal, and then check whether the balance meets the preset conditions based on the consumption record to trigger an automatic recharge operation. When the recharge is triggered, the recharge is not executed immediately. Instead, a recharge task message is generated and stored in a delay queue. The recharge task message is retrieved and the automatic recharge operation is executed only after waiting for a preset delay time in the delay queue. This mechanism staggers the automatic recharge operation from the card swiping interaction window in terms of time, effectively reducing the probability of duplicate deductions caused by the vehicle-mounted terminal initiating a second payment request while the communication link is still open. After the recharge is completed, a recharge record is further written into the transaction record of the target transportation card account, and the value of the recharge type identifier field is set to the first status value to indicate that the transportation card account has completed automatic recharge, so that the recharge record can be correctly identified in subsequent anti-duplicate verification. Therefore, the embodiments of this application construct a chain-like processing flow of "consumption trigger → delayed execution → flag writing", which can accurately realize payment processing after the automatic recharge of the transportation card is completed, and prevent payment conflicts caused by the re-swiping of the vehicle terminal. Attached Figure Description

[0016] The accompanying drawings are provided to further understand the technical solutions of this disclosure and constitute a part of the specification. They are used together with the embodiments of this disclosure to explain the technical solutions of this disclosure and do not constitute a limitation on the technical solutions of this disclosure.

[0017] Figure 1This is the first flowchart of the transportation card recharge processing method provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the determination of a preset delay duration provided in an embodiment of this application; Figure 3 yes Figure 2 A flowchart of step S204 in the process; Figure 4 This is a schematic diagram illustrating a process of recharging a transportation card on the back-end side of the transportation card company, as described in this application embodiment. Figure 5 This is the second flowchart of the transportation card recharge method provided in the embodiments of this application; Figure 6 This is a schematic diagram of a process on the security chip side of a terminal device according to an embodiment of this application; Figure 7 This is the third flowchart of the transportation card recharge method provided in the embodiments of this application; Figure 8 This is a system architecture diagram of the transportation card recharge processing system provided in the embodiments of this application; Figure 9 This is a specific flowchart of the transportation card recharge method provided in the embodiments of this application; Figure 10 This is a schematic diagram of a transportation card recharge processing device provided in an embodiment of this application; Figure 11 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this disclosure.

[0019] Before providing a further detailed description of the embodiments of this disclosure, the terms and concepts used in these embodiments are explained, and they are subject to the following interpretations: Near Field Communication (NFC): A short-range, high-frequency wireless communication technology that allows contactless point-to-point data transmission between electronic devices, and is widely used in areas such as mobile payments.

[0020] Secure Element (SE chip): A secure component embedded in a mobile phone, used to store transit card applications and sensitive data, providing a secure execution environment and preventing external attacks.

[0021] Onboard unit: A card reader / verification device installed on public transportation vehicles to read passenger transportation card information, complete payment deductions, and prevent duplicate verification.

[0022] Anti-duplicate swipe mechanism: The verification mechanism in the vehicle terminal is used to prevent the same card from being swiped repeatedly in the same vehicle within a short period of time. It is usually implemented by checking the most recent transaction record on the card.

[0023] Delayed queue: A special type of message queue where messages (such as recharge instructions) are not consumed immediately after being enqueued, but are processed by the consumer only after a specified delay time.

[0024] With the rapid development of mobile payment technology, public transportation payment methods based on mobile phone NFC functionality have been widely adopted. Mobile phones can have a built-in eSE (embedded Secure Element) card to function as a transit card. Users simply tap their NFC transit card against the card reader on the vehicle, and the reader can use NFC communication to read the transit card account in the terminal device (such as the mobile phone) and deduct the fare, greatly improving travel convenience. When the account balance is insufficient, the system will automatically top up the transit card account with a preset amount of funds, further enhancing travel convenience.

[0025] However, in the recharge processing solutions adopted by related technologies, there are three situations for scenarios where mobile phone NFC automatic recharge is executed immediately after consumption: (1) There is a conflict between the timing of automatic recharge and the anti-recharge mechanism: The card company's backend initiates the recharge immediately after receiving the consumption record, causing the most recent transaction record in the card to change from "consumption" to "recharge". However, the anti-recharge mechanism of the bus terminal only checks the most recent consumption record in the card to prevent duplicate deduction. The writing of the recharge record makes it impossible for the terminal to normally identify the recharge behavior through the consumption record.

[0026] (2) Risk of duplicate charges due to card swiping delay: Some users are accustomed to leaving their mobile phones in the vehicle's sensor area for a long time after swiping their cards, or the communication time may be extended due to the gate's sensor delay. After the automatic recharge is completed, if the communication link between the mobile phone's NFC chip and the vehicle's sensor has not been disconnected, the vehicle's sensor may initiate a consumption request again, resulting in duplicate charges for the same trip.

[0027] (3) Recharging too early leads to conflict window: Recharging immediately after consumption causes the automatic recharge operation to occur within the card swipe interval, creating conditions for repeated consumption.

[0028] Therefore, how to provide a method for recharging transportation cards that can accurately process payments after automatic recharging of transportation cards and prevent payment conflicts caused by re-swiping of the vehicle's onboard unit has become an urgent technical problem to be solved.

[0029] Based on this, the embodiments of this application propose a method, apparatus, device and storage medium for recharging a transportation card, which can accurately realize payment processing after the automatic recharging of the transportation card is completed, and prevent payment conflicts caused by re-swiping of the vehicle terminal.

[0030] The following describes the recharge method for transportation cards provided in the embodiments of this application.

[0031] Reference Figure 1 In some embodiments, the transportation card recharge method provided in this application is applied to the back-end of the transportation card company, and the specific implementation process includes, but is not limited to, steps S101 to S105: Step S101: Obtain the consumption record generated after the payment operation of the first payment request initiated by the target transportation card account to the vehicle-mounted terminal; Step S102: Determine the balance information of the target transportation card account based on the consumption record, and trigger an automatic recharge operation when the balance information meets the preset conditions. Step S103: When the automatic recharge operation is triggered, a recharge task message is generated and stored in the delay queue. The recharge task message contains the identification information of the target transportation card account. Step S104: Retrieve the recharge task message from the delay queue according to the preset delay time and execute the automatic recharge operation to add a preset amount of resources to the target transportation card account; Step S105: After performing the automatic recharge operation, write the recharge record into the transaction record of the target transportation card account, and set the value of the recharge type identifier field corresponding to the target transportation card account to the first status value. The first status value is used to indicate that the target transportation card account has completed the automatic recharge.

[0032] It should be noted that the back-end of the card company may include a consumption record receiving module, a real-time balance detection module, a delay queue module, a recharge execution module, and a duplicate refund module, and the specific implementation process of these modules will be described in detail in the following embodiments.

[0033] In step S101, the first payment request refers to the initial transaction deduction request initiated by the on-board unit when the user swipes their card for normal transportation. The target transportation card account refers to the transportation card application account stored in the security chip (SE chip) of the terminal device (such as a mobile phone), which includes data such as card number, balance, and transaction records. The on-board unit refers to the card-swiping verification device installed on public transportation vehicles (such as buses and subways), equipped with NFC read / write functionality. The transaction record refers to the structured transaction data generated after the on-board unit completes the transaction deduction, including fields such as card number, transaction amount, transaction time, transaction serial number, and terminal number.

[0034] In step S102, the balance information refers to the current available balance of the target transit card account. The preset condition refers to a pre-set balance threshold condition that triggers automatic top-up, such as triggering a top-up when the balance is below a value 'a'. The automatic top-up operation refers to the operation of adding a preset amount of resources to the target transit card account.

[0035] In some embodiments, before triggering the automatic recharge operation when the balance information meets preset conditions, the method provided in this application embodiment may further include the following steps: The balance information is compared with a preset recharge trigger threshold. When the balance information is less than the recharge trigger threshold, it is determined that the balance information meets the preset conditions.

[0036] The preset recharge trigger threshold refers to a pre-defined minimum balance value that triggers automatic recharge. This embodiment compares the current balance of the target transportation card account with this threshold. If the current balance is less than the threshold, the preset conditions for automatic recharge are met, and the automatic recharge operation is triggered. If the current balance is greater than or equal to the threshold, recharge is not triggered, and the process ends. Thus, by comparing the balance with the threshold, precise triggering of automatic recharge is achieved, ensuring that recharge is only initiated when the balance is insufficient, avoiding unnecessary automatic recharge operations that consume user funds and system resources.

[0037] In step S103, the recharge task message refers to a data structure containing the information required for recharge, including at least the identification information (such as the card number) of the target transportation card account. A delayed queue is a message queue mechanism where messages are not consumed immediately after being enqueued, but are retrieved and processed by the consumer only after a specified delay period.

[0038] In step S104, the preset delay time refers to the pre-set waiting time for the recharge task in the delay queue, and its specific value can be dynamically determined by the intelligent delay mechanism. Executing the automatic recharge operation means deducting a preset amount of resources from the user's linked payment account and writing the corresponding amount to the target transportation card account.

[0039] Reference Figure 2In some embodiments, prior to step S104, the method provided in this application may further include: determining a preset delay duration, and the process of determining the preset delay duration may include, but is not limited to, steps S201 to S204: Step S201: Determine the payment scenario type corresponding to the payment operation based on the attribute information of the consumption record; Step S202: Obtain the communication connection status information corresponding to the target transportation card account; Step S203: Obtain historical payment operation data corresponding to the target transportation card account. The historical payment operation data includes the duration of the communication connection for each payment operation. Step S204: Determine the preset delay duration based on at least one of the payment scenario type, communication connection status information, communication connection duration, and default delay duration.

[0040] In step S201, the attribute information of the consumption record refers to fields such as terminal number and transaction type. The payment scenario type refers to the specific transportation scenario in which the payment occurred, such as a bus scenario or a subway turnstile scenario. The user's behavior after swiping their card differs in different scenarios. For example, in a bus scenario, the vehicle starts after the user swipes their card, and it takes a certain amount of time for the user to leave the sensing area; a longer delay (e.g., 5-8 seconds) is recommended. In a subway turnstile scenario, the user leaves the sensing area immediately after passing through the turnstile; a medium delay (e.g., 3-5 seconds) can be used.

[0041] It should be noted that the payment scenario types include a first scenario type and a second scenario type. The first scenario type corresponds to a first delay duration, and the second scenario type corresponds to a second delay duration, with the first delay duration being longer than the second delay duration. For example, the first scenario type could refer to a bus onboard machine transaction scenario, while the second scenario type could refer to a subway turnstile transaction scenario. The fact that the first delay duration is longer than the second delay duration reflects the different emphases on recharge timeliness and conflict prevention requirements in different scenarios.

[0042] In step S202, the communication connection status information refers to the communication link status information between the NFC chip of the terminal device and the vehicle-mounted unit, used to determine whether the communication link has been disconnected. If the background detects that the SE chip is still in a communication connection state with the vehicle-mounted unit, the recharge delay should be extended until the communication is disconnected before execution.

[0043] In step S203, historical payment operation data refers to a record of the communication connection duration for each payment operation in the history of the target transportation card account. This embodiment of the application can calculate the average and maximum swipe duration by recording the historical swipe duration of each card (the time interval from the start of swiping to the end of communication), which can be used to estimate the communication duration of the current swipe.

[0044] In step S204, this application can dynamically calculate the delay duration by considering the above-mentioned factors. For example, the maximum value is selected from multiple candidate values ​​such as the default delay duration, the scenario-recommended delay duration determined based on the payment scenario type, the predicted value based on historical card swiping duration, and the remaining duration of the communication link as the actual delay duration, to ensure that the automatic recharge operation is executed after the user removes the mobile phone and disconnects the communication link.

[0045] In the above embodiments, this application dynamically determines the delay time by considering multiple factors such as the type of payment scenario, the communication connection status, and historical payment operation data. This optimizes the timing of recharge execution to the maximum extent while ensuring timely completion of the recharge, thus achieving a balance between conflict prevention and user experience.

[0046] Reference Figure 3 In some embodiments, step S204 may specifically include, but is not limited to, steps S301 to S303: Step S301: Determine the first recommended delay duration corresponding to the payment scenario type, and determine the second recommended delay duration corresponding to the communication connection status information; Step S302: Determine the maximum duration based on the communication connection duration of each payment operation, and determine the third recommended delay duration based on the maximum duration and the preset safety margin. Step S303: Determine the preset delay duration based on at least one of the first recommended delay duration, the second recommended delay duration, the third recommended delay duration, and the default delay duration.

[0047] In step S301, this embodiment of the application can query a preset scenario-delay mapping table based on the payment scenario type (bus or subway) to obtain a first recommended delay duration. Simultaneously, based on the current communication link status (disconnected or still connected), if the link is still connected, it is recommended to extend the delay duration to obtain a second recommended delay duration.

[0048] In step S302, the communication connection duration of each payment operation is extracted from the historical payment operation data, the maximum duration is determined, and then a preset safety margin (such as 2-3 seconds) is added to the maximum duration to obtain the third recommended delay duration, so as to ensure that the automatic recharge operation is executed after the user removes the mobile phone.

[0049] In step S303, the maximum value among the multiple candidate values ​​is selected as the actual delay duration. The calculation formula for the intelligent delay can be expressed as: T_delay = max(T_default, T_scene, T_history_card+ΔT, T_comm_remain+ΔT_safe), where T_delay represents the finally determined preset delay duration, T_default represents the default delay duration, T_scene represents the first recommended delay duration based on the scene, T_comm_remain represents the second recommended delay duration, T_history_card represents the third recommended delay duration, ΔT represents the preset safety margin, and ΔT_safe represents the communication safety margin (e.g., 1-2 seconds).

[0050] It should be noted that the delayed queue can be replaced by a scheduled task polling. The card company's backend maintains a table of pending recharge tasks, with each task recording its expected execution time. The backend scheduled task (e.g., scanning once every 1 second) scans this table, and tasks that have reached their execution time are retrieved and executed. Alternatively, the intelligent delay can adopt a simplified scheme with a fixed delay duration, that is, all recharge tasks are uniformly delayed by a fixed duration (e.g., 5 seconds).

[0051] In the above embodiments, by using a maximum value selection strategy based on multi-source information fusion, the delay time is ensured to be sufficient to cover various uncertainties, so that the automatic recharge operation is always executed after the card swiping interaction is completely finished, effectively reducing the probability of duplicate charges.

[0052] In step S105, the recharge record refers to the transaction record that records the details of the automatic recharge operation. The recharge type identifier field is a status field (i.e., the Auto-Recharge Flag, ARF) stored in the SE chip transaction record data structure, used to identify the type of transaction record. This field can contain three status values: 0x00 indicates no automatic recharge record (default status), 0x02 indicates automatic recharge in progress, and 0x01 indicates recharge completed. The first status value is 0x01. That is, after the SE chip completes a consumption deduction, if the balance is lower than the threshold and the background triggers an automatic recharge instruction, the SE chip, after completing the recharge amount writing, marks the transaction type corresponding to the current recharge record as automatic recharge and sets the ARF field to 0x01. 0x00 can be used as the default field. Each time a consumption occurs, the recharge type identifier field can be initially set to 0x02, and after the recharge is completed, the field can be set to 0x01. This first status value is used to guide the bus terminal to prevent duplicate swipes during duplicate detection.

[0053] It should be noted that the automatic recharge status flag is not limited to being stored in the SE chip; it can also be stored in the card account data in the card company's backend. During verification, the vehicle-mounted unit checks the backend in real time to see if the card's most recent transaction was an automatic recharge record.

[0054] In the above embodiments, the automatic recharge operation is delayed until after the card swipe interaction is completed by using a delayed queue. This time-wise avoids the automatic recharge operation from a potential second consumption request initiated by the vehicle-mounted unit, reducing the probability of duplicate charges from the source. Simultaneously, by writing an ARF tag into the recharge record, subsequent anti-duplicate verification can distinguish between the recharge record and the consumption record, providing a data foundation for the vehicle-mounted unit's correct judgment.

[0055] For example, please refer to Figure 4 , Figure 4 This is a schematic diagram illustrating a process for recharging a transit card on the back-end side of a transit card company, as described in this application embodiment. The process for recharging a transit card on the back-end side of the transit card company may include the following steps: Step 1: Receiving Transaction Records. The transaction record receiving module on the card company's backend can obtain transaction records uploaded by the vehicle-mounted device. These records include at least the card number, transaction amount, transaction serial number, and transaction time. These transaction records form the data foundation for triggering subsequent real-time balance monitoring and automatic top-up processes. After receiving the transaction records, the backend persistently stores them in the database and simultaneously triggers the real-time balance monitoring module.

[0056] Step Two: Real-time Balance Detection and Recharge Determination. The real-time balance detection module can read the current balance of the target transportation card account based on the card number information in the received transaction records and compare it with a preset automatic recharge threshold. If the current balance is greater than or equal to the threshold, it indicates sufficient balance, the process ends, and no recharge is triggered; if the current balance is lower than the threshold, it is determined that an automatic recharge needs to be initiated, and the process enters the intelligent delayed calculation stage.

[0057] Step 3: Intelligent Delay Calculation. The backend can dynamically calculate the delay duration for automatic top-up operations based on multi-dimensional information. The calculation process comprehensively considers four factors: transaction scenario identification, i.e., determining the specific scenario of the payment based on the terminal number in the consumption record (5-8 seconds for buses, 3-5 seconds for subway turnstiles, 1-2 seconds for convenience stores); communication status awareness, i.e., detecting whether the NFC communication link is disconnected, extending the delay if the link is still connected; historical data learning, i.e., calculating a recommended delay duration based on the historical card swipe duration of the transportation card account; and default delay duration, i.e., using the system's default delay duration (e.g., 5 seconds, covering over 95% of normal card swipe scenarios) when dynamic information is unavailable. Furthermore, the process of calculating the preset delay duration based on multiple factors has been detailed in the above embodiments.

[0058] Step 4: Generate a recharge task message and place it in a delay queue, waiting for the specified delay time. The backend can generate a recharge task message based on the target transit card account's card number, recharge amount, and associated transaction serial number, and store this message in the delay queue. The message waits in the delay queue for the preset delay time calculated in Step 3. The delay queue mechanism ensures that the recharge task will not be executed immediately before the card swipe interaction is completed, thus avoiding the time window between the automatic recharge operation and any potential second payment request initiated by the vehicle's onboard unit.

[0059] Step 5: Retrieve the recharge task message and execute the deduction. After the delay period, the recharge execution module retrieves the recharge task message from the delay queue and calls the user's linked payment channel to complete the pre-set deduction. This step changes the recharge task from the "pending execution" state to the "in execution" state, actually deducting the corresponding funds from the user's payment account.

[0060] Step Six: Issue a recharge command and set the ARF flag. After successful automatic deduction, the backend issues a recharge command to the terminal device's security chip (SE chip), completing the recharge amount writing, adding the recharge record to the target transit card account's transaction history, and setting the Recharge Type Identifier (ARF) field to the first status value (0x01, indicating automatic recharge completed). This flag allows the on-board unit to distinguish between recharge records and consumption records during anti-duplicate verification, preventing recharge records from interfering with the anti-duplicate verification mechanism.

[0061] Step Seven: Top-up Completion and Result Feedback. After the automatic top-up operation is completed, the background system updates the target transit card account's balance information, generates a top-up completion record, and sends the top-up result back to the relevant system modules. At this point, the automatic top-up process is complete, the target transit card account's balance has been increased by the preset amount, and the user can use the transit card for subsequent fares.

[0062] In some embodiments, after setting the value of the recharge type identifier field corresponding to the target transportation card account to a first state value, the method provided in this application embodiment further includes: If the communication link between the terminal device corresponding to the target transportation card account and the vehicle-mounted unit is not disconnected after the automatic recharge operation is completed, a second payment request initiated by the vehicle-mounted unit will be received. The transaction records of the target transportation card account are sent to the vehicle-mounted unit based on the second payment request, so that when the vehicle-mounted unit detects that the recharge type identifier field of the most recent record in the transaction records is the first state value, it performs anti-duplicate verification based on the consumption records before the most recent record.

[0063] In some cases, if a user fails to remove their phone from the vehicle's sensor area promptly after swiping their card, or if the gate's sensing delay prolongs the communication time, the NFC communication link may not be disconnected after automatic top-up, potentially leading to a second transaction request from the vehicle's system. In this situation, the terminal device receives the second payment request and returns a transaction record containing an ARF tag to the vehicle's system. Upon reading the transaction record, the vehicle's system detects that the most recent record is a top-up record (ARF=0x01), skips it, and uses the transaction record preceding the most recent record as the basis for anti-duplicate verification, allowing the second payment request to proceed normally. Thus, through the interaction and cooperation between the terminal device and the vehicle's system, the system can correctly identify top-up records and skip verification. Even if a second payment request occurs due to an unbroken communication link, the anti-duplicate verification mechanism remains operational, preventing duplicate charges.

[0064] In some other embodiments, after setting the value of the recharge type identifier field corresponding to the target transportation card account to the first state value, the method provided in this application further includes: Retrieve multiple consumption records generated by the vehicle's onboard unit; Multiple consumption records are checked for duplicates based on preset deduplication criteria, which include identical transportation card account identifiers, identical vehicle-mounted device identifiers, identical payment resource amounts, and payment time intervals less than preset time thresholds. When a first and a second consumption record that meet the preset duplicate detection conditions are detected, the second consumption record is marked as a suspected duplicate record, and the payment resources corresponding to the second consumption record are returned to the corresponding target transportation card account.

[0065] In this embodiment, the system can retrieve multiple transaction records of a target transportation card account from the transportation card company's backend database. Preset deduplication criteria include: identical transportation card account identifier (same card), identical vehicle-mounted device identifier (same vehicle), identical payment resource amount (same amount), and payment time interval less than a preset time threshold (within the same trip). Furthermore, a search can be performed using a combination of "card number + transaction time window + transaction amount + terminal number". If two records meeting all deduplication criteria are found within the preset time window, the latter record is identified as a suspected duplicate charge and an automatic refund is initiated. Thus, through the backend deduplication and automatic refund mechanism, even if previous anti-duplicate measures fail to completely prevent duplicate charges, the system can automatically identify and refund, reducing user complaints and manual processing costs.

[0066] It should be noted that duplicate checks and refunds can be initiated by the user, replacing automatic system processing. The backend sends a notification to the user regarding suspected duplicate charges, and the system only initiates the refund after the user confirms. This solution reduces the risk of false refunds.

[0067] In some specific embodiments, the process of refunding the payment amount corresponding to the second consumption record to the corresponding target transportation card account may specifically include the following steps: Determine the original payment channel corresponding to the second consumption record; Based on the original payment channel, a resource refund request is initiated, and the payment resource amount corresponding to the second consumption record is refunded to the corresponding target transportation card account via the original payment method.

[0068] In this embodiment, the original payment channel information (such as the linked bank card or third-party payment platform) used for the payment can be obtained from the second consumption record. Then, a refund request is initiated through the original payment channel to return the overcharged amount to the user's payment account or transportation card balance.

[0069] Reference Figure 5 In some embodiments, the transportation card recharge method provided in this application is applied to the security chip of the terminal device, and the specific implementation process may include, but is not limited to, steps S501 to S502: Step S501: In response to the completion of the automatic recharge operation, obtain the recharge record, which contains the amount of recharged resources; Step S502: Update the balance information of the target transportation card account according to the written recharge resource data, and set the value of the recharge type identifier field of the target transportation card account in the terminal device to the first status value. The first status value is used to indicate that the target transportation card account has completed automatic recharge.

[0070] In steps S501 to S502, this embodiment of the application can use the security chip (SE chip) of the terminal device as the execution entity, independently protecting the core processing flow on the SE chip side. Specifically, the SE chip can receive the recharge instruction issued from the card company's backend and, after completing the writing of the amount, obtain the recharge record generated by this automatic recharge operation. The SE chip can write the recharge resource data, update the balance information of the target transportation card account according to the written data, and set the ARF field value in the target transportation card account transaction record to 0x01 (recharge completed). In this way, the writing and storage mechanism of the ARF tag is independently protected from the SE chip side, forming complementary protection with the relevant content on the backend side.

[0071] For example, please refer to Figure 6 , Figure 6 This is a schematic diagram illustrating a process on the security chip side of a terminal device according to an embodiment of this application. The process of recharging a transportation card on the security chip side may include the following steps: Step 1: The SE chip receives the recharge instruction and completes the amount writing. Specifically, the SE chip in the terminal device receives the recharge instruction from the transit card company's backend, which includes parameters such as the recharge amount. The SE chip then executes the amount writing operation according to the recharge instruction, adding the preset amount of resources to the target transit card account's balance and simultaneously updating the card's balance data, completing the core amount change operation for automatic recharge.

[0072] Step 2: Set the Auto-Recharge Status Flag (ARF). After writing the recharge amount, the SE chip sets the recharge type identifier field (i.e., the Auto-Recharge Status Flag ARF) for the target transit card account to the first status value (0x01) and marks the transaction type of the current record as "Auto-Recharge". This flag distinguishes recharge records from regular consumption records, ensuring that the transaction is identified as an auto-recharge record rather than a consumption record when read subsequently.

[0073] Step 3: The on-board unit performs anti-duplicate payment verification and reads transaction records. When the on-board unit initiates another card reading operation for anti-duplicate payment verification, it uses NFC communication to read the transaction records of the target transportation card account stored in the terminal device's security chip, and obtains the most recent transaction record and its corresponding transaction type flag. This step is crucial for the on-board unit to determine whether the current card swipe request constitutes a duplicate payment; the accuracy of the anti-duplicate payment verification depends on whether the transaction record type is correctly identified.

[0074] Step 4: Determine if the most recent transaction record is an automatic top-up. The onboard unit determines whether the transaction is an "automatic top-up" based on the transaction type marker of the most recent transaction record. If the transaction type marker is "automatic top-up," it indicates that the most recent transaction was an automatic top-up operation rather than a consumption record, and the processing logic in Step 5 is executed; if the transaction type is not "automatic top-up," it indicates that the most recent transaction was a consumption record, and the processing logic in Step 6 is executed.

[0075] Step 5: Automatically skip recharge records and read the second most recent transaction record (recharge scenario). Specifically, when the most recent transaction record's transaction type is "automatic recharge," the vehicle-mounted unit automatically skips this recharge record, not using it as the basis for preventing duplicate transactions. Instead, it continues reading the second most recent transaction record; that is, the most recent transaction record preceding the recharge record is used as the basis for preventing duplicate transactions. This mechanism ensures that recharge records do not interfere with the vehicle-mounted unit's judgment of duplicate transactions, preventing the anti-duplicate transaction verification mechanism from failing due to the presence of recharge records.

[0076] Step Six: Use transaction records as the basis for anti-duplicate transaction verification and determine whether a duplicate transaction has occurred. Specifically, if the most recent transaction record is not of the "automatic top-up" type (i.e., a transaction record), the in-vehicle terminal directly uses this transaction record as the basis for anti-duplicate transaction verification. Based on the transaction time, amount, and terminal number in the identified transaction record, the in-vehicle terminal determines whether the current card swipe request is a duplicate transaction: if determined to be a duplicate transaction, the request is rejected to prevent repeated charges for the same trip; if determined to be a non-duplicate transaction, the request is allowed to proceed normally, and the user completes the payment for the ride.

[0077] Reference Figure 7 In some embodiments, the transportation card recharge method provided in this application is applied to an in-vehicle terminal, and the specific implementation process may include, but is not limited to, steps S701 to S702: Step S701: When the vehicle-mounted unit reads the transaction record for anti-duplication verification, the transaction record is returned to the vehicle-mounted unit. Step S702: Perform anti-duplicate verification based on the value of the recharge type identifier field of the most recent record in the transaction record.

[0078] In steps S701 and S702, the vehicle-mounted unit is the executing entity, independently protecting the processing flow of anti-duplicate verification using ARF tags on the vehicle-mounted unit side. Specifically, the vehicle-mounted unit reads the transaction records in the terminal device's security chip via NFC communication. The vehicle-mounted unit checks the value of the ARF field of the most recent record in the transaction records. If ARF=0x01 (recharge record), the record is skipped, and the most recent consumption record is used as the basis for anti-duplicate verification; if ARF=0x00, the most recent record is directly used as the basis for anti-duplicate verification.

[0079] In some embodiments, the process of performing anti-duplicate verification based on the value of the recharge type identifier field of the most recent record in the transaction record may include, but is not limited to, the following steps: Check if the value of the recharge type identifier field in the most recent transaction record is the first state value; When the recharge type identifier field of the most recent record is detected to be in the first state value, the most recent record is skipped, and the consumption record before the most recent record is used as the basis for anti-duplicate verification.

[0080] The onboard unit first checks if the ARF field value of the most recent transaction record is 0x01. If it is, the recharge record is skipped, and the second transaction request is executed normally based on the most recent consumption record. If the most recent record is not a recharge record (i.e., ARF ≠ 0x01), it is processed according to the regular anti-duplicate verification logic. This clarifies the complete logic of the onboard unit's anti-duplicate verification using ARF tags, enabling the onboard unit to correctly identify recharge records and skip verification, thus avoiding anti-duplicate failure caused by interference from recharge records.

[0081] The transportation card recharge method provided in this application has the following significant advantages: First, the delayed queuing mechanism reduces duplicate charges at the source. This application changes the timing of the automatic recharge operation from "immediately after consumption" to "delayed for a certain period of time after consumption," postponing the automatic recharge operation outside the card swiping interaction window, effectively reducing the probability of secondary consumption triggered due to user card swiping delays or device communication delays.

[0082] Second, the problem of recharge records interfering with the anti-recharge mechanism is fundamentally solved by using the Automatic Recharge Status Mark (ARF) mechanism. This application adds an ARF field to the SE chip transaction record to identify whether the most recent transaction record was generated by an automatic recharge operation. When the vehicle-mounted unit performs anti-recharge verification, if it detects that the most recent record is of the automatic recharge type, it automatically skips that record and uses the second most recent transaction record as the verification basis, so that the anti-recharge verification of the vehicle-mounted unit remains effective in the automatic recharge scenario.

[0083] Third, an intelligent delay mechanism balances the needs of timely recharge with conflict prevention. This application dynamically calculates the recharge delay based on multi-dimensional information such as transaction scenario type, NFC communication link status, and historical card swipe duration. While ensuring timely completion of the recharge, it optimizes the timing of the recharge execution to the maximum extent, achieving a balance between conflict prevention and user experience.

[0084] Fourth, the system provides a safety net for user funds through consumption record deduplication and automatic refund mechanisms. Even if duplicate charges occur, the system can automatically identify and refund the user, forming a complete closed loop of "marking + delay + deduplication" to prevent duplicate charges, effectively reducing user complaints and manual processing costs.

[0085] For example, such as Figure 8 The diagram shown is a system architecture diagram of a transportation card recharge processing system provided in this application embodiment. This recharge processing system specifically includes a mobile terminal, a bus-mounted terminal, a transportation card company's backend, and payment channels. The mobile terminal has a built-in security chip (SE chip), which stores transportation card application information, balance information, transaction records, and recharge type identifier fields. The bus-mounted terminal is a card-swiping verification device installed on the bus, equipped with NFC read / write functionality, a duplicate swipe prevention verification module, and a communication module. The transportation card company's backend can receive transaction records, monitor balances in real time, determine delay queues, execute recharges, and perform duplicate checks and refunds. The payment channel refers to the user-linked third-party payment platform or bank used to perform direct debit operations.

[0086] It should be noted that, on the backend side of the transit card company, in response to the first payment request initiated by the terminal device to the vehicle-mounted terminal, the system obtains the consumption record generated by the vehicle-mounted terminal; determines the balance information of the target transit card account based on the consumption record, and triggers and executes an automatic recharge operation when the balance information meets preset conditions. The terminal device's security chip, in response to the completion of the automatic recharge operation, obtains the recharge record, sets the value of the recharge type identifier field of the target transit card account to a first status value, and stores the transaction record containing the recharge record in the security chip. The first status value indicates that the target transit card account has completed automatic recharge. The vehicle-mounted terminal, when the communication link between the terminal device and the vehicle-mounted terminal remains open after the automatic recharge operation and a second payment request is initiated, reads the transaction record. When it detects that the recharge type identifier field of the most recent record in the transaction record is set to the first status value, it uses the consumption record preceding the most recent record as the basis for anti-duplicate verification.

[0087] In one specific embodiment, reference is made to Figure 9 The transportation card recharge method provided in this application embodiment may specifically include the following steps: Step S901: The mobile phone is brought close to the vehicle's onboard unit to establish NFC communication.

[0088] In this process, users bring their NFC-enabled phones close to the card reader area of ​​public transportation vehicles, and the phone's NFC chip establishes a contactless communication connection with the NFC card reader of the vehicle.

[0089] Step S902: The on-board unit reads the most recent transaction records and ARF.

[0090] Step S903: If ARF=0x00 is found, select this transaction record as the verification basis, and select the second most recent transaction record as the verification basis. If ARF=0x01 is found, select the transaction record preceding this recharge record as the verification basis.

[0091] Step S904: If the verification determines that there is no duplicate, the vehicle-mounted unit reads the SE chip and performs the consumption deduction.

[0092] The vehicle-mounted unit reads the target transportation card account information stored in the mobile phone's security chip through the established NFC communication link. After verifying the card's validity, it performs a consumption deduction operation based on the fare for this trip, deducting the fare from the balance of the target transportation card account.

[0093] Step S905: Generate consumption records and upload them to the backend.

[0094] After completing the transaction, the in-vehicle terminal generates a structured transaction record. This record is then uploaded in real-time to the card company's backend system via network communication, serving as the data source for triggering subsequent real-time balance monitoring and automatic top-up processes.

[0095] Step S906: The backend receives consumption records and triggers real-time balance detection.

[0096] Among them, the consumption record receiving module on the back-end of the card company receives the consumption records uploaded by the vehicle-mounted device, persists the consumption records to the database, and simultaneously triggers the real-time balance detection module.

[0097] Step S907: Is the balance below the threshold?

[0098] The real-time balance detection module compares the current balance of the target transportation card account with a preset automatic recharge threshold. If the current balance is greater than or equal to the threshold, it indicates that the balance is sufficient, the process ends, and there is no need to trigger an automatic recharge operation; the user can use the transportation card normally. If the current balance is lower than the threshold, it is determined that an automatic recharge needs to be initiated, and the process proceeds to step S908.

[0099] Step S908: Generate a recharge task, intelligently delay it, and add it to the queue.

[0100] The backend generates a recharge task message based on the target transportation card account's card number, recharge amount, and associated transaction serial number, and calculates the preset delay time for this recharge using an intelligent delay mechanism. After determining the delay time, the backend stores the recharge task message in a delay queue, where the message waits for the preset delay time before being retrieved and executed.

[0101] Step S909: Delayed expiration, recharge execution module deducts the amount.

[0102] The recharge task message waits in the delay queue for a preset delay period until the execution time arrives. The recharge execution module then retrieves the recharge task message from the delay queue. The module then calls the user's linked payment channel to complete the automatic deduction of the preset amount from the user's payment account, preparing to write the funds to the transportation card account.

[0103] Step S910: Send a recharge command to the SE chip, ARF=0x01.

[0104] After successful automatic deduction, the transit card company's backend sends a recharge instruction to the security chip of the terminal device to complete the recharge amount writing. The SE chip writes the recharge record into the transaction record and sets the value of the recharge type identifier field corresponding to the target transit card account to the first status value (0x01) to indicate that the target transit card account has completed automatic recharge.

[0105] Step S911: SE chip balance updated, process ends.

[0106] The SE chip updates the target transit card account's balance information based on the recharge amount, and the recharged amount has been actually added to the transit card account. At this point, the automatic recharge process is complete, and the user can continue to use the transit card for subsequent fares, as the balance has been replenished.

[0107] If the communication link between the phone's NFC chip and the vehicle's onboard unit is not disconnected after the automatic top-up operation, the onboard unit may initiate a second payment request. After reading the transaction records in the SE chip, the onboard unit detects that the most recent record has an ARF value of 0x01, skips that top-up record, and uses the most recent consumption record as the basis for preventing duplicate charges. If it is determined to be a duplicate charge, that is, if there are identical or highly similar transaction records in the historical consumption records, and the latter record is determined to be a suspected duplicate charge, the system will automatically initiate a refund process to return the overcharged amount to the user's linked payment account or transportation card balance, thus providing a safety net.

[0108] It should be noted that the logic for skipping automatic recharge records in the vehicle-mounted terminal can be replaced by the SE chip. When the SE chip receives a card reading request from the vehicle-mounted terminal, it proactively returns a processed list of transaction records, filtering or marking automatic recharge records from the recent transaction list, eliminating the need for special judgment from the vehicle-mounted terminal.

[0109] Reference Figure 10 This application also provides a transportation card recharge processing device, which includes: The record acquisition module 1010 is used to acquire the consumption record generated after the first payment request initiated by the target transportation card account to the vehicle terminal. The trigger module 1020 is used to determine the balance information of the target transportation card account based on the consumption record, and to trigger an automatic recharge operation when the balance information meets the preset conditions. The message generation module 1030 is used to generate a recharge task message when the automatic recharge operation is triggered, and store the recharge task message in a delayed queue. The recharge task message contains the identification information of the target transportation card account. The recharge module 1040 is used to retrieve the recharge task message from the delay queue according to the preset delay time and execute the automatic recharge operation to add a preset amount of resources to the target transportation card account; The first field setting module 1050 is used to write a recharge record into the transaction record of the target transportation card account after the automatic recharge operation is performed, and set the value of the recharge type identifier field corresponding to the target transportation card account to the first status value. The first status value is used to indicate that the target transportation card account has completed the automatic recharge.

[0110] In some embodiments, the transit card top-up processing device further includes: The record acquisition module is used to acquire the recharge record in response to the completion of the automatic recharge operation. The recharge record contains the amount of recharged resources. The second field setting module is used to set the value of the recharge type identifier field of the target transportation card account in the terminal device to the first status value, which indicates that the target transportation card account has completed automatic recharge. The storage module is used to store the transaction records of the target transportation card account, including recharge records, into the security chip.

[0111] In some embodiments, the transit card top-up processing device further includes: The record return module is used to return the transaction record to the vehicle-mounted unit when the unit reads the transaction record for anti-duplication verification. The anti-duplicate verification module is used to perform anti-duplicate verification based on the value of the recharge type identifier field of the most recent record in the transaction record.

[0112] It is evident that the content of the above-mentioned transportation card recharge processing method embodiments is applicable to the embodiments of this transportation card recharge processing device. The specific functions implemented by this transportation card recharge processing device embodiment are the same as those of the above-mentioned transportation card recharge processing method embodiments, and the beneficial effects achieved are also the same as those achieved by the above-mentioned transportation card recharge processing method embodiments.

[0113] Reference Figure 11 , Figure 11 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 1101 can be implemented using a general-purpose central processing unit (CPU), microprocessor, application specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 1102 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 1102 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1102 and is called and executed by the processor 1101 to execute the transportation card recharge method of the embodiments of this application. Input / output interface 1103 is used to implement information input and output; The communication interface 1104 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 1105 transmits information between various components of the device (e.g., processor 1101, memory 1102, input / output interface 1103, and communication interface 1104); The processor 1101, memory 1102, input / output interface 1103 and communication interface 1104 are connected to each other within the device via bus 1105.

[0114] This application also provides a computer program product, which includes a computer program. The processor of a computer device reads and executes the computer program, causing the computer device to perform the aforementioned transportation card recharge method.

[0115] It should be noted that any software tools or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0116] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “including,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes 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 apparatuses.

[0117] It should be understood that in this disclosure, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0118] It should be understood that in the description of the embodiments of this application, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0119] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0120] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0121] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0122] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0123] It should also be understood that the various implementation methods provided in this application can be combined arbitrarily to achieve different technical effects.

[0124] The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. A method for recharging a transportation card, characterized in that, The method includes: Obtain the consumption record generated after the first payment request initiated by the target transportation card account to the vehicle-mounted terminal. The balance information of the target transportation card account is determined based on the consumption record, and an automatic recharge operation is triggered when the balance information meets the preset conditions. When the automatic recharge operation is triggered, a recharge task message is generated and stored in a delay queue. The recharge task message contains the identification information of the target transportation card account. The payment scenario type corresponding to the payment operation is determined based on the attribute information of the consumption record; the communication connection status information corresponding to the target transportation card account is obtained; the historical payment operation data corresponding to the target transportation card account is obtained, the historical payment operation data includes the communication connection duration of each payment operation; a preset delay duration is determined based on at least one of the payment scenario type, the communication connection status information, the communication connection duration, and the default delay duration. The recharge task message is retrieved from the delay queue according to the preset delay time and the automatic recharge operation is executed to add a preset amount of resources to the target transportation card account; After the automatic recharge operation is performed, a recharge record is written into the transaction record of the target transportation card account, and the value of the recharge type identifier field corresponding to the target transportation card account is set to a first status value. The first status value is used to indicate that the target transportation card account has completed automatic recharge, and the first status value is used as the basis for anti-duplicate verification of the next payment request.

2. The method according to claim 1, characterized in that, The step of determining the preset delay duration based on at least one of the payment scenario type, the communication connection status information, the communication connection duration, and the default delay duration includes: Determine a first recommended delay duration corresponding to the payment scenario type, and determine a second recommended delay duration corresponding to the communication connection status information; The maximum duration is determined based on the communication connection duration of each payment operation, and a third recommended delay duration is determined based on the maximum duration and a preset safety margin. The preset delay duration is determined based on at least one of the first recommended delay duration, the second recommended delay duration, the third recommended delay duration, and the default delay duration.

3. The method according to claim 1, characterized in that, After setting the value of the recharge type identifier field corresponding to the target transportation card account to the first state value, the method further includes: If the communication link between the terminal device corresponding to the target transportation card account and the vehicle-mounted unit is not disconnected after the automatic recharge operation is completed, a second payment request initiated by the vehicle-mounted unit will be received. Based on the second payment request, the vehicle-mounted unit sends the transaction records of the target transportation card account to the vehicle-mounted unit, so that when the vehicle-mounted unit detects that the recharge type identifier field of the most recent record in the transaction records is the first status value, it performs anti-duplicate verification based on the consumption records before the most recent record.

4. The method according to claim 1, characterized in that, After setting the value of the recharge type identifier field corresponding to the target transportation card account to the first state value, the method further includes: Obtain multiple consumption records generated by the vehicle-mounted unit; The multiple consumption records are checked for duplicates according to preset deduplication conditions, which include identical transportation card account identifiers, identical vehicle-mounted device identifiers, identical payment resource amounts, and payment time intervals less than preset time thresholds. When a first consumption record and a second consumption record that meet the preset duplicate detection conditions are detected, the second consumption record is marked as a suspected duplicate record, and the payment resources corresponding to the second consumption record are returned to the corresponding target transportation card account.

5. A recharge processing device for a transportation card, characterized in that, The device includes: The record acquisition module is used to acquire the consumption record generated after the first payment request initiated by the target transportation card account to the vehicle terminal. The triggering module is used to determine the balance information of the target transportation card account based on the consumption record, and to trigger an automatic recharge operation when the balance information is detected to meet a preset condition; The message generation module is used to generate a recharge task message when the automatic recharge operation is triggered, and store the recharge task message in a delay queue. The recharge task message contains the identification information of the target transportation card account. The recharge module is used to determine the payment scenario type corresponding to the payment operation based on the attribute information of the consumption record; obtain the communication connection status information corresponding to the target transportation card account; obtain historical payment operation data corresponding to the target transportation card account, the historical payment operation data including the communication connection duration of each payment operation; determine a preset delay duration based on at least one of the payment scenario type, the communication connection status information, the communication connection duration, and the default delay duration; and retrieve the recharge task message from the delay queue according to the preset delay duration and execute the automatic recharge operation to add a preset amount of resources to the target transportation card account. The first field setting module is used to write a recharge record into the transaction record of the target transportation card account after the automatic recharge operation is performed, and to set the value of the recharge type identifier field corresponding to the target transportation card account to a first status value. The first status value is used to indicate that the target transportation card account has completed automatic recharge, and the first status value is used as the basis for anti-duplicate verification of the next payment request.

6. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the method described in any one of claims 1 to 4.

7. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 4.

Images