Payment recommendation method and apparatus, device, and medium

Abstract

This application relates to the field of vehicle technology, and more particularly to a payment recommendation method, apparatus, device, and medium. The method, applied to a diagnostic device, includes: displaying a diagnostic application interface; obtaining the network location identifier of the diagnostic device in response to a payment request operation; the payment request operation being used to request the purchase of services provided by the diagnostic application, the network location identifier indicating the access location of the diagnostic device in the network; determining at least one recommended payment option corresponding to the access location based on the network location identifier; and displaying at least one recommended payment option in the diagnostic application interface. This improves payment efficiency and success rate, enabling users to quickly obtain the services they need.

Description

Technical Field

[0001] This application belongs to the field of vehicle technology, and in particular relates to a payment recommendation method, device, equipment, and medium. Background Technology

[0002] In the field of modern automotive repair, technicians often use diagnostic equipment equipped with intelligent operating systems. These devices have built-in diagnostic applications that provide various functions such as vehicle fault detection and data stream reading.

[0003] Some advanced features or ongoing services (such as vehicle software downloads, feature unlocking, and annual fee renewals) require users to pay online before they can use them.

[0004] However, in practice, users need to choose one of several payment methods. Because the success rates of different payment methods vary in different scenarios, the randomly selected payment method may sometimes fail, leading to low payment efficiency, preventing users from receiving the services they need in a timely manner, and impacting user experience. Summary of the Invention

[0005] This application provides a payment recommendation method, apparatus, device, and medium, which improves payment efficiency and enables users to quickly obtain the services they need.

[0006] In a first aspect, embodiments of this application provide a payment recommendation method applied to diagnostic devices, the method comprising: Displays the diagnostic application interface of the diagnostic application; In response to a payment request operation, obtain the network location identifier of the diagnostic device; the payment request operation is used to request the purchase of services provided by the diagnostic application, and the network location identifier is used to indicate the access location of the diagnostic device in the network; Determine at least one recommended payment option corresponding to the access location based on the network location identifier; Display at least one recommended payment option in the diagnostic application interface.

[0007] The beneficial effects of the first aspect are as follows: First, the diagnostic application interface is displayed. When a user initiates a payment request, the network location identifier of the diagnostic device is obtained. This identifier reflects the device's current network access location. Since the success rates of payment infrastructure and payment methods vary depending on the network access location, this solution automatically determines at least one recommended payment option based on the network location identifier and displays it directly on the interface. Users do not need to guess or try randomly; the system has already provided a payment method with a high success rate based on the user's actual location. This significantly reduces the number of payment failures caused by improper selection, avoids the time wastage and operational burden caused by repeated attempts, and greatly improves the success rate of the first payment. Users can quickly obtain the diagnostic services they need. At the same time, by reducing invalid payment attempts and repeated payment page loading, the number of communications between the diagnostic device and the payment gateway is also reduced, saving network bandwidth and device power. Overall, this improves payment efficiency, the intelligence level of the diagnostic device, and the user's experience.

[0008] In one implementation, determining at least one recommended payment option corresponding to the access location based on the network location identifier includes: Based on the network location identifier, determine the current location of the diagnostic equipment; The system queries the local geolocation database of the diagnostic device based on the device's region. This database includes various payment options corresponding to different device regions, as well as the recommended priority of each payment option. Among multiple payment options that match the device's region, the n policy options with the highest recommendation priority are identified as at least one recommended payment option, where n is a positive integer.

[0009] In this implementation, the device's current location is first determined based on its network location identifier. Then, a local database of pre-stored geographic locations is used to query various payment options and their recommended priorities for that region. Finally, the n highest-priority options are selected as the recommendations. This local database approach allows for rapid querying and recommendations even in environments with no or weak network connectivity, eliminating the need to wait for cloud responses. Furthermore, recommendation priorities can be pre-configured based on historical payment statistics for each region, ensuring higher success rates for high-priority options locally. This approach improves response speed and offline availability while maintaining recommendation accuracy.

[0010] In one implementation, determining at least one recommended payment option corresponding to the access location based on the network location identifier includes: Based on the network location identifier, determine the current location of the diagnostic equipment; Determine at least one payment method permitted in the device region and the historical success rate of each payment method in the device region; The k payment methods with the highest historical success rates are identified as at least one recommended payment option, where k is a positive integer.

[0011] In this implementation, the allowed payment methods for the device's region are determined, and the historical success rate of each payment method in that region is calculated. The k payment methods with the highest historical success rates are then selected as recommended options. Historical success rates reflect real-time changes in the availability of payment channels (e.g., if a payment method has recently experienced frequent failures, its success rate will automatically decrease). The recommended results adaptively adjust based on actual payment conditions, consistently recommending the most likely successful payment method to the user, thus maintaining a consistently high payment success rate and avoiding recommending outdated methods due to static configuration lag.

[0012] In one implementation, at least one recommended payment option includes a credential payment option, which is a payment option that uses a pre-acquired digital credential to complete the payment, and the digital credential corresponds to a verification card key; The method also includes: In response to the selection of a payment option, the card input area is displayed; Obtain the card key entered by the user in the card key input area, and verify the digital credential based on the card key; If the verification is successful, a payment success message will be displayed, and a service entry point corresponding to the payment request operation will be provided.

[0013] In this implementation, the voucher payment option utilizes a pre-acquired digital voucher (corresponding to a verification card key) to complete the payment. When the user selects this option, a card key input area is displayed, the user's input card key is retrieved and verified, and upon successful verification, a payment success message is displayed, along with a service entry point. The key feature of voucher payment is the separation of purchase and use; digital vouchers can be obtained in advance through offline cash, gifts from friends and family, etc., completely independent of online real-time payment channels. Therefore, for regions where conventional online payments frequently fail, voucher payment provides a highly reliable alternative path. Users only need to enter the card key to complete the payment; the operation is simple and has a high success rate.

[0014] In one implementation, at least one recommended payment option also includes an online payment option; The method also includes: Receive the user's selection of online payment options and trigger the online payment process; In response to an online payment operation that fails, a prompt message is displayed to guide the user to select the voucher payment option to complete the payment.

[0015] In this implementation, recommended payment options also include online payment. When a user chooses online payment but the payment fails, the system displays a prompt message guiding the user to choose the voucher payment option. This design forms a complete safety net: the user first tries the convenient online payment method; if it fails due to unavailable payment channels or account issues, the system proactively suggests alternative solutions. This retains the convenience of online payment while providing a clear alternative path for failures, reducing user confusion and repeated attempts due to payment failures, and improving the robustness and completion rate of the payment process.

