Multi-scene quick non-inductive payment method and vehicle-mounted device

Abstract

The application is suitable for the field of vehicle non-inductive payment technology, and provides a multi-scene quick non-inductive payment method and a vehicle-mounted device.The method comprises the following steps: acquiring a road image in front of a vehicle and collecting real-time position information of the vehicle, and determining a payment business scene where the current vehicle is located; performing basic communication demand analysis based on the payment business scene, and configuring communication link information; initiating a pre-connection request to a target charging terminal based on the communication link information, and establishing a trusted data interaction channel; receiving business interaction data sent by the target charging terminal based on the trusted data interaction channel by the vehicle-mounted device, and generating an automatic payment request event; sending the automatic payment request event to a payment platform bound by a user in advance, calling a bound payment account to complete deduction, and receiving a transaction result returned by the payment platform.The application realizes quick and low-delay vehicle non-inductive payment, and improves the safety of vehicle non-inductive payment.

Description

Technical Field

[0001] This invention relates to the field of vehicle contactless payment technology, and in particular to a fast contactless payment method and in-vehicle device for multiple scenarios. Background Technology

[0002] With the rapid development of intelligent connected vehicles, vehicle-road cooperative technologies, and mobile payment technologies, the demand for vehicle payments in scenarios such as highway toll collection, parking lot payment, charging station charging, and gas station refueling is constantly increasing. Traditional vehicle payment methods usually require drivers to actively scan codes, swipe cards, insert cards, or complete payment operations through mobile terminals. This not only increases payment time but also easily causes vehicle queues, affecting the efficiency of station traffic and user experience. In the payment execution process, most existing technologies directly initiate payment requests based solely on the order information returned by the toll terminal, lacking a processing mechanism that combines vehicle identity information, real-time vehicle location, and the current payment business scenario to verify order consistency. When the toll order is abnormal, the vehicle is misidentified, or the toll terminal information is incorrect, it is easy to cause erroneous payments, duplicate payments, or incorrect deductions. At the same time, the handling of payment anomalies is relatively simple, usually relying solely on the payment platform for risk interception, lacking a collaborative confirmation mechanism between the vehicle terminal and the user, making it difficult to balance the efficiency of automatic payment and transaction security. Summary of the Invention

[0003] To address the aforementioned technical problems, this invention proposes a fast, contactless payment method and vehicle-mounted device for multiple scenarios, thereby resolving at least one of the aforementioned technical problems.

[0004] In a first aspect, embodiments of this application provide a fast, seamless payment method for multiple scenarios, comprising the following steps: Step S1: Obtain an image of the road ahead of the vehicle and collect real-time location information of the vehicle to determine the current payment transaction scenario in which the vehicle is located; Step S2: Analyze the basic communication requirements based on the payment business scenario and configure the communication link information; Step S3: Initiate a pre-connection request to the target toll terminal based on the communication link information to establish a trusted data interaction channel; Step S4: The vehicle-mounted device receives the business interaction data sent by the target toll terminal based on the trusted data interaction channel and generates an automatic payment request event; Step S5: Send the automatic payment request event to the user's pre-bound payment platform, call the bound payment account to complete the deduction, and receive the transaction result returned by the payment platform.

[0005] Secondly, embodiments of this application provide a vehicle-mounted device, including: The payment scenario confirmation module is used to acquire images of the road ahead of the vehicle and collect real-time location information of the vehicle to determine the current payment transaction scenario of the vehicle. The communication configuration module is used to perform basic communication requirement analysis based on the payment business scenario and configure communication link information; The communication connection module is used to initiate a pre-connection request to the target toll terminal based on the communication link information and establish a trusted data interaction channel. The payment request module is used by the vehicle-mounted device to receive business interaction data sent by the target toll terminal based on the trusted data interaction channel and generate an automatic payment request event. The seamless payment module is used to send automatic payment request events to the user's pre-bound payment platform, call the bound payment account to complete the deduction, and receive the transaction result returned by the payment platform.

[0006] In the aforementioned method and the solution provided by the vehicle-mounted device, by fusing images of the road ahead, real-time vehicle location information, and road environment features, the payment scenario in which the vehicle is located can be accurately identified. This allows for the pre-determination of the corresponding toll service type, avoiding incorrect connections to the toll terminal due to scenario misjudgment, and improving the accuracy of payment scenario identification and the timeliness of payment triggering. Dynamic analysis of communication requirements based on different payment scenarios, combined with communication link quality to configure communication parameters, automatically selects stable and reliable communication methods, reducing communication latency and the probability of link interruption, and improving the stability and connection success rate of data transmission between the vehicle and the toll terminal. Establishing a trusted data interaction channel through a pre-connection mechanism and completing two-way identity authentication and communication link encryption reduces connection waiting time during the formal payment phase, effectively ensuring the authenticity, integrity, and security of business data transmission, and improving the response efficiency of contactless payment.

[0007] By leveraging trusted data exchange channels to obtain payment order information and combining it with vehicle identity, real-time location, and payment business scenarios for consistency verification, order attribution can be accurately confirmed, preventing order mismatches, duplicate payments, and abnormal orders from entering the payment process, thus improving the accuracy and reliability of automatic payments. Submitting automatic payment requests to the payment platform for risk verification and account deduction, while simultaneously generating complete transaction confirmation data, enables real-time feedback of payment results and full-process traceability, ensuring payment security while enhancing the traceability of transaction data and the integrity of the payment process. Attached Figure Description

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