[0016] In one implementation, the displayed prompt information includes an online purchase portal and offline purchase address information. The offline purchase address information includes multiple digital voucher purchase addresses sorted by distance and their corresponding contact information. The method also includes: In response to the triggering of the online purchase portal, the user is redirected to the interface for purchasing digital vouchers online. The servers used for purchasing digital vouchers online are independent of the servers used for online payment options.

[0017] In this implementation, when a user is guided to pay using a credential but does not yet possess a valid digital credential, the solution further provides an online purchase portal and offline purchase address information (sorted by distance and including contact information) in the prompt message. The online purchase portal redirects to a purchase interface independent of the original online payment server. This server uses a backup payment channel, ensuring that the transaction may still be successfully completed even if the original online payment server becomes completely unavailable. By combining online and offline methods and deploying the server independently, this approach maximizes the guarantee that users can obtain valid digital credentials, significantly improving the system's fault tolerance and availability, making it particularly suitable for regions with underdeveloped payment infrastructure.

[0018] In one implementation, the diagnostic application interface also includes an online commitment code generation entry point, and the method further includes: In response to the triggered operation of the online commitment code generation portal, a commitment code is generated, which is used to obtain digital credentials from a third-party service provider; Send the commitment code to the third-party service provider; If a confirmation message is received from a third-party service provider within a preset time after the commitment code is sent, a payment success message will be displayed, and a service entry point corresponding to the payment request operation will be provided.

[0019] In this implementation, an online commitment code generation portal is provided within the diagnostic application interface. After the user triggers this portal, the system generates a one-time commitment code, which the user then sends to a third-party service provider (such as a distributor). Upon confirmation by the third party, the system immediately provides the corresponding service entry point. This approach implements a "activate first, pay later" model, particularly suitable for payment scenarios between users and service providers with long-term partnerships. Users can obtain services without immediate payment or holding digital vouchers, and subsequently repay funds through offline transfers or other methods. The entire process is completed online, offering ease of use. It solves the problem of users facing temporary financial difficulties or payment channel disruptions, while also protecting the rights of service providers through preset durations and confirmation mechanisms, achieving a balance between convenience and security.

[0020] Secondly, embodiments of this application provide a payment recommendation device, comprising: The display module is used to display the diagnostic application interface of the diagnostic application. The processing module is used to obtain the network location identifier of the diagnostic device in response to a payment request operation; the payment request operation is used to request the purchase of services provided by the diagnostic application, and the network location identifier is used to indicate the access location of the diagnostic device in the network; The processing module is also used to determine at least one recommended payment option corresponding to the access location based on the network location identifier; The display module is also used to display at least one recommended payment option in the diagnostic application interface.

[0021] Thirdly, this application also provides an electronic device. The electronic device includes a memory, one or more processors, and a computer program stored in the memory and executable on the processor. The electronic device executes the computer program to implement any of the implementations of the first aspect described above.

[0022] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the method of any of the implementations of the first aspect described above.

[0023] Fifthly, this application also provides a computer program product that, when run on an electronic device, causes the electronic device to execute any of the implementation methods of the first aspect described above.

[0024] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect above, and will not be repeated here. Attached Figure Description

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

[0026] Figure 1 This is a schematic diagram of the architecture of a payment recommendation system provided in one embodiment of this application; Figure 2 This is a flowchart of a payment recommendation method provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating a recommended option provided in one embodiment of this application; Figure 4 This is a structural block diagram of a payment recommendation device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0027] In the modern automotive repair field, users widely utilize diagnostic equipment equipped with intelligent operating systems. This equipment runs dedicated diagnostic applications that provide various testing and repair functions, such as vehicle fault code reading and data stream analysis. In some cases, certain advanced functions or ongoing services within the diagnostic applications (such as downloading software packages for specific vehicle models, unlocking functional modules, and renewing annual service fees) require online payment before they can be used normally.

[0028] In practice, users typically need to choose one of the various online payment methods offered by the diagnostic equipment to make a payment.

[0029] However, the payment ecosystem varies significantly across different countries and regions. For example, QR code payments are widespread in some areas, while e-wallets or bank card payments dominate in others. In some financially restricted regions, some payment channels are even completely unavailable. Faced with these differences, users often lack clear guidance on payment methods and can only rely on personal experience or random experimentation to make their choices.

[0030] Because the success rate of different payment methods varies across regions and scenarios, this untargeted, random selection easily leads to payment failures. Once a payment fails, users cannot obtain the necessary diagnostic software or services in a timely manner, requiring them to switch payment methods to complete the transaction. This results in low human-computer interaction efficiency, not only extending repair waiting times but also significantly reducing overall work efficiency and severely impacting the user experience. Therefore, how to automatically recommend suitable payment methods to users based on the payment channel characteristics of the diagnostic equipment's location has become an urgent technical problem to be solved.

[0031] Based on this, this application provides a payment recommendation method that can provide online payment recommendations for purchasing services for diagnostic applications of diagnostic equipment, recommending payment options with a high success rate for users to choose from.

[0032] First, the diagnostic device displays the diagnostic application interface. When a user initiates a payment request to purchase diagnostic application services, the device automatically obtains its network location identifier, which reflects the device's current network access location. Since the success rates of payment infrastructure and payment methods vary across different network access locations, the device determines at least one recommended payment option based on this network location identifier and displays it directly on the interface, thus preventing users from making blind choices.

[0033] In one embodiment, the location of the diagnostic device can be determined based on the network location identifier. Then, the various payment options and their recommendation priorities corresponding to that region can be queried from the locally stored geolocation database. The options with the highest priority are recommended to the user. The geolocation database stores the payment options recommended for each region and the priority of each payment option. This maps the process of recommending payment methods to a table lookup index process, which greatly improves the efficiency of online recommendation. This allows the diagnostic device to generate recommended options without performing a lot of calculations, reducing the computational burden on the diagnostic device and saving recommendation time.

[0034] In another embodiment, the historical success rates of various payment methods in the current location of the diagnostic device can be statistically analyzed, and the options with the highest success rates can be used as recommendations.

[0035] Typically, the payment recommendations provided by the diagnostic device may include at least one online payment option. However, for regions where payment channels are restricted or temporarily unavailable, the payment recommendations provided by the diagnostic device may not include online payment options.