[0009] Figure 1 This is a schematic diagram of the system structure in one embodiment of the present invention; Figure 2 This is a flowchart illustrating a fast, seamless payment method for multiple scenarios in one embodiment of the present invention; Figure 3 yes Figure 2 A schematic diagram of the implementation process of step S1; Figure 4 yes Figure 2 A schematic diagram of the implementation process of step S2; Figure 5 This is a schematic diagram of the structure of a vehicle-mounted device in one embodiment of the present invention; Detailed Implementation The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0010] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. It should also be understood that, as used in this specification and the appended claims, the term "and / or" refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0011] Furthermore, in the description of this invention and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0012] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of the invention include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0013] It should be understood that the sequence number of each step in the following embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0014] To illustrate the technical solution of the present invention, specific embodiments are described below.

[0015] To address the problems mentioned above in the background art, this application provides a method and a vehicle-mounted device. The method provided by this invention can be applied to applications such as... Figure 1 The system shown includes a client and a server.

[0016] In one embodiment, such as Figure 2 As shown, a fast and seamless payment method for multiple scenarios is provided, and this fast and seamless payment method for multiple scenarios is applied to... Figure 1 Taking the system in the example, the following steps are included: Step S1: Obtain an image of the road ahead of the vehicle and collect real-time location information of the vehicle to determine the current payment transaction scenario in which the vehicle is located; Step S2: Analyze the basic communication requirements based on the payment business scenario and configure the communication link information; Step S3: Initiate a pre-connection request to the target charging terminal based on the communication link information to establish a trusted data interaction channel; Step S4: The vehicle-mounted device receives the business interaction data sent by the target toll terminal based on the trusted data interaction channel and generates an automatic payment request event; Step S5: Send the automatic payment request event to the user's pre-bound payment platform, call the bound payment account to complete the deduction, and receive the transaction result returned by the payment platform.

[0017] In this embodiment, during normal vehicle operation, the on-board device continuously connects to the CAN bus and acquires the vehicle's speed with a sampling period of 100 ms. When the vehicle's speed is detected to be below 30 km / h for five consecutive sampling periods, the vehicle is determined to have entered a low-speed payment recognition state, and the scene recognition process is automatically initiated. The on-board forward-facing camera continuously acquires images of the road ahead of the vehicle, with a camera resolution set to 1920×1080 and a frame rate of 30 fps. Simultaneously, the GNSS positioning module outputs the vehicle's real-time location information at an update frequency of 10 Hz, with positioning accuracy controlled within ±1.5 m. The on-board device matches and analyzes visual targets such as charging pile signs, parking gates, toll gates, and fuel dispenser signs in the road images with the station information in the electronic map, and calculates the probability of the vehicle entering the station based on the vehicle's current location and driving direction. When a vehicle is less than 80 meters from the target charging station and its heading is aligned with the station entrance, the system determines that the vehicle is currently in a charging service payment scenario and generates corresponding payment scenario information. The onboard unit establishes a communication requirement model based on this scenario and simultaneously activates Bluetooth BLE, Wi-Fi, NFC, UWB, and 5G-V2X communication interfaces. It continuously monitors the toll terminal's broadcast information at 100 ms intervals, collecting broadcast data over five consecutive scan cycles. The system statistically analyzes the signal strength changes, communication latency, data integrity rate, and connection success rate of each communication link, and calculates the spatial location of the toll terminal using the charging station equipment coordinates on an electronic map. If the communication latency is no more than 100 ms, the data integrity rate is no less than 99%, and the connection success rate is no less than 95%, the toll terminal is retained as a candidate terminal. Subsequently, a comprehensive ranking is performed based on the vehicle's direction of travel and the distance between the vehicle and the terminal. The toll terminal with the highest comprehensive score is selected as the target toll terminal, and communication connection information is automatically generated, including the communication protocol type, communication channel number, encryption method, and reconnection parameters, enabling pre-configuration of communication resources.

[0018] Based on the communication connection information, the system proactively initiates a pre-connection request to the target toll terminal and establishes a secure communication environment through a trusted handshake process. The toll terminal returns terminal identity characteristics information such as device identification number, digital certificate, public key identifier, security authentication parameters, and service type. The on-board unit calls the vehicle digital identity credential stored in the security chip to verify the legitimacy of the toll terminal's digital certificate, while the toll terminal verifies the vehicle's digital identity in reverse. After both parties pass authentication, they jointly negotiate and generate a temporary communication key and a unique session identifier applicable only to this transaction, and complete the encryption configuration of the communication link. The entire data interaction process is protected by a temporary communication key. The on-board unit continuously monitors the communication status. When the communication latency remains within 100 ms, it is determined that the trusted data interaction channel has been successfully established, and then the business data interaction phase begins.