[0036] Therefore, to further improve payment reliability, a voucher payment option is included in the recommended options regardless of the location of the diagnostic device. This option uses a pre-obtained digital voucher (corresponding to a verification card key) to complete the payment. This method separates purchase from use and does not rely on real-time online payment channels, making it particularly suitable for scenarios where regular online payments are prone to failure.

[0037] If the user's chosen online payment fails, the system will proactively prompt and guide them to use a voucher for payment. The prompt message also provides an online purchase portal (which uses a backup channel independent of the original online payment server) and offline purchase addresses sorted by distance, making it convenient for users to obtain digital vouchers in a timely manner.

[0038] Once a user obtains a digital credential, they can initiate the payment process using the digital credential by triggering the credential payment option: the user only needs to enter the credential's key, and the diagnostic device will verify the key to determine whether the current digital credential meets the payment conditions and provide the corresponding payment result.

[0039] For a special situation where a user's online payment fails and they do not currently possess any valid digital credentials, the system also provides an online commitment code generation portal. The user can trigger this portal to generate a commitment code and send it to a third-party service provider (such as a distributor). Once the third party confirms the code, the system can activate the required services for the user, who can then complete the settlement with the third-party service provider subsequently.

[0040] By employing location-aware recommendations, multi-level alternative payment options (online payment + voucher payment), online and offline voucher acquisition integration, independent server backup channels, and commitment code payment mechanisms, this solution fundamentally solves the problem of payment failures caused by users randomly selecting payment methods due to a lack of guidance. It significantly improves the first-time payment success rate, shortens service acquisition time, reduces the user's operational burden, and enhances the adaptability and robustness of diagnostic equipment in complex payment environments (such as cross-border transactions, limited payment channels, and network restrictions), comprehensively improving the user experience and the intelligence level of diagnostic equipment.

[0041] Figure 1 This is a schematic diagram of the architecture of a payment recommendation system provided in an embodiment of this application. The system 100 includes a first server cluster 110, a second server 120, and a diagnostic device 130.

[0042] The first server cluster 110 is a server cluster corresponding to multiple online payment channels (i.e., multiple online payment options). Each online payment channel (e.g., QR code payment, e-wallet payment, bank card payment, etc.) can correspond to one or more servers in the cluster to process online payment requests for real-time fund transfers.

[0043] The second server 120 is the server corresponding to the digital credentials (i.e., the pre-acquired payment credentials upon which the credential payment option relies). Independent of the first server cluster 110, the second server 120 is dedicated to handling the verification, activation, and online purchase of digital credentials. Digital credentials can serve as an independent payment method or as a backup payment method after all other online payment methods fail, ensuring that users can still complete payments even when regular payment channels are unavailable. The second server 120 also provides an interface for online purchase of digital credentials, allowing users to purchase them even if they do not currently possess them, thus avoiding payment failures due to malfunctions or channel limitations in the first server cluster 110.

[0044] Diagnostic device 130 is a user-operated local device equipped with a diagnostic application that displays a diagnostic application interface for user interaction. Diagnostic device 130 also performs tasks such as acquiring network location identifiers, displaying recommended payment options, receiving user input, and communicating with the first server cluster 110 and the second server 120.

[0045] The following describes in detail the interactive process of payment recommendation, taking into account the diagnostic device 130, the first server cluster 110, the second server 120, and the user's operations.

[0046] Step 1: The diagnostic device displays the diagnostic application interface, and the user triggers a payment request based on the diagnostic application interface.

[0047] The diagnostic device 130 starts up and displays the diagnostic application interface. The interface provides various service entry points, such as "Purchase Vehicle Package," "Unlock Function Modules," and "Renew Annual Fee." The user clicks on a service entry point to initiate a payment request, which is used to purchase the services provided by the diagnostic application.

[0048] Step 2: The diagnostic device obtains the network location identifier and determines the recommended payment option.

[0049] In response to a payment request, diagnostic device 130 automatically obtains its own network location identifier, such as a public IP (Internet Protocol) address, and sends the network location identifier to the cloud or processes it locally (this embodiment uses local processing as an example). Based on the network location identifier, the diagnostic device determines its current device location (such as country or region), then queries a pre-stored local geolocation database to obtain multiple payment options matching that region and their recommendation priorities, selecting one or more options with the highest priority as recommended payment options. Alternatively, it can statistically analyze the historical success rates of various payment methods in that region and select the option with the highest success rate as the recommendation result.

[0050] Step 3: The diagnostic device displays recommended payment options.

[0051] The diagnostic device 130 displays a list of recommended payment options in its diagnostic application interface. For example, for China, "QR code payment" and "voucher payment" are recommended; for regions subject to financial sanctions, "voucher payment" is recommended as the only or preferred option. The interface also provides an "Other Payment Methods" entry, allowing users to manually select non-recommended options. These non-recommended options are not unusable, but rather payment options with a lower success rate compared to the recommended options. These payment options have successful payment cases in various regions around the world.

[0052] Step 4: The user selects a payment method from the recommended payment options and performs the payment operation.

[0053] The user selects a payment option from the recommended options, and the diagnostic device executes different branches depending on the option type.

[0054] Branch A: The user selects the online payment option.

[0055] Online payment options include various types, such as QR code payment, e-wallet payment, and bank card payment. The user selects one option, and the diagnostic device 130 calls the corresponding payment interface in the first server cluster 110 to initiate the online payment operation.

[0056] If the payment is successful, the first server cluster returns a success result, the diagnostic device displays the payment success information, and unlocks the corresponding service entry, allowing the user to use the purchased functions.

[0057] If payment fails (e.g., due to unavailable payment channels, insufficient account balance, network timeout, etc.), the diagnostic device displays a prompt message, guiding the user to select the voucher payment option as an alternative.

[0058] Branch B: Users directly select the voucher payment option.

[0059] The diagnostic device 130 displays the card key input area, prompting the user to enter the verification card key corresponding to the digital certificate.

[0060] After the user enters the card PIN, the diagnostic device sends the PIN to the second server 120 for verification.

[0061] The second server verifies the validity of the card key (whether it is unused, within the validity period, and has sufficient balance, etc.).

[0062] If the verification is successful, the second server returns a success result, the diagnostic device displays payment success information, and provides the corresponding service entry point.

[0063] If verification fails (e.g., incorrect card number, expired, insufficient balance), the diagnostic device displays a failure message and guides the user to re-enter the code or obtain a valid digital credential through other means.

[0064] Step 5: Diagnostic procedures for handling online payment failures when the user lacks digital credentials.