[0019] The toll terminal sends business interaction data to the on-board unit. The on-board unit parses the business message according to the agreed protocol, extracting order information such as order number, vehicle identification information, charging gun number, charging capacity, billing rules, service fee, and amount to be paid. Simultaneously, it reads the vehicle's digital identity information, GNSS positioning information, and the current payment scenario to perform consistency verification. During verification, it confirms that the ordered vehicle matches the current vehicle, that the vehicle is still within 80 meters of the toll terminal, that the vehicle's speed is still below 30 km / h, and that the order service type matches the currently identified charging service payment scenario. Once all the above information matches, an automatic payment request event is generated using the vehicle identification, order number, payment amount, toll terminal number, and current session identifier. The event's generation time and current communication link status are recorded, providing complete transaction information for the payment platform authorization.

[0020] The onboard unit uses a security chip to complete digital signature and encrypted encapsulation, and sends the payment authentication message to the user's pre-bound payment platform. The payment platform conducts a payment risk assessment based on the vehicle's digital identity, the toll terminal's trusted status, the transaction amount, the transaction location, and the account authorization status. If the assessment determines there is no risk, it automatically deducts funds from the bound payment account and returns the transaction serial number, transaction amount, transaction time, and payment status. Upon receiving the payment result, the onboard unit simultaneously obtains payment confirmation feedback from the toll terminal and generates transaction confirmation data by combining the transaction time, transaction amount, payment status, transaction serial number, toll terminal number, and communication link status. If the payment platform indicates a risk, the current automatic payment request event is immediately frozen, while maintaining the trusted data interaction channel and temporary communication key. A secondary confirmation request is sent to the user's mobile communication terminal, with a confirmation validity period of 30 seconds. The automatic payment process resumes after the user confirms payment. If the user refuses payment or the confirmation times out, the current transaction is terminated, and communication session resources are released, completing the entire seamless payment process. This ensures both payment efficiency and payment security, as well as the controllability of abnormal transactions.

[0021] In one embodiment, such as Figure 3 As shown, step S1 specifically includes the following steps: The vehicle speed is monitored in real time during vehicle operation. When the vehicle speed is lower than the preset trigger threshold, the vehicle-mounted device retrieves images from the vehicle-mounted camera to acquire images of the road in front of the vehicle and collect the vehicle's real-time location information. Based on the road image in front of the vehicle, visual features of the scene are extracted to identify features of toll facilities, station entrances and road signs, and real-time scene information is generated. Based on real-time scene information and vehicle real-time location information, scene correlation analysis is performed to generate scene analysis results; The payment scenario for the current vehicle is determined based on the scenario analysis results. These payment scenarios include highway toll payment, parking fee payment, charging service payment, and refueling service payment.

[0022] In this embodiment, the on-board device continuously connects to the vehicle's CAN bus and reads the vehicle's speed every 100 ms. When five consecutive sampling results are all below 30 km / h, the vehicle is determined to have entered a low-speed payment recognition state to avoid false triggering due to short-term vehicle deceleration. After entering the recognition state, the on-board forward-facing camera is immediately invoked to acquire road images. The camera resolution is set to 1920×1080, the acquisition frame rate is 30 fps, and 10 consecutive frames of road images are acquired as the analysis object. At the same time, the GNSS positioning module is invoked to obtain the vehicle's real-time location information. The positioning update frequency is set to 10 Hz, and the positioning accuracy is controlled within ±1.5 m. The vehicle's heading angle, road number, and electronic map matching results are read simultaneously to form a raw scene dataset with a unified timestamp.

[0023] Image preprocessing algorithms are used to correct image distortion, equalize brightness, and filter noise. Then, an object detection network is employed to identify target objects in the image, such as toll collection facilities, station entrances, road signs, parking lot gates, charging pile signs, gas station brand logos, and highway toll gates. Category information, boundary positions, size information, and confidence parameters of the target objects are extracted. Furthermore, the number of road lanes, the area of ​​the open area in front of vehicles, road curvature, and the relative distance between vehicles and toll collection facilities are calculated to generate real-time scene information. Only target objects with a detection confidence score greater than 0.90 are retained for subsequent analysis to improve scene recognition accuracy and reduce the impact of misidentification in complex traffic environments.

[0024] Based on GNSS positioning results and matching road attribute information from the electronic map, the system obtains the road type, road function level, and surrounding Points of Interest (POIs) corresponding to the current location. It then calculates the consistency of the vehicle's driving direction by combining the vehicle's heading angle with the direction of the road ahead, and performs scene correlation calculations based on the spatial distance between the vehicle's current location and the toll collection facility. When the vehicle is less than 80 meters from the toll collection facility and the heading angle deviation is less than 15°, the system determines that the vehicle has a tendency to enter the target toll station. Simultaneously, it calculates the approach rate to the toll collection facility by combining the target position changes in 10 consecutive frames of images, performing a secondary verification to confirm whether the vehicle has actually entered the toll area. This generates scene analysis results, thus avoiding misjudgments caused by complex environments such as adjacent toll areas, auxiliary roads, and service areas.

[0025] If a highway toll gate, ETC sign, and highway road attributes are detected, the scenario is identified as a highway toll collection scenario; if a parking lot gate, parking fee sign, and parking lot entrance are detected, the scenario is identified as a parking payment scenario; if charging pile equipment, charging space signs, and new energy charging station information are detected, the scenario is identified as a charging service payment scenario; and if a fuel dispenser, gas station brand logo, and refueling lane are detected, the scenario is identified as a refueling service payment scenario. When different scenario features coexist, a comprehensive score is calculated based on the target object detection confidence, vehicle movement direction consistency, spatial distance, and historical trajectory continuity. The scenario with the highest score is selected as the final payment scenario, and the scenario type, station number, vehicle current location, and recognition confidence are encapsulated to generate the payment scenario recognition result.

[0026] In one embodiment, such as Figure 4 As shown, step S2 specifically includes the following steps: Based on the aforementioned payment business scenario, basic communication requirements are analyzed to generate communication connection requirements. Based on communication connectivity requirements, the vehicle-mounted device activates multiple communication interfaces for broadcast detection to identify the communication links of the toll terminal. Calculate the signal stability, communication latency, data integrity rate, and connection success probability of the communication link to generate communication link parameters. Identify the spatial location of toll collection terminals and perform link matching analysis based on communication link parameters to filter target toll collection terminals; Configure communication link information based on the target toll terminal, including the target communication type and communication connection parameters.

[0027] In this embodiment, after the payment scenario is identified, the on-board unit does not directly initiate communication. Instead, it establishes a corresponding communication requirement model based on the current scenario type. Different payment scenarios have different requirements for communication methods. For example, highway toll collection focuses more on millisecond-level response capabilities, parking payment focuses more on short-range communication stability, and charging and refueling services require support for continuous data interaction and status synchronization. Therefore, the on-board unit dynamically configures communication requirements by comprehensively considering the vehicle's current location, driving direction, speed, and the spatial distribution of the toll station. When the vehicle's speed is consistently below 30 km / h and the distance to the target toll station is less than 80 m, it is determined that the vehicle has entered the communication preparation area. At this time, a corresponding communication connection request is generated, and the relevant communication modules are woken up in advance, so that the communication preparation process is synchronized with the vehicle's approach to the toll station, thereby reducing the waiting time after the vehicle arrives at the toll area.

[0028] The vehicle-mounted device simultaneously activates multiple communication interfaces, including Bluetooth BLE, Wi-Fi, NFC, UWB, and 5G-V2X, continuously monitoring broadcast signals from surrounding devices with a scan cycle of 100 ms. It collects broadcast data from each toll collection terminal over five consecutive scan cycles. The collected data includes device identification, broadcast timestamp, communication protocol type, broadcast strength, and broadcast duration, and is organized according to a unified data structure. To address the possibility of the same toll collection terminal broadcasting repeatedly via different communication interfaces, the device identification, broadcast time, and spatial location are correlated and aggregated to form a unique toll collection terminal broadcast record. Terminals that broadcast less than three times, have abnormal broadcast intervals, or lack broadcast content are directly excluded to prevent occasional signal interference from affecting subsequent communication decisions, ensuring that all toll collection terminals participating in the evaluation have good broadcast continuity and connectivity.

[0029] Communication quality is evaluated for each communication link. The vehicle-mounted device continuously sends fixed-length probe data packets to candidate toll collection terminals and records the results of 10 consecutive interactions, statistically analyzing the link response characteristics. Signal stability is calculated using the continuous variation amplitude of RSSI; smaller fluctuations indicate more stable communication. Communication latency is evaluated using the average of 10 round-trip times. Data integrity rate is obtained based on the ratio of the actual number of received data packets to the number sent. Connection success probability is statistically analyzed based on the results of 10 connection establishments. The above evaluation indicators are uniformly converted into a comparable comprehensive score, and links with communication latency exceeding 100 ms, data integrity rate below 99%, and connection success probability below 95% are eliminated, retaining only candidates that meet the communication requirements, thereby ensuring that subsequent payment data can be transmitted through stable and reliable communication links.

[0030] The vehicle-mounted device further combines the field station coordinates on the electronic map, GNSS positioning results, and the broadcast signal strength of each toll terminal to calculate the actual spatial location of the toll terminal and analyze the matching relationship between the vehicle's current heading and the toll terminal's orientation. When multiple toll terminals simultaneously meet the communication requirements, the candidate toll terminals are prioritized based on the vehicle's direction of travel, the spatial distance between the vehicle and the toll terminal, the overall communication score, and the vehicle's expected entry path. The toll terminal that best matches the vehicle's current trajectory is selected as the target communication object. Communication connection information is automatically generated according to the communication protocol supported by the target toll terminal, including the target communication type, communication channel number, data encryption method, link hold time, and abnormal reconnection parameters. This communication connection information is then sent to the vehicle-mounted communication control module, enabling the vehicle to quickly connect directly after entering the toll area. This avoids misconnection problems caused by cross-over of broadcast signals from nearby parking lots, charging stations, or gas stations, improving the communication reliability and response efficiency of the entire contactless payment process.

[0031] In one embodiment, step S3 specifically includes the following steps: Based on the communication link information, a pre-connection request is initiated to the target charging terminal to obtain the terminal identity feature information broadcast by the target charging terminal. The terminal identity feature information includes device identity information, service type information, digital certificate information, and security authentication parameters. Based on the vehicle's digital identity credentials invoked by the in-vehicle device, two-way trusted authentication is performed based on the terminal's identity feature information. Once authentication is successful, a temporary communication key and session identifier are generated, the data transmission link is encrypted, and a trusted data interaction channel is established.