[0065] When a user fails to make an online payment via branch A and does not currently possess a valid digital credential, the diagnostic device provides the following further interactive entry points in the prompt message.

[0066] 1. Online Purchase Portal: After clicking, the user is redirected to the online digital certificate purchase interface provided by the second server 120. The payment channel used by this purchase interface is independent of that of the first server cluster 110 (e.g., supporting cryptocurrency payments, local purchasing platform payments, etc.). Therefore, even if the first server cluster is completely unavailable, the user may still successfully purchase the digital certificate through the backup channel of the second server. After a successful purchase, the second server automatically binds the digital certificate to the current diagnostic device or returns the card key, which the user can use without having to enter it again.

[0067] 2. Offline Purchase Address Information: The diagnostic device obtains its current location, queries the locally stored dealer database, and displays multiple digital voucher purchase addresses and corresponding contact information, sorted by distance from nearest to farthest. Users can go to the nearest store to purchase physical digital vouchers using cash or local payment methods.

[0068] Step 6: The diagnostic equipment generates a commitment code online.

[0069] For a special situation where a user's online payment fails and they currently lack a valid digital credential and cannot immediately purchase the device online or offline (e.g., due to network interruption, distance from the store, or insufficient funds), the diagnostic device provides an "Online Commitment Code Generation Entry" within its diagnostic application interface. After the user triggers this entry, the diagnostic device generates a one-time commitment code (e.g., a string of numbers or a QR code). The user then sends this commitment code to a third-party service provider (such as a familiar distributor or agent) via SMS, instant messaging, or other means. The third-party service provider logs into the system using their own terminal, enters the commitment code, and confirms "agree to provide digital credentials." Subsequently, the second server 120 receives the confirmation instruction and immediately activates the required services for the diagnostic device. Activation can be for the entire service period (e.g., one year if the service period is one year) or temporary (e.g., only 7 days).

[0070] Users can then settle payments with third-party service providers via online transfers or offline cash payments. This method enables a flexible "use now, settle later" payment model, which is particularly suitable for payment scenarios between repair shops and dealers with long-term cooperative relationships.

[0071] Through the aforementioned system architecture and interaction process, the payment recommendation method provided in this application can automatically recommend payment methods with high success rates to users based on the characteristics of payment channels in the region where the diagnostic device is located, avoiding situations where users randomly select payment methods, resulting in low payment success rates and low payment efficiency. Simultaneously, by setting up a digital credential server independent of the online payment server, providing multiple online and offline channels for obtaining credentials, and establishing a commitment code credit mechanism, a multi-level security system is formed, encompassing online payment to credential payment, and from immediate purchase to post-settlement. Even if conventional online payment is completely unavailable, users can still complete payments using digital credentials or commitment codes, significantly improving payment success rates and service acquisition efficiency, enhancing user experience, and strengthening the adaptability and robustness of diagnostic devices in complex payment environments.

[0072] Figure 2 This is a flowchart of a payment recommendation method provided in an embodiment of this application. The method is applied to a diagnostic device and includes the following steps.

[0073] Step 210: Display the diagnostic application interface of the diagnostic application.

[0074] The diagnostic equipment is equipped with and runs a corresponding diagnostic application. This application is the core software component of the diagnostic equipment, providing various vehicle detection and repair functions such as vehicle fault code reading, data stream analysis, and remote assistance.

[0075] The diagnostic application interface is a graphical window through which the diagnostic application interacts with the user. It includes multiple function entry controls, such as those for "Fault Scan," "Data Stream," "Action Test," "Software Upgrade," "Function Unlock," and "Annual Fee Renewal." Some of these services require user purchase or renewal to access, such as "Software Upgrade," "Function Unlock," and "Annual Fee Renewal."

[0076] Users can initiate corresponding operation requests, call the corresponding service, or enter the payment process by triggering these controls through the touch screen or buttons provided by the diagnostic device, and then call the service after the payment is completed.

[0077] Step 220: In response to the payment request operation, obtain the network location identifier of the diagnostic device.

[0078] The payment request operation is used to request the purchase of services provided by the diagnostic application.

[0079] When a user triggers the aforementioned paid service entry control (such as "Purchase vehicle package"), a payment request is initiated. In response to this action, the diagnostic device automatically obtains its own network location identifier.

[0080] A network location identifier is used to indicate the access location of a diagnostic device within a network. A network location identifier includes, but is not limited to, at least one of the following: 1. Public IP (Internet Protocol) address: A unique digital identifier assigned by the network operator when a diagnostic device connects to the Internet via Wi-Fi or Ethernet.

[0081] 2. Mobile network base station identifier: If the diagnostic device has a built-in cellular communication module (such as 4G / 5G), it can read the cell ID of the currently connected base station.

[0082] 3. WiFi hotspot BSSID (Basic Service Set Identifier): This is the MAC address (Media Access Control Address) of the wireless router.

[0083] Step 230: Determine at least one recommended payment option corresponding to the access location based on the network location identifier.

[0084] In this embodiment, at least one of the recommended payment options includes a voucher payment option, which refers to a payment option that uses a pre-acquired digital voucher to complete the payment. The digital voucher corresponds to a verification card key, such as a 16-digit alphanumeric string. After purchasing a digital voucher (which can be purchased offline with cash, given by others, or purchased through an online backup channel, etc.), the user can activate the service by entering the card key on the diagnostic device, without relying on a real-time cross-border fund clearing channel.

[0085] In addition to the payment option based on credentials, some embodiments include at least one online payment option among the recommended payment options. The types of online payment options include, but are not limited to, QR code payment, e-wallet payment, and bank card payment. In actual recommendation, the online payment option recommended to the user may include at least one of the online payment options exemplified above. Online payment options require real-time invocation of the payment interface to complete the fund transfer, relying on the support of local payment infrastructure and financial channels.

[0086] In other words, regardless of the location of the diagnostic device, the recommended payment options include a voucher payment option to ensure that users still have a reliable alternative when online payment is unavailable.

[0087] This embodiment provides several optional methods for determining the recommended payment option. One method is a static priority lookup method based on a locally pre-stored geolocation database (Method 1), and the other is a dynamic calculation method based on historical success rates (Method 2). The two methods are described below.