[0032] In this embodiment, the on-board unit automatically initiates a pre-connection request to the target toll terminal based on the target communication type, instead of waiting for the vehicle to fully enter the toll area before establishing a communication connection. The pre-connection request is sent through the target communication channel determined in the previous stage, carrying the vehicle's basic connection identifier, communication protocol version, and random handshake identifier to notify the toll terminal to enter the pre-communication state. After receiving the request, the toll terminal returns a broadcast response. The on-board unit continuously receives no less than three broadcast response data and performs a consistency comparison of the broadcast content. Only when the continuous response content remains consistent is the toll terminal considered to be in a stable online state. Protocol parsing is performed on the broadcast data to extract terminal identity feature information, including device identification number, service type, digital certificate, public key identifier, security authentication parameters, and protocol version number, and a toll terminal identity information table is established to provide basic data for subsequent trusted authentication. For terminals with missing broadcast content or abnormal continuous responses, the current connection process is directly terminated, and a new target toll terminal is searched for, preventing abnormal terminals from participating in payment interactions from the source.

[0033] The onboard unit uses the digital identity credential stored in the vehicle's internal security chip to reliably verify the identity of the toll terminal. The vehicle's digital identity credential includes a unique vehicle identifier, a vehicle digital certificate, public key information, and an authorization identifier. This credential is read and signed by the security chip, and is always stored within the chip and not transmitted in plaintext. During authentication, the onboard unit first verifies the completeness of the toll terminal's digital certificate, its consistency with the service type, and its validity period. It also verifies that the device identification number returned by the toll terminal matches the station device number registered on the electronic map. The toll terminal then performs reverse verification of the vehicle's legitimacy based on the digital identity information sent by the vehicle, confirming the vehicle's authenticity and authorization status. Only when both parties complete identity verification and the results are consistent is the two-way reliable authentication considered successful. If any authentication fails, the current connection is immediately disconnected, and the system re-enters the toll terminal screening process to prevent counterfeit terminals or unauthorized vehicles from accessing the payment link.

[0034] Both parties jointly generate a temporary communication key for this communication using a random number negotiation mechanism, and simultaneously generate a unique session identifier. The temporary communication key corresponds only to the current payment transaction and expires immediately after the session ends, not participating in the next payment process, thus reducing the security risks associated with long-term use of fixed keys. The vehicle-mounted device configures the data transmission link securely based on the negotiation results, including setting data encryption methods, integrity verification parameters, message sequence numbers, and communication timeout times. The communication timeout time is uniformly set to 100 ms, consistent with the aforementioned communication link performance evaluation. Upon continuously receiving encrypted confirmation information from the toll terminal, the vehicle-mounted device enters a trusted communication state and establishes a dedicated data interaction channel for the current payment transaction. This data interaction channel, in addition to transmitting toll orders, payment requests, and payment results, also simultaneously records link status, data retransmission counts, and communication anomaly information, providing a complete data foundation for subsequent payment reliability analysis and anomaly handling, while ensuring the authenticity, integrity, and confidentiality of data transmission throughout the entire payment process.

[0035] In one embodiment, step S4 specifically includes the following steps: The vehicle-mounted device receives business interaction data sent by the target toll terminal based on a trusted data interaction channel; The business interaction data is parsed using business protocols to extract charge order information; The system extracts vehicle identity information, real-time vehicle location information, and payment business scenario information to verify the consistency of the charging order information. When the verification is successful, an automatic payment request event is generated.

[0036] In this embodiment, the vehicle-mounted device begins monitoring the business interaction data sent by the toll terminal and filters the received data based on the previously negotiated session identifier, processing only data packets belonging to the current communication session. Upon arrival of business data, the system first verifies data integrity and message sequence continuity, confirming that no data has been lost, duplicated, or tampered with. Then, it decapsulates the data according to the data format agreed upon during session establishment to restore the original business content. To avoid data anomalies caused by network jitter, the vehicle-mounted device completes data caching and reassembly within a 100 ms data reception window and performs consistency comparisons on multiple consecutively received data for the same order, retaining only the data with consistent content and the latest timestamp as the object of this business processing, thereby ensuring high reliability and integrity of the data entering subsequent analysis.

[0037] The on-board unit automatically identifies the meaning of each field based on the business agreement template corresponding to the toll terminal and extracts the toll order information. The toll order information mainly includes order number, service type, vehicle identification information, consumption start time, consumption end time, billing rules, consumption details, discount information, amount to be paid, and toll terminal number, while simultaneously establishing a structured dataset of toll orders. Different data parsing strategies are adopted for different payment scenarios. For example, in highway toll scenarios, the system focuses on parsing entrance and exit stations and toll interval information; in parking payment scenarios, it focuses on parsing entry time, parking duration, and parking rate; in charging service payment scenarios, it focuses on parsing charging volume, service electricity price, service fee, and charging gun number; and in refueling service payment scenarios, it focuses on parsing fuel type, refueling volume, and unit price, ensuring that data from different businesses can be converted into a unified data structure, providing standardized input for subsequent consistency verification.