[0088] Method 1: Static priority lookup table method based on locally pre-stored geographic location database Optionally, the device region where the diagnostic device is currently located is determined based on the network location identifier; a query is performed from the local geolocation database of the diagnostic device based on the device region, wherein the geolocation database includes multiple payment options corresponding to different device regions and the recommendation priority of each payment option; the n system options with the highest recommendation priority among the multiple payment options matching the device region are determined as at least one recommended payment option, where n is a positive integer.

[0089] When determining the device's region based on network location identifiers, the diagnostic device can use at least one of the aforementioned three types of information for location.

[0090] 1. Using a public IP address, quickly match the device to a country-level location through a locally stored IP range-country mapping table. For example, if the obtained IP is 185.102.33.44, querying the mapping table shows that this IP belongs to Russia, thus determining that the device's region is Russia.

[0091] 2. By utilizing mobile network base station identifiers, the device's country or region can be located by reading the currently connected base station number (Cell ID) and combining it with a locally stored base station location database (which contains the correspondence between base station numbers and geographical locations). For example, if the MCC (Mobile Country Code) is 460, it can be confirmed that the device is located in China; if the LAC (Location Area Code) and Cell ID are further obtained, the location can be pinpointed to the city or district / county.

[0092] 3. By utilizing the BSSID of WiFi hotspots, scanning the BSSIDs of surrounding WiFi hotspots and matching them with a locally stored WiFi location database (which records the correspondence between BSSIDs and latitude / longitude or addresses), the device's location can be determined. For example, if the BSSID 00:1A:2B:3C:4D:5E is scanned and matched with the local WiFi location database, the corresponding geographical location is "Shenzhen Nanshan Science and Technology Park," thus confirming that the device is located in that area.

[0093] To improve accuracy, diagnostic equipment can cross-verify multiple identifiers: when the public IP address is located in the United States, but the system language is Russian and the time zone is Moscow time, it is determined that an accelerator may have been used. In this case, the location result of the mobile network base station identifier or BSSID shall be given priority.

[0094] It is worth noting that the term "device region" in this embodiment has two levels of definition: a broad one and a narrow one. The broad level is divided according to country or geographical region, such as "China," "United States," and "Russia," which directly correspond to the traditional IP geographic location database. The narrow level is divided according to the availability of payment channels and the characteristics of payment infrastructure, such as "QR code payment dominant area," "e-wallet payment dominant area," "bank card payment dominant area," and "financial payment channel restricted area."

[0095] In the embodiment of Method 1, taking the narrow division of financial payment channels as an example, four device region types are predefined: Type A (Regions Dominated by QR Code Payment): Such as China, where QR code payment has a high penetration rate, with e-wallets and bank cards serving as supplementary methods. QR code payment refers to an online payment method that uses a QR code as the information carrier. Payment institutions generate QR code images containing transaction elements, and users scan these images with their mobile devices or are recognized by image scanning devices to complete the fund transfer. In the active scanning mode, the user scans the QR code displayed by the merchant; in the passive scanning mode, the merchant scans the QR code displayed by the user. QR code payment relies on payment applications, which complete the information exchange by accessing the camera or generating a QR code.

[0096] Type B (Regions Dominated by E-Wallet Payments): Regions where e-wallets are widely used, such as the United States, Canada, the United Kingdom, Germany, and France. An e-wallet is an internet-based virtual account system where users pre-link bank cards or top up their accounts, completing payments through account-to-account transfers without needing to enter sensitive information such as card numbers and expiration dates each time. E-wallet payments typically rely on email addresses or mobile phone numbers as account identifiers.

[0097] Type C (Regions with Restricted Financial Payment Channels): Regions such as Iran and North Korea have restricted financial channels or are subject to related control policies, making conventional cross-border payment channels (credit cards, e-wallets) cut off or extremely unavailable. In these regions, server connections for the aforementioned online payment methods are blocked or transactions are rejected.

[0098] Type D (General Bank Card Regions): For countries and regions other than those listed above, credit card / debit card payments are the primary method, with payment via voucher as an alternative. Bank card payments complete transactions by entering card-related verification information, relying on the card organization network and the issuing bank's authorization system.

[0099] The diagnostic equipment categorizes the current device into one of the four types mentioned above based on the country / region information and auxiliary information obtained from the network location identifier mapping (such as whether the country has restricted financial payment channels).

[0100] After determining the device's region type, the diagnostic device queries the locally stored geolocation database using that type as the key. This database can be a key-value pair data structure; for example, the geolocation database is shown in Table 1 below.

[0101] Table 1

[0102] For example, assuming the current device's region type is determined to be Type C (restricted financial payment channels), the highest-priority recommended payment option for this type in the geolocation database is voucher payment. If n=2, the first two options are taken, but since Type C only has one voucher payment option, the recommended options only include voucher payment. If the current device's region type is Type A, and n=2, the first two highest-priority recommended options are: QR code payment and voucher payment.

[0103] Method 1 transforms complex recommendation decisions into simple in-memory indexing operations, which require minimal computation, typically have a response time in the milliseconds, and are completely independent of real-time networks.

[0104] Indicative, such as Figure 3 As shown, Figure 3 This is a diagram showing the recommended options corresponding to Table 1.

[0105] When online payment options (QR code payment, e-wallet payment, bank card payment) fail, you can choose the voucher payment option as a backup plan.

[0106] Method 2: Dynamic calculation method based on historical success rate Optionally, based on the network location identifier, determine the current device region where the diagnostic device is located; determine at least one payment method allowed in the device region and the historical success rate of each payment method in the device region; The k payment methods with the highest historical success rates are identified as at least one recommended payment option, where k is a positive integer.

[0107] For example, unlike Method 1, Method 2 uses a broad definition of "device region" (e.g., "China," "Russia," "United States," etc.) rather than a narrow definition based on financial payment channels. The specific technical details for determining the device region have been described in detail in Method 1 (using any one of the following information—public IP address, mobile network base station identifier, or WiFi hotspot BSSID—for location or cross-validation based on multiple pieces of information), and will not be repeated here.

[0108] After determining the device's region, the diagnostic device needs to obtain at least one payment method allowed in that region (e.g., read from a locally stored "Region-Available Payment Method List") and calculate the "historical success rate" for each payment method in that region. The historical success rate is calculated in real time, with the current time as the cutoff point. Data from a pre-defined historical period before the cutoff time is used as the data period for calculating the historical success rate.

[0109] The data sources include at least one of the following, and all of this data is obtained from public platforms or with user authorization: The primary data source (local order data) consists of payment order records for diagnostic application services previously initiated by the diagnostic device in the region, stored locally on the device. This includes the payment method used for each payment and the success / failure result. This data reflects individual users' payment habits and recent experiences.

[0110] The second data source (cloud-aggregated data): This is the big data of all payment orders for all diagnostic devices in the region, collected by the cloud server corresponding to the diagnostic device. The diagnostic device can periodically synchronize with the network or query in real time. This data reflects the overall availability of macro-payment channels and is particularly useful when local data is insufficient.

[0111] The third data source (regional general data): Payment success rate data for all online transactions in the region, obtained from public platforms or third-party statistical agencies. Examples include annual electronic payment reports for various countries published by a statistical website, and rankings of payment channel success rates published by cross-border e-commerce platforms. This data reflects the general state of the overall payment ecosystem in the region, and is not limited to diagnostic equipment purchase scenarios. It can serve as a global benchmark, especially applicable to new regions where local diagnostic equipment data is sparse or cloud data has not yet been accumulated.

[0112] For each payment method, the diagnostic device can perform a weighted calculation based on the success rate of each payment method across different data sources to obtain the overall historical success rate of that payment method. An exemplary weighted calculation formula is: Historical Success Rate = α × Local Success Rate + β × Cloud Success Rate + γ × Regional General Success Rate, where α, β, and γ are weighting coefficients, and α + β + γ = 1. Each weighting coefficient can be dynamically adjusted according to the reliability and timeliness of the data source. For example, when the number of local payment records exceeds a threshold (e.g., 10 records), α = 0.5, β = 0.3, and γ = 0.2 can be set; when local data is scarce but cloud data is abundant, α = 0, β = 0.7, and γ = 0.3 can be set; when the device is completely unable to connect to the network, only local data can be used (α = 1, β = 0, γ = 0). The regional general success rate, as a priori probability, can play an important role when the device is used for the first time or when cloud data is lacking.

[0113] The diagnostic device uses the current moment as the statistical cutoff point, obtains data sources from historical time periods, identifies the various payment methods involved, and calculates the comprehensive historical success rate of each payment method within the historical time period in real time. Then, it sorts the payment methods in descending order of success rate and determines the k payment methods with the highest success rate (k is a positive integer, such as k=2 or k=3) as at least one recommended payment option.

[0114] For example, suppose the current device is located in region A, and region A allows payment methods including e-wallet payment, bank card payment, and credential payment.

[0115] The diagnostic equipment read from local records: e-wallet payment attempts: 1 successful out of 5 attempts (20% success rate); bank card payment attempts: 0 successful out of 2 attempts (0% success rate); voucher payment attempts: 3 successful out of 3 attempts (100% success rate). Global data retrieved from the cloud: e-wallet payment success rate: 10%; bank card payment success rate: 5%; voucher payment success rate: 95%. Regionally applicable data retrieved from publicly available statistical websites: e-wallet payment success rate: 15%; bank card payment success rate: 8%; voucher payment success rate: 90%.

[0116] With weights α=0.3, β=0.4, and γ=0.3, the historical success rate is calculated as follows: E-wallet payment = 0.3 × 20% + 0.4 × 10% + 0.3 × 15% = 6% + 4% + 4.5% = 14.5%; Bank card payment = 0.3 × 0% + 0.4 × 5% + 0.3 × 8% = 0% + 2% + 2.4% = 4.4%; Voucher payment = 0.3 × 100% + 0.4 × 95% + 0.3 × 90% = 30% + 38% + 27% = 95%. After sorting, voucher payment has the highest success rate. If k=1, only voucher payment is recommended; if k=2, both voucher payment and e-wallet payment are recommended, and the recommendation order is determined according to the historical success rate.

[0117] Method Two does not rely on a predefined static priority table, but rather dynamically calculates based on actual payment results. This allows it to reflect changes in payment channel availability in real time (e.g., a sudden restriction on payment channels in a certain region causing a sharp drop in e-wallet success rates), enabling the recommendation strategy to adapt to the current payment situation in the region. Simultaneously, by weightedly fusing local, cloud, and publicly available regional data, it takes into account individual differences, global statistics, and the general ecosystem, improving the accuracy and robustness of the recommendations.

[0118] In some embodiments, instead of directly obtaining the network location identifier of the diagnostic device, other geographic indication information associated with the payment request operation may be obtained to determine the recommended payment option.

[0119] For example, it is possible to obtain the registered region or regional information of the user account logged into the diagnostic device, the user's manually set preferred region information, or the geographic tag information implicit in the user's historical payment orders. The above information can be hashed or processed by feature mapping to generate a standardized geographic identifier, which is used to indicate the geographic region where the user is located or belongs.

[0120] For example, in response to a payment request operation, geographic indication information associated with the payment request operation is obtained; at least one recommended payment option corresponding to the geographic indication information is determined based on the geographic indication information. The geographic indication information includes at least one of the following: the user's registered region, a region manually selected by the user, a high-frequency region statistically derived from the user's historical successful payment records (referring to regions that have reached a preset number of successful payments), or the region where the service outlet bound to the diagnostic device is located. In this way, even if the diagnostic device cannot obtain a network location identifier (e.g., the device is not connected to the network but the user has logged into the account), geographic-based payment recommendations can still be achieved, expanding the applicability of the method. Accordingly, steps 220 to 230 can be implemented as: in response to a payment request operation, obtaining geographic indication information associated with the payment request operation; determining at least one recommended payment option based on the geographic indication information.

[0121] Step 240: Display at least one recommended payment option in the diagnostic application interface.

[0122] After identifying at least one recommended payment option, the diagnostic device displays these options in the diagnostic application interface as a list, button, or other visual format. Users can then select any payment option based on the on-screen prompts to proceed with the corresponding payment process. The interaction flow for each payment option is explained below.

[0123] Optionally, in response to the selection of a payment option, the system displays a card PIN input area; retrieves the card PIN entered by the user in the input area; and verifies the digital credential based on the card PIN. If verification is successful, a payment success message is displayed, and a service entry point corresponding to the payment request is provided. If verification fails, a failure message is displayed.

[0124] When a user selects the voucher payment option, the diagnostic device displays a card PIN input area (e.g., a text input box and a confirmation button). The user enters the verification PIN corresponding to the pre-acquired digital voucher (e.g., a 16-character alphanumeric string) in this area. The diagnostic device retrieves the entered PIN and sends it to a separate digital voucher verification server (i.e., the aforementioned second server) for verification. Verification includes checking if the PIN exists, if it is valid, and if it has already been used.