[0038] The onboard device synchronously retrieves the vehicle's digital identity information, real-time vehicle location information, and the current payment transaction scenario to perform multi-dimensional consistency verification on the payment order. The vehicle identity information is verified against the vehicle identification information in the payment order to confirm that the order belongs to the current vehicle. The real-time vehicle location information uses GNSS positioning results consistent with the previous steps, maintaining a positioning update frequency of 10 Hz and a positioning accuracy of ±1.5 m. Combined with an electronic map, the actual distance between the vehicle and the payment terminal is calculated, and it is verified whether the vehicle is still within the target station's service area. Simultaneously, based on the previously identified payment transaction scenario, the service type in the order is matched and analyzed. For example, if the identification result is a charging service payment scenario, only charging orders are allowed to be processed, and parking or highway toll orders are not accepted. When the vehicle remains within 80 m of the target payment terminal and the vehicle's speed remains below 30 km / h, the continuity of the current business behavior is further confirmed to prevent erroneous order acceptance even after the vehicle has left the target area.

[0039] Once the vehicle identity, vehicle location, and payment scenario verification results all meet the consistency requirements, the on-board unit continues to check whether the order number has been processed, whether there are duplicate records of the amount to be paid, and whether the current communication session remains valid, to prevent duplicate payments and accidental triggering of historical orders. After all verifications pass, based on the vehicle identity identifier, order number, payment terminal number, payment amount, business scenario type, and current session identifier, an automatic payment request event is automatically generated and assigned a unique transaction record identifier. The payment request generation time, communication link status, and verification results are also recorded. The generated automatic payment request event is temporarily stored in the on-board payment cache queue, awaiting further authorization processing from the payment platform, thus ensuring complete business continuity and traceability throughout the entire payment process.

[0040] In one embodiment, step S5 specifically includes the following steps: The security chip of the vehicle-mounted device performs digital signature and encrypted encapsulation on automatic payment request events to generate payment authentication messages. The payment authentication message is sent to the user's pre-bound payment platform to conduct a payment risk assessment and output the payment risk assessment result; When the payment risk assessment result is no risk, the system automatically calls the bound payment account to complete the deduction, receives the transaction result returned by the payment platform, and generates transaction confirmation data containing transaction time, transaction amount, payment status, and communication link information.

[0041] In this embodiment, the vehicle-mounted device sends the event to the vehicle-mounted security chip for secure processing. The security chip first reads key information from the payment request, including the order number, vehicle digital identity, payment amount, toll terminal number, service scenario type, session identifier, and request generation time, and generates a data block to be authenticated according to a preset data format. It then uses the vehicle's private key stored internally in the security chip to perform a digital signature operation, generating a unique signature digest. Simultaneously, it uses a temporary communication key negotiated during the session establishment phase to encrypt and encapsulate the data block to be authenticated, ensuring that the order content, vehicle identity, and payment parameters remain encrypted throughout transmission. The entire digital signature and encryption process is completed internally within the security chip; the private key data is not accessed externally, preventing identity forgery or data tampering during the payment process. After encapsulation, the digital signature, encrypted data, vehicle digital certificate identifier, and session identifier are combined to form a payment authentication message. The message integrity is then verified, and after confirmation, the payment is sent.

[0042] The payment authentication message is sent to the user's pre-bound payment platform through the established trusted data interaction channel. Upon receiving the message, the payment platform jointly verifies the authenticity of the digital signature, the legality of the vehicle's identity, and the trustworthiness of the toll terminal, and conducts a payment risk assessment based on the transaction behavior. During the assessment, the order amount, transaction time, vehicle's current location, toll terminal number, and payment scenario are analyzed in conjunction with the user's historical payment behavior, current transaction frequency, and account authorization status for a comprehensive judgment. For example, if the vehicle's real-time location information matches the toll terminal's registered location, the vehicle remains within 80 meters of the target toll area, the vehicle's speed remains below 30 km / h, the transaction order matches the current payment scenario, and the toll terminal's digital certificate is valid and the communication link remains normal, then the transaction is deemed to meet normal payment characteristics. If abnormal transaction location, short-term duplicate payments, abnormal terminal identity, or a transaction amount significantly deviating from historical levels are detected, the risk level is increased, and the automatic deduction process is suspended. After completing the comprehensive analysis, the payment platform outputs the payment risk assessment result and returns it to the onboard device.

[0043] When the payment risk assessment determines there is no risk, the payment platform automatically deducts funds from the user's pre-authorized payment account, without requiring manual confirmation from the driver. After successful deduction, the payment platform generates a transaction serial number and returns transaction completion information, including transaction time, transaction amount, payment status, transaction serial number, and payment account identifier. Simultaneously, the on-board unit receives payment confirmation feedback from the toll terminal and correlates the two sets of information. Combining the current communication status information, the transaction time, transaction amount, payment status, transaction serial number, communication link status, toll terminal number, and session identifier are uniformly encapsulated to generate transaction confirmation data. The communication link status records the actual communication type, communication latency, and link quality evaluation results used during the payment process, with the communication latency remaining within 100 ms as required by the aforementioned assessment. The generated transaction confirmation data is stored in the on-board unit's local transaction record area and payment log database, and simultaneously sent to the toll terminal to update the order status, thus forming a complete payment loop. This provides reliable data support for subsequent payment result queries, anomaly tracing, and payment strategy optimization.