[0125] If the verification is successful, the server returns a success result, the diagnostic device displays payment success information, and automatically provides the service entry corresponding to the payment request operation (such as unlocking the "vehicle software download" function or extending the annual fee validity period).

[0126] If verification fails (e.g., incorrect card, expired, insufficient balance), the diagnostic device displays a failure message and provides guidance options such as "re-enter" or "obtain valid digital credentials," for example, redirecting to the online purchase portal or displaying the address of a nearby dealer.

[0127] Optionally, the system receives a selection of an online payment option, triggering an online payment operation; in response to the online payment operation and if the online payment operation fails, a prompt message is displayed to guide the user to select a voucher payment option for payment.

[0128] When a user selects an online payment option (such as QR code payment, e-wallet payment, bank card payment, etc.), the diagnostic device calls the corresponding payment interface in the first server cluster to initiate the online payment operation. If the online payment is successful, a payment success message is displayed directly, and the corresponding service is unlocked. If the online payment fails (e.g., due to unavailable payment channels, insufficient account balance, network timeout, or financial sanctions imposed on the region), the diagnostic device displays a prompt message to guide the user to select a voucher payment option.

[0129] In some embodiments, considering that the user may not yet have a valid digital certificate (i.e., has not purchased a digital certificate in advance), the diagnostic device may further provide online purchase access and offline purchase address information when displaying the prompt information to help the user conveniently obtain a digital certificate.

[0130] Optionally, the displayed prompt information includes an online purchase portal and offline purchase address information. The offline purchase address information includes multiple digital voucher purchase addresses sorted by distance and their corresponding contact information. In response to the triggering operation of the online purchase portal, the user is redirected to the online digital voucher purchase interface. The server used for online digital voucher purchase is independent of the server used for online payment options.

[0131] 1. Online Purchase Portal: Clicking this portal will redirect users to the online digital voucher purchase interface. This interface is provided by a separate server, and the server used for online digital voucher purchase is independent of the server used by the aforementioned online payment option. Even if the online payment server becomes completely unavailable due to failure or payment channel restrictions, the server used for online digital voucher purchase may still complete the transaction through an alternative payment channel (such as cryptocurrency, local purchasing platform, etc.), thereby ensuring that users can obtain digital vouchers.

[0132] 2. Offline Purchase Address Information: The diagnostic device obtains its current geographical location, prioritizing GPS (Global Positioning System). If not available, it determines the location based on network location identifiers and queries the locally stored dealer database. Multiple digital voucher purchase addresses are displayed, sorted by straight-line distance from nearest to farthest, along with corresponding contact information (such as store name, address, phone number, and business hours). Users can then visit the nearest store to purchase physical digital vouchers using cash or local payment methods.

[0133] It is worth noting that, in addition to online and offline purchases, digital vouchers can also be obtained through at least one of the following methods: (1) Obtain through redemption code: The redemption code is generated and distributed by the service provider or authorized distributor. Users can enter the code to redeem the corresponding service.

[0134] (2) Obtained through license: When a user pre-charges in an unrestricted payment environment (e.g., by purchasing points through WeChat Pay on the official website), the system generates an authorization code, which is a digital credential.

[0135] (3) Obtain through invitation code: Authorized users generate invitation codes and share them with other users. After the new user uses the invitation code, both parties can obtain service time.

[0136] (4) Obtaining through transfer code: After purchasing digital vouchers, the purchaser does not use them himself, but generates a transfer code and sends it to the recipient. The recipient enters the transfer code to obtain the service.

[0137] (5) Obtaining through resource exchange: Users exchange non-monetary resources (such as diagnostic equipment usage points, uploaded vehicle diagnostic data, remaining service time, etc.) for digital vouchers from service providers or third parties.

[0138] (6) Acquisition through commitment before payment: Users first prepay funds to a third-party service provider (such as a distributor) or make only a verbal / electronic commitment through offline or online means. The third-party service provider generates a temporary activation certificate for the user, and the user then repays the funds to the third party or completes the final payment.

[0139] For example, taking the above method (6) as an example, in some embodiments, the diagnostic application interface also includes an online commitment code generation entry.

[0140] In response to the triggering operation of the online commitment code generation entry, a commitment code is generated, which is used to obtain digital credentials from a third-party service provider; the commitment code is sent to the third-party service provider; if a confirmation message is received from the third-party service provider within a preset time after sending the commitment code, a payment success message is displayed, and a service entry corresponding to the payment request operation is provided.

[0141] For example, in response to a user's trigger action to generate an online commitment code, the diagnostic device generates a one-time commitment code (e.g., a 16-digit string). The diagnostic device sends this commitment code to the terminal device of a third-party service provider (such as a distributor). The third-party service provider enters the received commitment code into its terminal (e.g., the distributor's back-end management system) and triggers a confirmation command. Upon receiving the confirmation information within a preset timeframe (e.g., 48 hours) after sending the commitment code, the diagnostic device automatically displays a payment success message and temporarily activates the service entry corresponding to the payment request (e.g., unlocking a 7-day trial period). The user subsequently settles the payment with the third-party service provider via offline transfer, cash, etc., and the third-party service provider marks the receipt in its terminal, completing the closed loop.

[0142] In summary, the payment recommendation method provided in this application obtains the network location identifier of the diagnostic device when the user initiates a payment request by displaying the diagnostic application interface. This identifier reflects the device's current network access location. Since the success rates of payment infrastructure and payment methods vary objectively depending on the network access location, this solution automatically determines at least one recommended payment option that matches the network location identifier and displays it directly on the interface. Users do not need to guess or try randomly; the system has already provided a payment method with a high success rate based on the user's actual location. This significantly reduces the number of payment failures caused by improper selection, avoids the time wastage and operational burden caused by repeated attempts, and greatly improves the success rate of the first payment. Users can quickly obtain the diagnostic services they need. At the same time, by reducing invalid payment attempts and repeated payment page loading, the number of communications between the diagnostic device and the payment gateway is also reduced, saving network bandwidth and device power. Overall, this improves payment efficiency, the intelligence level of the diagnostic device, and the user's experience.

[0143] Corresponding to the payment recommendation method in the above embodiment, Figure 4 A structural block diagram of the payment recommendation device provided in the embodiments of this application is shown. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0144] Reference Figure 4 The device 400 includes: Display module 410 is used to display the diagnostic application interface of the diagnostic application. Processing module 420 is used to obtain the network location identifier of the diagnostic device in response to a payment request operation; the payment request operation is used to request the purchase of services provided by the diagnostic application, and the network location identifier is used to indicate the access location of the diagnostic device in the network; Processing module 420 is also used to determine at least one recommended payment option corresponding to the access location based on the network location identifier; Display module 410 is also used to display at least one recommended payment option in the diagnostic application interface.

[0145] It should be noted that the information interaction and execution process between the above-mentioned devices / modules 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.

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

[0147] To implement the above embodiments, this application also proposes an electronic device. Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application.

[0148] like Figure 5 As shown, the above-mentioned electronic device 500 includes: The system includes a memory 510 and at least one processor 520, and a bus 530 connecting the different components (including the memory 510 and the processor 520). The memory 510 stores a computer program, which implements the payment recommendation method of the present application embodiment when the processor 520 executes the program.

[0149] Bus 530 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0150] Electronic device 500 typically includes a variety of electronic device readable media. These media can be any available media that can be accessed by electronic device 500, including volatile and non-volatile media, removable and non-removable media.

[0151] Memory 510 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 540 and / or cache memory 550. Electronic device 500 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 560 can be used to read and write non-removable, non-volatile magnetic media (… Figure 5 Not shown; usually referred to as a "hard drive"). Although Figure 5 As not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 530 via one or more data media interfaces. Memory 510 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0152] A program / utility 580 having a set (at least one) of program modules 570 may be stored, for example, in memory 510. Such program modules 570 include—but are not limited to—an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 570 typically perform the functions and / or methods described in the embodiments of this application.

[0153] Electronic device 500 can also communicate with one or more external devices 590 (e.g., keyboard, pointing device, display 591, etc.), and with one or more devices that enable a user to interact with electronic device 500, and / or with any device that enables electronic device 500 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 595. Furthermore, electronic device 500 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 593. As shown, network adapter 593 communicates with other modules of electronic device 500 via bus 530. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 500, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0154] The processor 520 performs various functional applications and data processing by running programs stored in the memory 510.

[0155] It should be noted that the implementation process and technical principles of the electronic device in this embodiment are explained in the foregoing description of the payment recommendation method in this application embodiment, and will not be repeated here.

[0156] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps described in the various method embodiments above.

[0157] This application provides a computer program product that, when run on an electronic device, enables the electronic device to perform the steps described in the various method embodiments above.

[0158] 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. A computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographic device / electronic device, a recording medium, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some regions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

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

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

[0161] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic 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 devices or units may be electrical, mechanical, or other forms.

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

[0163] In the foregoing, specific details such as particular system architectures and techniques have been set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted to avoid unnecessary detail from obscuring the description of this application.

[0164] It should be understood that, when used in this application 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 a collection thereof.

[0165] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0166] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0167] Furthermore, in the description of this application 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.

[0168] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application 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.

[0169] The above 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 payment recommendation method, characterized in that, Applied to diagnostic devices, the method includes: Displays the diagnostic application interface of the diagnostic application; In response to a payment request operation, the network location identifier of the diagnostic device is obtained; the payment request operation is used to request the purchase of services provided by the diagnostic application, and the network location identifier is used to indicate the access location of the diagnostic device in the network. Based on the network location identifier, at least one recommended payment option corresponding to the access location is determined; The at least one recommended payment option is displayed in the diagnostic application interface.

2. The method according to claim 1, characterized in that, The step of determining at least one recommended payment option corresponding to the access location based on the network location identifier includes: Based on the network location identifier, the current device region of the diagnostic device is determined; The system queries the local geolocation database of the diagnostic device based on the device's region. The geolocation database includes various payment options corresponding to different device regions and the recommended priority of each payment option. The n highest-priority payment options among multiple payment options that match the device's region are determined as the at least one recommended payment option, where n is a positive integer.

3. The method according to claim 1, characterized in that, The step of determining at least one recommended payment option corresponding to the access location based on the network location identifier includes: Based on the network location identifier, the current device region of the diagnostic device is determined; Determine at least one payment method permitted in the device region and the historical success rate of each payment method in the device region; The k payment methods with the highest historical success rates are identified as at least one recommended payment option, where k is a positive integer.

4. The method according to any one of claims 1 to 3, characterized in that, The at least one recommended payment option includes a voucher payment option, which refers to a payment option that uses a pre-acquired digital voucher to complete the payment, and the digital voucher corresponds to a verification card key; The method further includes: In response to the selection of the payment option, the card input area is displayed; Obtain the card key entered by the user in the card key input area, and verify the digital credential based on the card key; If the verification is successful, a payment success message will be displayed, and a service entry point corresponding to the payment request operation will be provided.

5. The method according to claim 4, characterized in that, The at least one recommended payment option also includes an online payment option; The method further includes: Receive a selection of the online payment option and trigger an online payment operation; In response to the online payment operation and if the online payment operation fails, a prompt message is displayed to guide the user to select the voucher payment option to make the payment.

6. The method according to claim 5, characterized in that, The displayed prompt information includes online purchase entry and offline purchase address information. The offline purchase address information includes multiple digital voucher purchase addresses sorted by distance and their corresponding contact information. The method further includes: In response to the triggering operation of the online purchase portal, the user is redirected to the interface for purchasing the digital voucher online. The server used for purchasing digital vouchers online is independent of the server used for the online payment option.

7. The method according to claim 4, characterized in that, The diagnostic application interface also includes an online commitment code generation entry, and the method further includes: In response to a trigger operation on the online commitment code generation entry, a commitment code is generated, which is used to obtain the digital credential from a third-party service provider; Send the commitment code to the third-party service provider; If a confirmation message is received from the third-party service provider within a preset time period after the commitment code is sent, a payment success message will be displayed, and a service entry corresponding to the payment request operation will be provided.

8. A payment recommendation device, characterized in that, The device includes: The display module is used to display the diagnostic application interface of the diagnostic application. The processing module is used to obtain the network location identifier of the diagnostic device in response to a payment request operation; the payment request operation is used to request the purchase of services provided by the diagnostic application, and the network location identifier is used to indicate the access location of the diagnostic device in the network; The processing module is further configured to determine at least one recommended payment option corresponding to the access location based on the network location identifier; The display module is also used to display the at least one recommended payment option in the diagnostic application interface.

9. An electronic device comprising a memory, one or more processors, and a computer program stored in the memory and executable on the one or more processors, characterized in that, When the one or more processors execute the computer program, the electronic device performs the method as described in any one of claims 1 to 7.

10. 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 as described in any one of claims 1 to 7.

Images