[0044] In one embodiment, it further includes: If the payment risk assessment result indicates that there is a risk, the automatic payment process is suspended, and a secondary confirmation request is sent to the user's mobile communication terminal through the vehicle terminal. Accept user confirmation; Analyze the payment execution based on the user's manually confirmed information to determine whether to continue automatic payment, terminate payment, or re-initiate payment.

[0045] In this embodiment, when the payment risk assessment result returned by the payment platform indicates the existence of a risk, the vehicle-mounted device immediately suspends the current automatic payment process and freezes the automatic payment request event to prevent the payment request from continuing. Simultaneously, the system retains the established trusted data interaction channel and temporary communication key to keep the payment order data valid and prevent business interruption caused by re-establishing the communication link. The vehicle-mounted device synchronously records the risk type, order number, payment terminal number, transaction amount, payment business scenario, and risk trigger time corresponding to this risk event, and generates a risk event identifier. Based on the risk reason returned by the payment platform, the risk event is classified, such as abnormal transaction location, abnormal trusted status of the payment terminal, repeated transactions within a short period, abnormal transaction amount, or changes in account authorization status, and the risk reason is written into the risk event record. A secondary confirmation request is sent to the user's mobile communication terminal through the vehicle's bound mobile communication method. The request content includes the service type, payment amount, transaction location, order number, risk warning information, and confirmation validity time, where the confirmation validity time is set to 30 seconds. Within this time window, the order remains frozen while continuously maintaining the trusted communication link to ensure that the user can directly resume the transaction after confirmation without re-establishing the payment process.

[0046] The mobile communication terminal transmits the user confirmation result, identity authentication result, and confirmation time back to the vehicle-mounted device. Upon receiving the confirmation information, the vehicle-mounted device first verifies whether the confirmation information belongs to the current transaction session and checks whether the confirmation return time is within a preset 30-second valid time window. If the valid time is exceeded, the confirmation is automatically deemed invalid, and the current transaction ends. For valid confirmation information, the device further verifies whether the user's identity matches the vehicle's bound account. Simultaneously, it reconfirms whether the vehicle is still within the target toll area, meaning the vehicle's location information remains within 80 meters of the target toll terminal, and the vehicle's speed is still below 30 km / h, to prevent payment operations from being performed after the vehicle has left the toll area. After completing the above verifications, the user confirmation result is converted into standardized confirmation data and associated with the current order information, payment risk type, and communication status to form a complete manual confirmation record, providing a basis for subsequent payment decisions.

[0047] The on-board unit performs payment execution analysis based on payment risk type, user confirmation result, vehicle operating status, and the current status of the toll terminal. For transactions where the user confirms payment, the toll terminal remains online, the trusted communication link is uninterrupted, and the communication latency does not exceed 100 ms, the system unfreezes the transaction, restores the original automatic payment request event to the execution queue, and re-invokes the payment platform to complete the automatic deduction without regenerating order information. For transactions where the user actively refuses payment or the confirmation result is invalid, the payment process is immediately terminated, a transaction cancellation notification is sent to the toll terminal, and the session identifier and temporary communication key are released, ending the trusted data interaction channel. If the user confirms payment, but the transaction cannot continue due to communication anomalies, changes in the toll terminal status, or an invalid order returned by the payment platform, the original order information is retained, a new payment request is generated, and the payment process is re-initiated. Finally, the on-board unit writes the payment execution analysis results, manual confirmation results, final processing method, and processing completion time into the transaction log, forming a complete record of abnormal payment processing. This provides traceable data for subsequent risk model optimization, payment behavior analysis, and system operation evaluation.

[0048] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0049] In one embodiment, an in-vehicle device is provided, which corresponds one-to-one with the fast, contactless payment methods for multiple scenarios described in the above embodiments. For example... Figure 5 As shown, the device includes: The payment scenario confirmation module is used to acquire images of the road ahead of the vehicle and collect real-time location information of the vehicle to determine the current payment transaction scenario of the vehicle. The communication configuration module is used to perform basic communication requirement analysis based on the payment business scenario and configure communication link information; The communication connection module is used to initiate a pre-connection request to the target toll terminal based on the communication link information and establish a trusted data interaction channel. The payment request module is used by the vehicle-mounted device to receive business interaction data sent by the target toll terminal based on the trusted data interaction channel and generate an automatic payment request event. The seamless payment module is used to send automatic payment request events to the user's pre-bound payment platform, call the bound payment account to complete the deduction, and receive the transaction result returned by the payment platform.

[0050] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0051] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0052] The aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), or Field Programmable Gate Arrays (FPGAs). Programmable Gate Array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0053] The memory can be an internal storage unit of the computer device, such as a hard drive or RAM. The memory can also be an external storage device of the computer device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory can include both internal and external storage units of the computer device.

[0054] 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, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0055] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0056] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0057] In the embodiments provided in this application, it should be understood that the disclosed apparatus / devices and methods can be implemented in other ways. For example, the apparatus / device embodiments described above are merely illustrative. For instance, the division of modules or 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; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0058] 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.

[0059] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A fast, seamless payment method for multiple scenarios, characterized in that, Includes the following steps: Step S1: Obtain an image of the road ahead of the vehicle and collect real-time location information of the vehicle to determine the current payment transaction scenario in which the vehicle is located; Step S2: Analyze the basic communication requirements based on the payment business scenario and configure the communication link information; Step S3: Initiate a pre-connection request to the target charging terminal based on the communication link information to establish a trusted data interaction channel; Step S4: The vehicle-mounted device receives the business interaction data sent by the target toll terminal based on the trusted data interaction channel and generates an automatic payment request event; Step S5: Send the automatic payment request event to the user's pre-bound payment platform, call the bound payment account to complete the deduction, and receive the transaction result returned by the payment platform.

2. The fast, seamless payment method for multiple scenarios according to claim 1, characterized in that, The specific steps of step S1 are as follows: The vehicle speed is monitored in real time during vehicle operation. When the vehicle speed is lower than the preset trigger threshold, the vehicle-mounted device retrieves images from the vehicle-mounted camera to acquire images of the road in front of the vehicle and collect the vehicle's real-time location information. Based on the road image in front of the vehicle, visual features of the scene are extracted to identify features of toll facilities, station entrances and road signs, and real-time scene information is generated. Based on real-time scene information and vehicle real-time location information, scene correlation analysis is performed to generate scene analysis results; The payment transaction scenario of the vehicle is determined based on the scenario analysis results.

3. The fast, seamless payment method for multiple scenarios according to claim 2, characterized in that, The payment service scenarios include highway toll payment scenarios, parking fee payment scenarios, charging service payment scenarios, and refueling service payment scenarios.

4. The fast, seamless payment method for multiple scenarios according to claim 2, characterized in that, The specific steps of step S2 are as follows: Based on the aforementioned payment business scenario, basic communication requirements are analyzed to generate communication connection requirements. Based on communication connectivity requirements, the vehicle-mounted device activates multiple communication interfaces for broadcast detection to identify the communication links of the toll terminal. Calculate the signal stability, communication latency, data integrity rate, and connection success probability of the communication link to generate communication link parameters. Identify the spatial location of toll collection terminals and perform link matching analysis based on communication link parameters to filter target toll collection terminals; Configure communication link information based on the target toll terminal, including the target communication type and communication connection parameters.

5. The fast, seamless payment method for multiple scenarios according to claim 4, characterized in that, Step S3 is as follows: Based on the communication link information, a pre-connection request is initiated to the target charging terminal to obtain the terminal identity feature information broadcast by the target charging terminal. The terminal identity feature information includes device identity information, service type information, digital certificate information, and security authentication parameters. Based on the vehicle's digital identity credentials invoked by the in-vehicle device, two-way trusted authentication is performed based on the terminal's identity feature information. Once authentication is successful, a temporary communication key and session identifier are generated, the data transmission link is encrypted, and a trusted data interaction channel is established.

6. The fast, seamless payment method for multiple scenarios according to claim 5, characterized in that, The specific steps of step S4 are as follows: The vehicle-mounted device receives business interaction data sent by the target toll terminal based on a trusted data interaction channel; The business interaction data is parsed using business protocols to extract charge order information; The system extracts vehicle identity information, real-time vehicle location information, and payment business scenario information to verify the consistency of the charging order information. When the verification is successful, an automatic payment request event is generated.

7. The fast, seamless payment method for multiple scenarios according to claim 6, characterized in that, The chargeable order information includes service type, vehicle identification information, consumption time, billing rules, order number, consumption details, and amount to be paid.

8. The fast, seamless payment method for multiple scenarios according to claim 6, characterized in that, The specific steps of step S5 are as follows: The security chip of the vehicle-mounted device performs digital signature and encrypted encapsulation on automatic payment request events to generate payment authentication messages. The payment authentication message is sent to the user's pre-bound payment platform to conduct a payment risk assessment and output the payment risk assessment result; When the payment risk assessment result is no risk, the system automatically calls the bound payment account to complete the deduction, receives the transaction result returned by the payment platform, and generates transaction confirmation data containing transaction time, transaction amount, payment status, and communication link information.

9. The fast, seamless payment method for multiple scenarios according to claim 8, characterized in that, Also includes: If the payment risk assessment result indicates that there is a risk, the automatic payment process is suspended, and a secondary confirmation request is sent to the user's mobile communication terminal through the vehicle terminal. Accept user confirmation; Analyze the payment execution based on the user's manually confirmed information to determine whether to continue automatic payment, terminate payment, or re-initiate payment.

10. A vehicle-mounted device, characterized in that, The steps for implementing the fast, contactless payment method for multiple scenarios as described in any one of claims 1 to 9 include: The payment scenario confirmation module is used to acquire images of the road ahead of the vehicle and collect real-time location information of the vehicle to determine the current payment transaction scenario of the vehicle. The communication configuration module is used to perform basic communication requirement analysis based on the payment business scenario and configure communication link information; The communication connection module is used to initiate a pre-connection request to the target toll terminal based on the communication link information and establish a trusted data interaction channel. The payment request module is used by the vehicle-mounted device to receive business interaction data sent by the target toll terminal based on the trusted data interaction channel and generate an automatic payment request event. The seamless payment module is used to send automatic payment request events to the user's pre-bound payment platform, call the bound payment account to complete the deduction, and receive the transaction result returned by the payment platform.

Images