Payment implementation method and device, equipment, storage medium and program product

Abstract

The invention discloses a payment implementation method and device, equipment, a storage medium and a program product. The method is applied to a code-to-card system and comprises the steps that a first code-to-card request which is sent by a wallet system and comprises a first payment account identifier is received, and the first payment account identifier is used for identifying a target payment account of a target user; in response to the first code-to-card request, determining a target payment account of a target user corresponding to the first payment account identifier and a target payment account system corresponding to the target payment account; acquiring first card data used for non-contact payment and corresponding to the target payment account from a target payment account system; determining second card data based on the first card data and the first payment account identifier; and sending the second card data to the wallet application via the wallet system, so that the wallet application stores the second card data to a security chip of the user terminal, and payment is carried out by using resources in the target payment account in a non-contact payment mode based on the second card data in the security chip.

Description

Technical Field

[0001] This application belongs to the field of payment technology, and in particular relates to a payment implementation method, apparatus, device, storage medium and program product. Background Technology

[0002] With the rapid development of mobile payment globally, in order to improve the overseas payment experience, some countries or regions have added, reinstalled, or upgraded acceptance terminals to enable them to support QR code payment for various wallet applications, thereby promoting QR code-based payment solutions.

[0003] However, these payment methods heavily rely on modifications to the hardware and systems at the overseas payment terminals, resulting in high implementation costs. Furthermore, the specific implementation methods vary across different countries and regions, exhibiting diverse and personalized characteristics. Therefore, existing QR code payment models based on terminal modifications have limited global adoption and struggle to effectively meet the growing demand for mobile payments overseas. Summary of the Invention

[0004] This application provides a payment implementation method, apparatus, electronic device, computer-readable storage medium, and computer program product, which can improve the global popularity of mobile payment and effectively meet the growing demand for mobile payment overseas.

[0005] In a first aspect, embodiments of this application provide a payment implementation method applied to a code-to-card system, the method comprising: Receive a first code-to-card request sent by the wallet system. The first code-to-card request includes a first payment account identifier, which is used to identify the target user's target payment account. In response to the first code-to-card request, the target payment account of the target user corresponding to the first payment account identifier and the target payment account system corresponding to the target payment account are determined; Obtain first card data corresponding to the target payment account from the target payment account system; the first card data is used for contactless payment. Based on the first card data and the first payment account identifier, the second card data is determined; The second card data is sent to the wallet application via the wallet system, so that the wallet application stores the second card data in the security chip of the user terminal, and makes a payment using the resources in the target payment account based on the second card data in the security chip using a contactless payment method.

[0006] Secondly, embodiments of this application provide a payment implementation method applied to a wallet application, the method comprising: Receive the first input for converting the code to a card for the target user's target payment account; In response to the first input, obtain the wallet application identifier, the first user identifier of the target user who is logged into the wallet application, and the second payment account identifier of the target payment account; Based on the wallet application identifier, the first user identifier, and the second payment account identifier, a third code transfer request is generated; The system sends the third code-to-card request to the wallet system so that the wallet system can obtain the wallet system identifier. Based on the wallet application identifier, the wallet system identifier, the first user identifier, and the second payment account identifier, the system determines the first payment account identifier. Based on the first payment account identifier, the system generates the first code-to-card request and sends the first code-to-card request to the code-to-card system so that the code-to-card system can determine the target payment account of the target user corresponding to the first payment account identifier, as well as the target payment account system corresponding to the target payment account. The system also obtains the first card data corresponding to the target payment account from the target payment account system and determines the second card data based on the first card data and the first payment account identifier. The first card data is used for contactless payment. Receive the second card data sent by the code-to-card system via the wallet system; The second card data is stored in the security chip of the user terminal, so that, based on the second card data in the security chip, the target payment account can be used for payment using a contactless payment method.

[0007] Thirdly, embodiments of this application provide a payment implementation method applied to a wallet system, the method comprising: Receive a third code transfer request sent by a wallet application, wherein the third code transfer request includes a wallet application identifier, a first user identifier of the target user who is logged into the wallet application, and a second payment account identifier of the target payment account; In response to the third code transfer request, obtain the wallet system identifier; The first payment account identifier is determined based on the wallet application identifier, the wallet system identifier, the first user identifier, and the second payment account identifier; Based on the first payment account identifier, a first code transfer request is generated; Send the first code-to-card request to the code-to-card system so that the code-to-card system can determine the target payment account of the target user corresponding to the first payment account identifier, and the target payment account system corresponding to the target payment account, and obtain the first card data corresponding to the target payment account from the target payment account system, and determine the second card data based on the first card data and the first payment account identifier, wherein the first card data is used for contactless payment; Receive the second card data sent by the code-to-card system; The second card data is sent to the wallet application so that the wallet application stores the second card data in the security chip of the user terminal, and then uses the resources in the target payment account to make payment based on the second card data in the security chip using a contactless payment method.

[0008] Fourthly, embodiments of this application provide a payment implementation device applied to a code-to-card system, the device comprising: The first receiving module is used to receive a first code-to-card request sent by the wallet system. The first code-to-card request includes a first payment account identifier, which is used to identify the target user's target payment account. The first determining module is used to, in response to the first code-to-card request, determine the target payment account of the target user corresponding to the first payment account identifier, and the target payment account system corresponding to the target payment account; The first acquisition module is used to acquire first card data corresponding to the target payment account from the target payment account system. The first card data is used for contactless payment. The first determining module is further configured to determine the second card data based on the first card data and the first payment account identifier; The first sending module is used to send the second card data to the wallet application via the wallet system, so that the wallet application stores the second card data in the security chip of the user terminal, and makes payment using the resources in the target payment account based on the second card data in the security chip using a contactless payment method.

[0009] Fifthly, embodiments of this application provide a payment implementation device for use in a wallet application, the device comprising: The second receiving module is used to receive the first input for converting the code to the card of the target user's target payment account; The second acquisition module is used to acquire, in response to the first input, a wallet application identifier, a first user identifier of the target user who is logged into the wallet application, and a second payment account identifier of the target payment account. The second generation module is used to generate a third code-to-card request based on the wallet application identifier, the first user identifier, and the second payment account identifier; The second sending module is used to send the third code-to-card request to the wallet system, so that the wallet system can obtain the wallet system identifier, determine the first payment account identifier based on the wallet application identifier, the wallet system identifier, the first user identifier, and the second payment account identifier, generate the first code-to-card request based on the first payment account identifier, and send the first code-to-card request to the code-to-card system, so that the code-to-card system can determine the target payment account of the target user corresponding to the first payment account identifier, and the target payment account system corresponding to the target payment account, and obtain the first card data corresponding to the target payment account from the target payment account system, and determine the second card data based on the first card data and the first payment account identifier, wherein the first card data is used for contactless payment; The second receiving module is further configured to receive the second card data sent by the code-to-card system via the wallet system; The storage module is used to store the second card data in the security chip of the user terminal, so as to make payment using the resources in the target payment account based on the second card data in the security chip using a contactless payment method.

[0010] Sixthly, embodiments of this application provide a payment implementation device applied to a wallet system, the device comprising: The third receiving module is used to receive a third code transfer request sent by the wallet application. The third code transfer request includes a wallet application identifier, a first user identifier of the target user who is logged into the wallet application, and a second payment account identifier of the target payment account. The third acquisition module is used to acquire the wallet system identifier in response to the third code transfer request; The third determining module is used to determine the first payment account identifier based on the wallet application identifier, the wallet system identifier, the first user identifier, and the second payment account identifier; The third generation module is used to generate a first code-to-card request based on the first payment account identifier; The third sending module is used to send the first code-to-card request to the code-to-card system so that the code-to-card system can determine the target payment account of the target user corresponding to the first payment account identifier, and the target payment account system corresponding to the target payment account, and obtain the first card data corresponding to the target payment account from the target payment account system, and determine the second card data based on the first card data and the first payment account identifier, wherein the first card data is used for contactless payment; The third receiving module is also used to receive the second card data sent by the code-to-card system; The third sending module is further configured to send the second card data to the wallet application, so that the wallet application stores the second card data in the security chip of the user terminal, and makes payment using the resources in the target payment account based on the second card data in the security chip using a contactless payment method.

[0011] In a seventh aspect, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements any one of the possible implementations of the first, second, or third aspect described above.

[0012] Eighthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions that, when executed by a processor, implement the method in any of the possible implementations of the first, second, or third aspects described above.

[0013] Ninthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform a method as described in any of the possible implementations of the first, second, or third aspects above.

[0014] This application embodiment, in response to a first card transfer request sent by the wallet system for a target user's target payment account, obtains first card data for contactless payment from the payment account system corresponding to the target payment account, and determines second card data based on the first card data and a first payment account identifier used to identify the target user's target payment account. This allows the target payment account to be converted into second card data for contactless payment. Thus, by sending the second card data to the wallet application via the wallet system, and the wallet application storing the second card data in the user terminal's secure chip, it is possible to use the second card data in the secure chip for contactless payment, utilizing the resources in the target payment account. This improves the global prevalence of mobile payments and effectively meets the growing demand for mobile payments overseas. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram of the structure of a payment implementation system provided in one embodiment of this application; Figure 2 This is a flowchart illustrating a payment implementation method applied to a code-to-card system according to an embodiment of this application; Figure 3 This is a flowchart illustrating a payment implementation method for a wallet application provided in one embodiment of this application; Figure 4 This is a flowchart illustrating a payment implementation method for a wallet system provided in one embodiment of this application; Figure 5 This is a schematic diagram of the structure of a payment implementation device applied to a code-to-card system according to an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a payment implementation device for a wallet application provided in one embodiment of this application; Figure 7 This is a schematic diagram of the structure of a payment implementation device applied to a wallet system according to an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0017] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0018] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0019] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, they do not mean that the applicant has used or necessarily used the solution.

[0020] Furthermore, the acquisition, storage, use, and processing of data in this application's technical solution all comply with relevant national laws and regulations.

[0021] As described in the background section, with the rapid development of mobile payment globally, in order to improve the overseas payment experience, some countries or regions have been adding, reinstalling, or upgrading acceptance terminals to enable them to support QR code payment for various wallet applications, thereby promoting QR code-based payment solutions.

[0022] However, these payment methods heavily rely on modifications to the hardware and systems at the overseas payment terminals, resulting in high implementation costs. Furthermore, the specific implementation methods vary across different countries and regions, exhibiting diverse and personalized characteristics. Therefore, existing QR code payment models based on terminal modifications have limited global adoption and struggle to effectively meet the growing demand for mobile payments overseas.

[0023] In recent years, contactless payment products have been gradually adopted by overseas users to meet the demand for contactless payments in face-to-face scenarios. Therefore, this application, considering the actual payment acceptance environment overseas, proposes a method for converting user payment codes to user payment cards without requiring the addition, reinstallation, or upgrading of acceptance terminals. Specifically, payment card data for contactless payments is generated through a wallet account or a bank card linked to a wallet application and stored in the user terminal's secure chip. This enables contactless payments based on the payment card data, thereby improving the global adoption of mobile payments and effectively meeting the growing demand for mobile payments overseas.

[0024] Therefore, to address the relevant technical issues, embodiments of this application provide a payment implementation method, apparatus, electronic device, computer-readable storage medium, and computer program product. The payment implementation method can be applied to contactless payment scenarios based on user payment codes. This contactless payment scenario based on user payment codes can be understood as first generating payment card data for contactless payment based on the wallet account of a wallet application or a bank card linked to the wallet application, and then performing contactless payment based on this payment card data.

[0025] The payment implementation method in this application embodiment can be applied to a payment implementation system.

[0026] The payment implementation system provided in the embodiments of this application is described below.

[0027] Figure 1 A schematic diagram of the structure of a payment implementation system provided in one embodiment of this application is shown.

[0028] like Figure 1 As shown, the payment implementation system 100 may include a wallet application 11, a wallet system 12, a code-to-card system 13, a wallet system 141, and an issuing bank system 142. The wallet application 11 can be any application capable of enabling QR code payment by displaying a graphic code. The wallet application 11 may include the front-end application corresponding to the issuing bank system and the front-end application corresponding to the third-party payment platform. The wallet application 11 can be used to interact with users to activate the code-to-card function for a payment account or generate payment card data corresponding to a payment account for contactless payment. The wallet system 12 can be the back-end system of the wallet application 11. Each wallet application 11 can correspond to one wallet system 12, and each wallet system 12 can correspond to one or more wallet applications 11.

[0029] Furthermore, wallet system 141 and issuing bank system 142 can be collectively referred to as payment account system. Payment account system can represent the backend system corresponding to a payment account that has enabled code-to-card conversion. This payment account can be the wallet account of wallet application 11 or a bank card bound to wallet application 11. The wallet account can include a stored-value balance account, a wealth management balance account, a credit limit account, etc. Additionally, if the payment account is a bank card bound to wallet application 11, then the payment account system can be issuing bank system 142. If the payment account is a wallet account of wallet application 11, then the payment account system can be wallet system 141. Wallet system 141 and wallet system 12 can be the same or different, and this is not limited here. In other words, the embodiments of this application can realize code-to-card conversion across wallet systems and issuing bank systems. For example, through wallet application A and its corresponding wallet system A, payment card data corresponding to the wallet account of wallet application A can be generated, as can payment card data corresponding to the wallet account of wallet application B, or payment card data corresponding to the bank card bound to wallet application A.

[0030] As an example, wallet application 11 can first receive a third input from a user to activate the code-to-card function for a first payment account. The first payment account can be the wallet account of wallet application 11 or a bank card linked to wallet application 11. In response to the third input, wallet application 11 can obtain its wallet application identifier and the first user identifier of the user logged into wallet application 11. Based on the wallet application identifier, the first user identifier, and the first payment account, it generates a first code-to-card function activation request for the first payment account and sends this request to the wallet system 12 corresponding to wallet application 11. Upon receiving the first code-to-card function activation request, wallet system 12 can add its wallet system identifier to the request to obtain a second code-to-card function activation request and send this request to code-to-card system 13. Upon receiving a second code-to-card conversion function activation request, the code-to-card conversion system 13 first parses the request to obtain a wallet application identifier, a wallet system identifier, a first user identifier, and a first payment account. Then, based on these identifiers, it performs user identification to determine the user's identity. If the code-to-card conversion system 13 does not contain a unique identifier corresponding to the user identity, it creates one to obtain a second user identifier. It then creates a payment account identifier corresponding to the user identity and the first payment account, and associates this payment account identifier with the second user identifier. If the code-to-card conversion system 13 already contains a unique identifier (the second user identifier) ​​corresponding to the user identity, it creates one to correspond to the user identity and the first payment account, and then associates this payment account identifier with the second user identifier. In this way, the code-to-card conversion system 13 obtains a list of payment accounts with activated code-to-card conversion functions corresponding to the second user identifier. This list can include multiple payment accounts with activated code-to-card conversion functions and their corresponding payment account identifiers. The second user identifier can be recorded as the main payment token, and the payment account identifier can be recorded as the sub-token.

[0031] Based on this, specific code-to-card conversion operations can be performed on the payment accounts that have already enabled the code-to-card function, generating payment card data corresponding to the payment account, and making contactless payments based on the payment card data.

[0032] The following describes the payment implementation method for the code-to-card system provided in the embodiments of this application.

[0033] Figure 2 This illustration shows a flowchart of a payment implementation method for a code-to-card system according to an embodiment of this application. Figure 2 As shown, the payment implementation method provided in this application embodiment includes the following steps: S210. Receive the first code transfer request sent by the wallet system. The first code transfer request includes a first payment account identifier, which is used to identify the target user's target payment account. S220. In response to the first code transfer request, determine the target payment account of the target user corresponding to the first payment account identifier, and the target payment account system corresponding to the target payment account; S230. Obtain the first card data corresponding to the target payment account from the target payment account system. The first card data is used for contactless payment. S240. Based on the first card data and the first payment account identifier, determine the second card data; S250: Send the second card data to the wallet application via the wallet system, so that the wallet application stores the second card data in the security chip of the user terminal, and makes payment using the resources in the target payment account based on the second card data in the security chip using a contactless payment method.

[0034] This application embodiment, in response to a first card transfer request sent by the wallet system for a target user's target payment account, obtains first card data for contactless payment from the payment account system corresponding to the target payment account, and determines second card data based on the first card data and a first payment account identifier used to identify the target user's target payment account. This allows the target payment account to be converted into second card data for contactless payment. Thus, by sending the second card data to the wallet application via the wallet system, and the wallet application storing the second card data in the user terminal's secure chip, it is possible to use the second card data in the secure chip for contactless payment, utilizing the resources in the target payment account. This improves the global prevalence of mobile payments and effectively meets the growing demand for mobile payments overseas.

[0035] The specific implementation methods for each of the above steps are described below.

[0036] In some embodiments, in S210, the first code-to-card request may be a code-to-card request for the target user's target payment account. The first payment account identifier may be used to identify the target user's target payment account. The first payment account identifier may be payment token information generated based on the target user's target payment account, or it may include information such as a wallet system identifier, a wallet application identifier, a first user identifier of the target user logged into the wallet application, and a second payment account identifier of the target payment account.

[0037] As an example, a wallet application can display one or more payment accounts that have enabled the code-to-card conversion function. These payment accounts can all belong to the target user. The payment account can be the wallet application's own wallet account, a bank card already linked to the wallet application, or a wallet application belonging to another wallet application, or a bank card already linked to another wallet application—there are no restrictions here.

[0038] In addition, the wallet application can display specific account information for the payment account, which may include information such as the second payment account identifier, account name, account balance, and account type.

[0039] After the wallet application displays one or more payment accounts that have enabled the code-to-card conversion function, the target user can select a target payment account from these accounts based on their payment habits, preferences, and account balance. In response to the user's selection of a target payment account, the wallet application can obtain the wallet application identifier and the target user's first user identifier. Based on the wallet application identifier, the first user identifier, and the target payment account's second payment account identifier, the wallet application application generates a third code-to-card conversion request and sends it to the wallet system. The first user identifier may include at least one of the user's login account, mobile phone number, ID card number, and email address.

[0040] After receiving a third-party code transfer request, the wallet system can parse the request to obtain the wallet application identifier, the first user identifier, and the second payment account identifier, as well as the wallet system identifier. Based on these identifiers, the wallet system identifier, the first user identifier, and the second payment account identifier, the wallet system can determine the first payment account identifier. Then, based on the first payment account identifier, the wallet system can generate a first code-to-card transfer request and send this request to the code-to-card transfer system. The determination of the first payment account identifier based on the wallet application identifier, wallet system identifier, first user identifier, and second payment account identifier can be achieved by directly using all three identifiers together. In other words, the first payment account identifier can include the wallet application identifier, wallet system identifier, first user identifier, and second payment account identifier.

[0041] Additionally, the wallet system may include a first payment account identifier that corresponds to both the second user identifier and the second payment account identifier of the payment account. The second user identifier can be a unique identifier for the user across the code-to-card system, different wallet systems, and different payment account systems; that is, the second user identifier can be used to uniquely identify the user. The second user identifier can be token information obtained by tokenizing a mobile phone number or ID card number. Therefore, the second user identifier can also be recorded as the primary token.

[0042] Based on this, after obtaining the wallet application identifier, wallet system identifier, first user identifier, and second payment account identifier of the target payment account, the wallet system can first perform user identification based on the wallet application identifier, wallet system identifier, and first user identifier to determine the second user identifier corresponding to the target user. Then, based on the above correspondence, it can determine the first payment account identifier that jointly corresponds to the second user identifier and the second payment account identifier of the target payment account. This first payment account identifier can also be recorded as a sub-token.

[0043] Additionally, as mentioned above, a wallet application can display the payment accounts of one or more target users who have enabled the code-to-card conversion function. This payment account can be the wallet application's own wallet account, a bank card already linked to the wallet application, or a wallet application of another wallet application, or a bank card already linked to another wallet application—there are no restrictions on this.

[0044] Therefore, in order to improve the comprehensiveness of the displayed payment accounts, in some embodiments, before S210 above, the method may further include: Receive a second code transfer request sent by the wallet system. The second code transfer request includes the wallet system identifier, the wallet application identifier, and the first user identifier of the target user who is logged into the wallet application. In response to the second code transfer request, the second user identifier corresponding to the target user is determined based on the wallet system identifier, wallet application identifier, and first user identifier; Obtain the list of payment accounts corresponding to the second user identifier. The list of payment accounts includes multiple payment accounts that have enabled the code-to-card conversion function. The wallet system sends a list of payment accounts to the wallet application so that the wallet application can display the list of payment accounts. It receives a first input to select a target payment account from the list of payment accounts. In response to the first input, it obtains the wallet application identifier, the first user identifier, and the second payment account identifier of the target payment account. Based on the wallet application identifier, the first user identifier, and the second payment account identifier, it generates a third code-to-card transfer request and sends the third code-to-card transfer request to the wallet system so that the wallet system can obtain the wallet system identifier. Based on the wallet application identifier, the wallet system identifier, the first user identifier, and the second payment account identifier, it determines the first payment account identifier. Based on the first payment account identifier, it generates a first code-to-card transfer request and sends the first code-to-card transfer request to the code-to-card transfer system.

[0045] Here, the second code-to-card request can be used to retrieve all payment accounts corresponding to the target user that have the code-to-card function enabled. Additionally, the payment account list can include account information for multiple payment accounts. This account information may include information such as the first payment account identifier, the second payment account identifier, the account name, the account balance, and the account type.

[0046] As an example, a wallet application can first receive a second input for transferring a code to a card from the target user's payment account. This second input could be, for example, the user clicking a "Code to Card" control within the wallet application. In response to the second input, the wallet application can obtain its own wallet application identifier and a first user identifier of the target user logged into the wallet application. Based on the wallet application identifier and the first user identifier, it can generate a fourth code to card transfer request and send the fourth code to card transfer request to the wallet system.

[0047] Upon receiving the fourth code transfer request, the wallet system can parse it to obtain the wallet application identifier and the first user identifier, as well as the wallet system identifier. Based on the wallet application identifier, wallet system identifier, and first user identifier, it can then generate a second code transfer request. Afterward, the wallet system can send the second code transfer request to the code transfer system.

[0048] Upon receiving a second code-to-card transfer request, the code-to-card transfer system can parse the request to obtain the wallet system identifier, wallet application identifier, and first user identifier. Based on these identifiers, it can then perform user identification to determine the second user identifier corresponding to the target user. As described above, the code-to-card transfer system can pre-store a list of payment accounts that have activated code-to-card transfer functionality, corresponding to the second user identifier. This list can include multiple payment accounts that have activated code-to-card transfer functionality. Therefore, after determining the second user identifier corresponding to the target user, the code-to-card transfer system can obtain the list of payment accounts corresponding to that second user identifier and send this list to the wallet system.

[0049] Since the list of payment accounts corresponding to the second user identifier can include information such as the first payment account identifier, second payment account identifier, account name, account balance, and account type for multiple payment accounts, the wallet system can determine and store the correspondence between the second user identifier, the second payment account identifier, and the first payment account identifier upon receiving the payment account list. Alternatively, the wallet system may choose not to store the correspondence between the second user identifier, the second payment account identifier, and the first payment account identifier. Afterward, the wallet system can send the payment account list to the wallet application.

[0050] Once the wallet application receives the list of payment accounts, it can display it. Specifically, the wallet application can display information such as the secondary payment account identifier, account name, account balance, and account type for each payment account. After viewing this information, the target user can select the desired payment account from among the multiple payment accounts based on their payment habits, preferences, and account balance.

[0051] After the user selects the target payment account, the wallet application can respond to the user's selection operation by obtaining the wallet application identifier, the first user identifier, and the second payment account identifier of the target payment account, and generate a third code transfer request based on the wallet application identifier, the first user identifier, and the second payment account identifier, and send the third code transfer request to the wallet system.

[0052] Upon receiving a third-party code transfer request, the wallet system parses it to obtain the wallet application identifier, the first user identifier, and the second payment account identifier, as well as the wallet system identifier. Based on these identifiers, it then determines the first payment account identifier. The specific process for determining the first payment account identifier is described above and will not be repeated here. Afterward, the wallet system can generate a first code-to-card transfer request based on the first payment account identifier and send it to the code-to-card transfer system.

[0053] This application embodiment improves the comprehensiveness of the displayed payment accounts by first obtaining a list of all payment accounts corresponding to the target user, and then displaying the list of payment accounts in the wallet application.

[0054] Based on this, in order to improve the user's payment experience, in some embodiments, before sending the list of payment accounts to the wallet application via the wallet system, the method may further include: Get the discount information corresponding to each of the multiple payment accounts.

[0055] Based on this, the aforementioned sending of the payment account list to the wallet application via the wallet system, so that the wallet application can display the payment account list, may specifically include: The wallet system sends a list of payment accounts and promotional information to the wallet application so that the wallet application can display the list of payment accounts and promotional information.

[0056] Here, the discount information corresponding to multiple payment accounts can be stored in the discount system. If a payment account does not have any discount information, then the discount information corresponding to that payment account can be empty.

[0057] As an example, after obtaining the list of payment accounts, the code-to-card system can connect with the discount system to obtain the discount information corresponding to each payment account in the payment account list. The system then returns the payment account list and the discount information corresponding to each payment account to the wallet application via the wallet system, so that the wallet application can display the payment account list and discount information.

[0058] As a more specific example, after obtaining the discount information, the code-to-card system can add the discount information to the account information, resulting in account information including the first payment account identifier, the second payment account identifier, the account name, the account balance, the account type, and the discount information.

[0059] This application embodiment displays a list of payment accounts and promotional information through a wallet application, allowing target users to select a target payment account based on their own payment habits, payment preferences, and the promotional information and account balance of the payment account, thereby improving the user's payment experience.

[0060] In some embodiments, in S220, after receiving the first code-to-card request, the code-to-card system can parse the first code-to-card request to obtain the first payment account identifier. If the first payment account identifier is a sub-token, the code-to-card system can first determine the main token corresponding to the sub-token based on the association between the main token (i.e., the second user identifier) ​​and the sub-token, identify the target user, and then determine the target payment account of the target user corresponding to the sub-token in the payment account list corresponding to the main token, based on the correspondence between the sub-token and the payment account. Alternatively, if the first payment account identifier includes a wallet application identifier, a wallet system identifier, a first user identifier, and a second payment account identifier, the code-to-card system can first perform user identification based on the wallet application identifier, the wallet system identifier, and the first user identifier to determine the second user identifier corresponding to the target user, and then determine the target payment account of the target user corresponding to the second payment account identifier in the payment account list corresponding to the second user identifier.

[0061] Furthermore, based on the second payment account identifier of the target payment account, the target payment account system corresponding to the target payment account can be determined. For example, if the target payment account is a bank card, the issuing bank system can be determined based on the first six digits of the bank card number. Alternatively, when generating the payment account list, the payment account system corresponding to each payment account can be predetermined. In this way, after determining the target payment account, the target payment account system corresponding to the target payment account can be directly determined according to the pre-stored correspondence.

[0062] In some embodiments, in S230, after determining the target payment account system, the code-to-card system can obtain first card data corresponding to the target payment account for contactless payment from the target payment account system. This first card data may include integrated circuit (IC) card transaction data and key data. The IC card transaction data includes, but is not limited to, IC card public key certificates, IC card encrypted data, and target payment system application data. The key data includes, but is not limited to, data encryption transmission keys, message authentication keys, and application encrypted keys.

[0063] In some embodiments, in S240, the first payment account identifier may be a sub-token pre-generated by the code-to-card system during the activation phase of the code-to-card function. This sub-token may be a permanent sub-token. After obtaining the first card data, the code-to-card system can determine the second card data based on the first card data and the sub-token. That is, the second card data may include the first card data and the sub-token. Furthermore, the second card data generated based on the permanent sub-token may be permanent card data.

[0064] In addition, sub-tokens can also include temporary sub-tokens, and the second card data can also include the temporary card data corresponding to the temporary sub-tokens.

[0065] Specifically, as mentioned above, the first payment account identifier may include the wallet system identifier, the wallet application identifier, the first user identifier of the target user who logged into the wallet application, and the second payment account identifier of the target payment account.

[0066] Therefore, in order to improve the flexibility of generating second card data, in some embodiments, the above-mentioned S240 may specifically include: Based on the wallet system identifier, wallet application identifier, and first user identifier, determine the second user identifier corresponding to the target user; Based on the second user identifier and the second payment account identifier, generate a temporary first payment account identifier or a permanent first payment account identifier; The temporary card data is determined based on the first card data and the temporary first payment account identifier; or, The permanent card data is determined based on the first card data and the permanent first payment account identifier.

[0067] Here, the temporary first payment account identifier can be a temporary sub-token, and the permanent first payment account identifier can be a permanent sub-token. The temporary and permanent sub-tokens can have different expiration dates but the same content. This sub-token is the same as the sub-token pre-generated by the code-to-card system during the activation phase of the code-to-card function.

[0068] As an example, after obtaining the wallet system identifier, wallet application identifier, first user identifier, and second payment account identifier, the code-to-card system can first perform user identification based on the wallet system identifier, wallet application identifier, and first user identifier to determine the second user identifier corresponding to the target user. Then, based on the second user identifier and second payment account identifier, a temporary sub-token or a permanent sub-token is generated. The method for generating the temporary or permanent sub-token at this time is the same as the method for generating sub-tokens during the activation phase of the code-to-card function.

[0069] If the code-to-card system generates a temporary sub-token, temporary card data can be generated based on the first card data and the temporary sub-token. If the code-to-card system generates a permanent sub-token, permanent card data can be generated based on the first card data and the permanent sub-token.

[0070] This application embodiment improves the flexibility of generating a second card by allowing users to choose between generating temporary card data or permanent card data according to actual needs.

[0071] In some embodiments, in S250, after generating the second card data, the code-to-card system can send the second card data to the wallet system. Upon receiving the second card data, the wallet system can send it to the wallet application. Upon receiving the second card data, the wallet application can store the second card data in the user terminal's secure chip, enabling contactless payment using resources in the target payment account based on the second card data in the secure chip. The secure chip can be, for example, an embedded secure element (eSE). Additionally, the user terminal can be equipped with a supporting system for contactless payments, which can be implemented using existing methods and will not be elaborated further here.

[0072] Furthermore, to further enhance the user's payment experience, in some embodiments, the above-mentioned S250 may specifically include: The wallet system sends the second card data and its corresponding target offer information to the wallet application, so that the wallet application can output offer prompt information based on the target offer information.

[0073] Here, the target discount information can be the discount information corresponding to the target payment account. For example, the discount information could be "Use this card to enjoy a discount of 50 yuan off a 300 yuan payment".

[0074] This application embodiment, by sending second card data to the wallet application while simultaneously returning the target discount information and outputting a reminder message to the user through the wallet application, can further enhance the user's payment experience by reminding the user of the payment discount again.

[0075] Based on this, once the data for the second card used for contactless payment is ready, the process of making contactless payments based on that second card data can begin.

[0076] Based on this, in order to improve the user's payment experience, in some embodiments, after S250 above, the method may further include: The merchant terminal receives the first transaction data sent by the acquiring system. The first transaction data is generated based on the first transaction amount and the second card data. The second card data is read by the merchant terminal from the security chip of the user terminal via contactless means. Based on the first payment account identifier in the first transaction data, determine the target user's target payment account and the target payment account system corresponding to the target payment account; Send the first transaction data to the target payment account system so that the target payment account system can make payment based on the first transaction data.

[0077] Here, during contactless payment, the merchant terminal can receive the first transaction amount entered by the user, read the second card data from the user's terminal's security chip via contactless means, and generate first transaction data based on the first transaction amount and the second card data. Afterwards, the merchant terminal can send the first transaction data to the code-to-card system via the acquiring system. The first transaction data may include information such as the first payment account identifier (i.e., sub-token), the IC card transaction ciphertext generated based on the second card data, the first transaction amount, and the transaction time.

[0078] After receiving the first transaction data, the code-to-card system can determine the target user's target payment account and the corresponding target payment account system based on the first payment account identifier in the first transaction data. The methods for determining the target payment account and target payment account system are described above and will not be repeated here.

[0079] Afterwards, the code-to-card system can send the first transaction data to the target payment account system. Upon receiving the first transaction data, the target payment account system can first perform transaction authentication based on the first transaction data, then make the payment after successful authentication, and return payment response information to the code-to-card system.

[0080] This application embodiment improves the user's payment experience by first converting the target payment account into second card data and then performing contactless payment based on the second card data.

[0081] Additionally, as mentioned above, the target payment account can correspond to target discount information. Therefore, to further enhance the user's payment experience, in some embodiments, before sending the first transaction data to the target payment account system, the method may further include: Based on the target discount information corresponding to the target payment account, the first transaction amount in the first transaction data is updated to the second transaction amount to obtain the second transaction data.

[0082] Based on this, sending the first transaction data to the target payment account system may specifically include: Send second transaction data to the target payment account system so that the target payment account system can make payment based on the second transaction data.

[0083] Here, after receiving the first transaction data and identifying the target payment account, the code-to-card system can also obtain the target discount information corresponding to the target payment account from the discount system, and calculate the first transaction amount based on the discount calculation method corresponding to the target discount information to obtain the second transaction amount. Furthermore, it updates the first transaction data based on the second transaction amount to obtain the second transaction data. The second transaction amount is less than the first transaction amount.

[0084] This application embodiment can further enhance the user's payment experience by updating the first transaction data, which includes the first transaction amount, to the second transaction data, which includes the second transaction amount, based on the target discount information, and by making payment based on the second transaction data.

[0085] Additionally, as mentioned above, the second card data can be permanent card data. Based on this, to improve payment security, in some embodiments, before S250 above, the method may further include: Set the risk control information corresponding to the second card data. The risk control information includes at least one of the following: number of transactions, transaction validity period, and transaction limit.

[0086] Based on this, sending the first transaction data to the target payment account system may specifically include: Based on risk control information, the first transaction data is verified, and the verification result is obtained. If the verification result is successful, the first transaction data is sent to the target payment account system.

[0087] Here, after the code-to-card system generates the second card data, risk control information such as the number of transactions, transaction validity period, and transaction limit corresponding to the second card data can be set. Thus, after the code-to-card system receives the first transaction data sent by the merchant's acceptance terminal via the acquiring system, it can verify the first transaction data based on the risk control information before sending it to the target payment account system. If the verification passes, the first transaction data can be sent to the target payment account system for payment. If the verification fails, the system can refuse to send the first transaction data to the target payment account system and refuse the payment.

[0088] As an example, a code-to-card system can record the number of times the first payment account identifier is used (i.e., the number of times the second card data is used). The number of transactions can be determined by the number of times the first payment account identifier is used. If the number of transactions exceeds a threshold, the verification result can be determined as verification failure.

[0089] In addition, the code-to-card system can also record the validity period of the first payment account identifier (i.e., the validity period of the second card data). The transaction validity period can be determined by the validity period of the first payment account identifier. If the transaction time in the first transaction data exceeds the transaction validity period, the verification result can be determined as verification failure.

[0090] Additionally, the transaction limit can be a single-transaction limit or a total limit. If the transaction limit is a single-transaction limit, and the amount of the first transaction exceeds the transaction limit, the verification result will be determined as verification failure. If the transaction limit is a total limit, and the total transaction amount corresponding to the first payment account identifier exceeds the transaction limit, the verification result will be determined as verification failure.

[0091] If the number of transactions, the validity period of the transactions, and the transaction limit all meet the expectations (e.g., the number of transactions is less than or equal to the threshold, the transaction time is within the validity period of the transactions, and the transaction amount is less than or equal to the transaction limit), the verification result can be determined as successful.

[0092] The embodiments of this application improve payment security by first verifying the first transaction data based on risk control information, and then continuing subsequent payments if the verification passes.

[0093] In addition, embodiments of this application may also verify the second transaction data based on risk control information before sending the second transaction data to the target payment account system, obtain a verification result, and send the second transaction data to the target payment account system if the verification result is successful.

[0094] Additionally, if the second card data is temporary card data, then to improve payment security, in some embodiments, after sending the first transaction data to the target payment account system as described above, the method may further include: Receive payment response information sent by the target payment account system upon completion of payment; In response to the payment response information, a card data deletion instruction is sent to the wallet application via the wallet system, instructing the wallet application to delete the second card data from the security chip.

[0095] Here, after receiving the payment response information sent by the target payment account system, the code-to-card system can send a card data deletion instruction to the wallet application via the wallet system, instructing the wallet application to delete the second card data from the security chip to improve payment security.

[0096] The following describes the payment implementation method for wallet applications provided in the embodiments of this application.

[0097] Figure 3 This illustration shows a flowchart of a payment implementation method for a wallet application according to an embodiment of this application. Figure 3 As shown, the payment implementation method provided in this application embodiment includes steps S310-S360.

[0098] S310 receives the first input for code-to-card conversion of the target user's target payment account.

[0099] Here, the wallet application can display one or more payment accounts that have enabled the code-to-card function. These one or more payment accounts can all belong to the target user. The first input can be the user selecting the target payment account from among the one or more payment accounts.

[0100] Therefore, in order to improve the comprehensiveness of the displayed payment accounts, in some embodiments, before S310 above, the method may further include: Receive a second input for converting the code to a card for the target user's payment account; In response to the second input, obtain the wallet application identifier and the first user identifier; Based on the wallet application identifier and the first user identifier, generate a fourth code card transfer request; A fourth code-to-card request is sent to the wallet system to enable the wallet system to obtain the wallet system identifier. Based on the wallet application identifier, the wallet system identifier, and the first user identifier, a second code-to-card request is generated. The second code-to-card request is also sent to the code-to-card system to enable the code-to-card system to respond to the second code-to-card request. Based on the wallet system identifier, the wallet application identifier, and the first user identifier, the second user identifier corresponding to the target user is determined. The list of payment accounts corresponding to the second user identifier is obtained. The list of payment accounts includes multiple payment accounts that have enabled the code-to-card function. The system receives a list of payment accounts sent via the wallet system from the code-to-card conversion system. Displays a list of payment accounts.

[0101] Based on this, the aforementioned S310 may specifically include: Receive the first input from the list of payment accounts to select the target payment account.

[0102] Here, the second input could be, for example, the user clicking the "Code to Card" control in the wallet application.

[0103] This application embodiment improves the comprehensiveness of the displayed payment accounts by first obtaining a list of all payment accounts corresponding to the target user, and then displaying the list of payment accounts in the wallet application.

[0104] Based on this, in order to improve the user's payment experience, in some embodiments, the payment account list sent by the above-mentioned code-to-card system via the wallet system may specifically include: The system receives a list of payment accounts and corresponding discount information for each payment account sent via the wallet system from the code-to-card conversion system.

[0105] Based on this, a list of payment accounts can be displayed, which may include: Displays a list of payment accounts and promotional information.

[0106] This application embodiment displays a list of payment accounts and promotional information through a wallet application, allowing target users to select a target payment account based on their own payment habits, payment preferences, and the promotional information and account balance of the payment account, thereby improving the user's payment experience.

[0107] S320, in response to the first input, obtains the wallet application identifier, the first user identifier of the target user who is logged into the wallet application, and the second payment account identifier of the target payment account.

[0108] S330 generates a third code card transfer request based on the wallet application identifier, the first user identifier, and the second payment account identifier.

[0109] S340, a third code-to-card request is sent to the wallet system to enable the wallet system to obtain the wallet system identifier. Based on the wallet application identifier, wallet system identifier, first user identifier, and second payment account identifier, the first payment account identifier is determined. Based on the first payment account identifier, a first code-to-card request is generated, and the first code-to-card request is sent to the code-to-card system to enable the code-to-card system to determine the target payment account of the target user corresponding to the first payment account identifier, as well as the target payment account system corresponding to the target payment account. The system also obtains the first card data corresponding to the target payment account from the target payment account system, and determines the second card data based on the first card data and the first payment account identifier. The first card data is used for contactless payment.

[0110] The S350 receives second card data sent by the code-to-card system via the wallet system.

[0111] Furthermore, to further enhance the user's payment experience, in some embodiments, the above-mentioned S350 may specifically include: Receive the second card data and its corresponding target offer information sent by the code-to-card system via the wallet system; Based on the target discount information, output discount reminder information.

[0112] This application embodiment outputs a reminder message to the user through a wallet application, which can remind the user of the payment offer again and further improve the user's payment experience.

[0113] The S360 stores the second card data in the user terminal's security chip, and then uses the second card data in the security chip to make a payment using the resources in the target payment account through contactless payment.

[0114] Additionally, if the second card data is temporary card data, in order to improve payment security, in some embodiments, after S360 above, the method may further include: Receive card data deletion instructions sent by the code-to-card system via the wallet system; In response to a card data deletion command, the data on the second card is deleted from the security chip.

[0115] In addition to the above, other steps of the method in the embodiments of this application can be found in the above text. Figure 1 The relevant descriptions of the embodiments shown will not be repeated here.

[0116] This application embodiment responds to a first code-to-card request sent by a wallet system to a target user's target payment account via a code-to-card conversion system. It obtains first card data for contactless payment from the payment account system corresponding to the target payment account, and determines second card data based on the first card data and a first payment account identifier used to identify the target user's target payment account. This allows the target payment account to be converted into second card data for contactless payment. Thus, by receiving the second card data sent by the code-to-card conversion system via the wallet system and storing the second card data in the user terminal's security chip, it is possible to use the second card data in the security chip for contactless payment, utilizing the resources in the target payment account. This improves the global adoption of mobile payments and effectively meets the growing demand for mobile payments overseas.

[0117] The following describes the payment implementation method for a wallet system provided in the embodiments of this application.

[0118] Figure 4 This illustration shows a flowchart of a payment implementation method for a wallet system according to an embodiment of this application. Figure 4 As shown, the payment implementation method provided in this application embodiment includes steps S410-S470.

[0119] S410 receives a third code transfer request sent by the wallet application. The third code transfer request includes the wallet application identifier, the first user identifier of the target user who is logged into the wallet application, and the second payment account identifier of the target payment account.

[0120] S420, in response to the third-party code transfer request, obtains the wallet system identifier.

[0121] S430 determines the first payment account identifier based on the wallet application identifier, the wallet system identifier, the first user identifier, and the second payment account identifier.

[0122] In some embodiments, the above-mentioned S430 may specifically include: Based on the wallet application identifier, wallet system identifier, and first user identifier, determine the second user identifier corresponding to the target user; The first payment account identifier is determined based on the second user identifier and the second payment account identifier.

[0123] S440 generates a first code transfer request based on the first payment account identifier.

[0124] S450, a first code-to-card request is sent to the code-to-card system so that the code-to-card system can determine the target payment account of the target user corresponding to the first payment account identifier, the target payment account system corresponding to the target payment account, and obtain the first card data corresponding to the target payment account from the target payment account system. Based on the first card data and the first payment account identifier, the second card data is determined. The first card data is used for contactless payment.

[0125] S460 receives data from the second card sent by the code-to-card system.

[0126] S470 sends second card data to the wallet application so that the wallet application stores the second card data in the user terminal's secure chip. Based on the second card data in the secure chip, the user can make a payment using the resources in the target payment account through contactless payment.

[0127] This application embodiment responds to a first code-to-card request sent by a wallet system for a target user's target payment account via a code-to-card conversion system. It obtains first card data for contactless payment from the payment account system corresponding to the target payment account, and determines second card data based on the first card data and a first payment account identifier used to identify the target user's target payment account. This allows the target payment account to be converted into second card data for contactless payment. Thus, by sending the second card data to the wallet system via the code-to-card conversion system, and by storing the second card data in the user terminal's secure chip, contactless payment can be made using the resources in the target payment account based on the second card data in the secure chip. This improves the global adoption of mobile payments and effectively meets the growing demand for mobile payments overseas.

[0128] In summary, this application, by establishing a code-to-card system and releasing a unified technical access standard, connects with multiple wallet systems and issuing bank systems, strengthening business cooperation between the institution hosting the code-to-card system and various domestic and international wallet and banking institutions, thus contributing to the construction of the payment ecosystem. Furthermore, by leveraging the existing bank card payment acceptance environments in various countries and regions, and without requiring new installations or upgrades to acceptance-side terminals, it achieves the conversion of user payment codes into user payment cards based on token technology, improving the overseas payment experience.

[0129] Based on the payment implementation method for the code-to-card system provided in the above embodiments, this application also provides specific implementation methods for the payment implementation device for the code-to-card system. Please refer to the following embodiments.

[0130] like Figure 5 As shown, a payment implementation device 500 for a code-to-card system provided in one embodiment of this application includes the following modules: The first receiving module 510 is used to receive a first code-to-card request sent by the wallet system. The first code-to-card request includes a first payment account identifier, which is used to identify the target user's target payment account. The first determining module 520 is used to respond to the first code-to-card request to determine the target payment account of the target user corresponding to the first payment account identifier, and the target payment account system corresponding to the target payment account; The first acquisition module 530 is used to acquire the first card data corresponding to the target payment account from the target payment account system. The first card data is used for contactless payment. The first determining module 520 is also used to determine the second card data based on the first card data and the first payment account identifier; The first sending module 540 is used to send second card data to the wallet application via the wallet system, so that the wallet application stores the second card data in the security chip of the user terminal, and makes payment using the resources in the target payment account based on the second card data in the security chip using a contactless payment method.

[0131] The payment realization device 500 described above will be explained in detail below: In some embodiments, the payment implementation device 500 may further include: The first receiving module 510 is also configured to receive a second code transfer request sent by the wallet system before receiving the first code transfer request sent by the wallet system. The second code transfer request includes a wallet system identifier, a wallet application identifier, and a first user identifier of the target user who is logged into the wallet application. The first determining module 520 is also used to respond to the second code-to-card request by determining the second user identifier corresponding to the target user based on the wallet system identifier, the wallet application identifier and the first user identifier; The first acquisition module 530 is also used to acquire a list of payment accounts corresponding to the second user identifier. The list of payment accounts includes multiple payment accounts that have enabled the code-to-card conversion function. The first sending module 540 is further configured to send a list of payment accounts to the wallet application via the wallet system, so that the wallet application displays the list of payment accounts; receive a first input to select a target payment account from the list of payment accounts; and in response to the first input, obtain a wallet application identifier, a first user identifier, and a second payment account identifier of the target payment account; generate a third code-to-card request based on the wallet application identifier, the first user identifier, and the second payment account identifier; and send the third code-to-card request to the wallet system, so that the wallet system obtains a wallet system identifier; determine a first payment account identifier based on the wallet application identifier, the wallet system identifier, the first user identifier, and the second payment account identifier; generate a first code-to-card request based on the first payment account identifier; and send the first code-to-card request to the code-to-card system.

[0132] In some embodiments, the payment implementation device 500 may further include: The first acquisition module 530 is also used to acquire discount information corresponding to each of the multiple payment accounts before sending the list of payment accounts to the wallet application via the wallet system; The first sending module 540 is further configured to send a list of payment accounts to the wallet application via the wallet system, so that the wallet application displays the list of payment accounts, including: The first sending module 540 is also used to send a list of payment accounts and promotional information to the wallet application via the wallet system, so that the wallet application can display the list of payment accounts and promotional information.

[0133] In some embodiments, the first transmitting module 540 may specifically include: The sending submodule is used to send the second card data and its corresponding target offer information to the wallet application via the wallet system, so that the wallet application can output offer prompt information based on the target offer information.

[0134] In some embodiments, the second card data includes temporary card data and permanent card data, and the first payment account identifier includes a wallet system identifier, a wallet application identifier, a first user identifier of the target user who logged into the wallet application, and a second payment account identifier of the target payment account.

[0135] Based on this, the first determining module 520 may specifically include: The first determination submodule is used to determine the second user identifier corresponding to the target user based on the wallet system identifier, wallet application identifier and first user identifier; The generation submodule is used to generate a temporary first payment account identifier or a permanent first payment account identifier based on the second user identifier and the second payment account identifier. The first determining submodule is also used to determine temporary card data based on the first card data and the temporary first payment account identifier; or, to determine permanent card data based on the first card data and the permanent first payment account identifier.

[0136] In some embodiments, the payment implementation device 500 may further include: The first receiving module 510 is also used to receive first transaction data sent by the merchant acceptance terminal via the acquiring system after sending the second card data to the wallet application via the wallet system. The first transaction data is generated based on the first transaction amount and the second card data. The second card data is read by the merchant acceptance terminal from the security chip of the user terminal via a contactless method. The first determining module 520 is also used to determine the target payment account of the target user and the target payment account system corresponding to the target payment account based on the first payment account identifier in the first transaction data; The first sending module 540 is also used to send first transaction data to the target payment account system so that the target payment account system can make payment based on the first transaction data.

[0137] In some embodiments, the payment implementation device 500 may further include: The update module is used to update the first transaction amount in the first transaction data to the second transaction amount based on the target discount information corresponding to the target payment account before sending the first transaction data to the target payment account system, thereby obtaining the second transaction data.

[0138] Based on this, the first sending module 540 may specifically include: The sending submodule is also used to send second transaction data to the target payment account system so that the target payment account system can make payment based on the second transaction data.

[0139] In some embodiments, the second card data is permanent card data. Based on this, the payment implementation device 500 may further include: The settings module is used to set the risk control information corresponding to the second card data before sending the second card data to the wallet application via the wallet system. The risk control information includes at least one of the following: number of transactions, transaction validity period, and transaction limit.

[0140] Based on this, the first sending module 540 may specifically include: The verification submodule is used to verify the first transaction data based on risk control information and obtain the verification result; The sending submodule is also used to send the first transaction data to the target payment account system if the verification result is successful.

[0141] In some embodiments, the second card data is temporary card data. Based on this, the payment implementation device 500 may further include: The first receiving module 510 is also used to receive payment response information sent by the target payment account system after sending the first transaction data to the target payment account system when the payment is completed; The first sending module 540 is also configured to, in response to a payment response message, send a card data deletion instruction to the wallet application via the wallet system, instructing the wallet application to delete the second card data from the security chip.

[0142] This application embodiment, in response to a first card transfer request sent by the wallet system for a target user's target payment account, obtains first card data for contactless payment from the payment account system corresponding to the target payment account, and determines second card data based on the first card data and a first payment account identifier used to identify the target user's target payment account. This allows the target payment account to be converted into second card data for contactless payment. Thus, by sending the second card data to the wallet application via the wallet system, and the wallet application storing the second card data in the user terminal's secure chip, it is possible to use the second card data in the secure chip for contactless payment, utilizing the resources in the target payment account. This improves the global prevalence of mobile payments and effectively meets the growing demand for mobile payments overseas.

[0143] Based on the payment implementation method for wallet applications provided in the above embodiments, this application also provides specific implementation methods for payment implementation devices for wallet applications. Please refer to the following embodiments.

[0144] like Figure 6 As shown, a payment implementation device 600 for a wallet application provided in one embodiment of this application includes the following modules: The second receiving module 610 is used to receive the first input for converting the code to the card of the target user's target payment account; The second acquisition module 620 is used to acquire, in response to the first input, a wallet application identifier, a first user identifier of the target user who is logged into the wallet application, and a second payment account identifier of the target payment account. The second generation module 630 is used to generate a third code transfer request based on the wallet application identifier, the first user identifier, and the second payment account identifier. The second sending module 640 is used to send a third code-to-card request to the wallet system so that the wallet system can obtain the wallet system identifier, determine the first payment account identifier based on the wallet application identifier, the wallet system identifier, the first user identifier, and the second payment account identifier, generate a first code-to-card request based on the first payment account identifier, and send the first code-to-card request to the code-to-card system so that the code-to-card system can determine the target payment account of the target user corresponding to the first payment account identifier, and the target payment account system corresponding to the target payment account, and obtain the first card data corresponding to the target payment account from the target payment account system, and determine the second card data based on the first card data and the first payment account identifier, wherein the first card data is used for contactless payment; The second receiving module 610 is also used to receive second card data sent by the code-to-card system via the wallet system; The storage module 650 is used to store the second card data in the security chip of the user terminal, so as to make payment using the resources in the target payment account based on the second card data in the security chip and using a contactless payment method.

[0145] The payment realization device 600 described above will be explained in detail below: In some embodiments, the payment implementation device 600 may further include: The second receiving module 610 is further configured to receive a second input for converting the code to card of the target user's payment account before receiving the first input for converting the code to card of the target user's payment account; The second acquisition module 620 is also used to acquire the wallet application identifier and the first user identifier in response to the second input; The second generation module 630 is also used to generate a fourth code card transfer request based on the wallet application identifier and the first user identifier; The second sending module 640 is further configured to send a fourth code-to-card request to the wallet system so that the wallet system can obtain the wallet system identifier, generate a second code-to-card request based on the wallet application identifier, the wallet system identifier, and the first user identifier, and send the second code-to-card request to the code-to-card system so that the code-to-card system can respond to the second code-to-card request, determine the second user identifier corresponding to the target user based on the wallet system identifier, the wallet application identifier, and the first user identifier, and obtain a list of payment accounts corresponding to the second user identifier, the list of payment accounts including multiple payment accounts that have enabled the code-to-card function; The second receiving module 610 is also used to receive a list of payment accounts sent by the code-to-card system via the wallet system; The display module is used to show the list of payment accounts.

[0146] Based on this, the second receiving module 610 may specifically include: The second receiving submodule is used to receive the first input from selecting the target payment account in the payment account list.

[0147] In some embodiments, the second receiving module 610 may specifically include: The second receiving submodule is also used to receive the list of payment accounts and the corresponding discount information for each payment account sent by the code-to-card system via the wallet system.

[0148] Based on this, the display module may specifically include: The display submodule is used to show the list of payment accounts and promotional information.

[0149] In some embodiments, the second receiving module 610 may specifically include: The second receiving submodule is also used to receive the second card data and its corresponding target discount information sent by the code-to-card system via the wallet system; The prompt submodule is used to output promotional prompts based on the target promotional information.

[0150] In some embodiments, the second card data is temporary card data. Based on this, the payment implementation device 600 may further include: The second receiving module 610 is also used to receive a card data deletion instruction sent by the code-to-card system via the wallet system after storing the second card data in the security chip of the user terminal. The deletion module is used to delete the second card data from the security chip in response to a card data deletion command.

[0151] This application embodiment responds to a first code-to-card request sent by a wallet system to a target user's target payment account via a code-to-card conversion system. It obtains first card data for contactless payment from the payment account system corresponding to the target payment account, and determines second card data based on the first card data and a first payment account identifier used to identify the target user's target payment account. This allows the target payment account to be converted into second card data for contactless payment. Thus, by receiving the second card data sent by the code-to-card conversion system via the wallet system and storing the second card data in the user terminal's security chip, it is possible to use the second card data in the security chip for contactless payment, utilizing the resources in the target payment account. This improves the global adoption of mobile payments and effectively meets the growing demand for mobile payments overseas.

[0152] Based on the payment implementation method for a wallet system provided in the above embodiments, this application also provides specific implementation methods for a payment implementation device for a wallet system. Please refer to the following embodiments.

[0153] like Figure 7As shown, a payment implementation device 700 for a wallet system provided in one embodiment of this application includes the following modules: The third receiving module 710 is used to receive a third code transfer request sent by the wallet application. The third code transfer request includes a wallet application identifier, a first user identifier of the target user who is logged into the wallet application, and a second payment account identifier of the target payment account. The third acquisition module 720 is used to obtain the wallet system identifier in response to the third code transfer request; The third determining module 730 is used to determine the first payment account identifier based on the wallet application identifier, the wallet system identifier, the first user identifier, and the second payment account identifier; The third generation module 740 is used to generate a first code-to-card request based on the first payment account identifier; The third sending module 750 is used to send a first code-to-card request to the code-to-card system so that the code-to-card system can determine the target payment account of the target user corresponding to the first payment account identifier, the target payment account system corresponding to the target payment account, and obtain the first card data corresponding to the target payment account from the target payment account system. Based on the first card data and the first payment account identifier, the system determines the second card data, and the first card data is used for contactless payment. The third receiving module 710 is also used to receive second card data sent by the code-to-card system; The third sending module 750 is also used to send the second card data to the wallet application so that the wallet application stores the second card data in the security chip of the user terminal, and makes payment using the resources in the target payment account based on the second card data in the security chip using a contactless payment method.

[0154] The payment realization device 700 described above will be explained in detail below: In some embodiments, the third determining module 730 may specifically include: The third determination submodule is used to determine the second user identifier corresponding to the target user based on the wallet application identifier, the wallet system identifier, and the first user identifier. The third determination submodule is also used to determine the first payment account identifier based on the second user identifier and the second payment account identifier.

[0155] This application embodiment responds to a first code-to-card request sent by a wallet system for a target user's target payment account via a code-to-card conversion system. It obtains first card data for contactless payment from the payment account system corresponding to the target payment account, and determines second card data based on the first card data and a first payment account identifier used to identify the target user's target payment account. This allows the target payment account to be converted into second card data for contactless payment. Thus, by sending the second card data to the wallet system via the code-to-card conversion system, and by storing the second card data in the user terminal's secure chip, contactless payment can be made using the resources in the target payment account based on the second card data in the secure chip. This improves the global adoption of mobile payments and effectively meets the growing demand for mobile payments overseas.

[0156] Based on the payment implementation method provided in the above embodiments, this application also provides specific implementation methods for electronic devices. Figure 8 A schematic diagram of the structure of an electronic device provided in one embodiment of this application is shown.

[0157] like Figure 8 As shown, the electronic device 800 may include a processor 810 and a memory 820 storing computer program instructions.

[0158] Specifically, the processor 810 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0159] Memory 820 may include mass storage for data or instructions. For example, and not limitingly, memory 820 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 820 may include removable or non-removable (or fixed) media. Where appropriate, memory 820 may be internal or external to electronic device 800. In a particular embodiment, memory 820 is a non-volatile solid-state memory.

[0160] In specific embodiments, the memory 820 may be implemented as a read-only memory (ROM), random access memory (RAM), static storage device, dynamic storage device, etc. The memory 820 may store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 820 and executed by the processor 810. The processor 810 implements any of the payment implementation methods in the above embodiments by reading and executing the computer program instructions stored in the memory 820.

[0161] The processor 810 reads and executes computer program instructions stored in the memory 820 to implement any of the payment implementation methods in the above embodiments.

[0162] In one example, the electronic device 800 may also include a communication interface 830 and a bus 840. For example, Figure 8 As shown, the processor 810, memory 820, and communication interface 830 are connected through bus 840 and complete communication with each other.

[0163] The communication interface 830 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0164] Bus 840 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-E) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 840 may include one or more buses. Although specific buses are described and illustrated in the embodiments of this application, this application considers any suitable bus or interconnection.

[0165] For example, the electronic device 800 can be a mobile phone, tablet computer, laptop computer, handheld computer, in-vehicle electronic device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc.

[0166] The electronic device can execute the payment implementation method in the embodiments of this application, thereby achieving a combination Figures 2 to 4 The payment implementation method described herein, and the beneficial effects of the corresponding method embodiments, will not be elaborated further here.

[0167] Furthermore, in conjunction with the payment implementation methods in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the payment implementation methods in the above embodiments. Examples of such computer-readable storage media include non-transitory computer-readable storage media, such as read-only memory (ROM).

[0168] The computer program instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the payment implementation method as shown in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0169] Based on the payment implementation methods in the above embodiments, this application embodiment can provide a computer program product for implementation. When the instructions in this computer program product are executed by the processor of an electronic device, they implement any of the payment implementation methods in the above embodiments.

[0170] The computer program products of the above embodiments are used to implement the payment implementation method shown in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0171] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0172] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0173] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0174] The aspects of this application have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0175] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A payment implementation method, characterized in that, Applied to a code-to-card system, the method includes: Receive a first code-to-card request sent by the wallet system. The first code-to-card request includes a first payment account identifier, which is used to identify the target user's target payment account. In response to the first code-to-card request, the target payment account of the target user corresponding to the first payment account identifier and the target payment account system corresponding to the target payment account are determined. Obtain first card data corresponding to the target payment account from the target payment account system; the first card data is used for contactless payment. Based on the first card data and the first payment account identifier, the second card data is determined; The second card data is sent to the wallet application via the wallet system, so that the wallet application stores the second card data in the security chip of the user terminal, and makes a payment using the resources in the target payment account based on the second card data in the security chip using a contactless payment method.

2. The method according to claim 1, characterized in that, Before receiving the first code transfer request sent by the wallet system, the method further includes: Receive a second code-to-card request sent by the wallet system, wherein the second code-to-card request includes a wallet system identifier, a wallet application identifier, and a first user identifier of the target user who is logged into the wallet application; In response to the second code-to-card request, a second user identifier corresponding to the target user is determined based on the wallet system identifier, the wallet application identifier, and the first user identifier; Obtain a list of payment accounts corresponding to the second user identifier, wherein the list of payment accounts includes multiple payment accounts that have enabled the code-to-card conversion function; The wallet system sends the payment account list to the wallet application, causing the wallet application to display the payment account list. It receives a first input to select a target payment account from the payment account list. In response to the first input, it obtains the wallet application identifier, the first user identifier, and a second payment account identifier of the target payment account. Based on the wallet application identifier, the first user identifier, and the second payment account identifier, it generates a third code-to-card transfer request and sends the third code-to-card transfer request to the wallet system, causing the wallet system to obtain the wallet system identifier. Based on the wallet application identifier, the wallet system identifier, the first user identifier, and the second payment account identifier, it determines a first payment account identifier. Based on the first payment account identifier, it generates a first code-to-card transfer request and sends the first code-to-card transfer request to the code-to-card transfer system.

3. The method according to claim 2, characterized in that, Before sending the list of payment accounts to the wallet application via the wallet system, the method further includes: Obtain the discount information corresponding to each of the multiple payment accounts; Sending the payment account list to the wallet application via the wallet system, so that the wallet application displays the payment account list, includes: The wallet system sends the list of payment accounts and the offer information to the wallet application so that the wallet application can display the list of payment accounts and the offer information.

4. The method according to claim 3, characterized in that, Sending the second card data to the wallet application via the wallet system includes: The wallet system sends the second card data and its corresponding target discount information to the wallet application, so that the wallet application can output discount prompt information based on the target discount information.

5. The method according to claim 1, characterized in that, The second card data includes temporary card data and permanent card data. The first payment account identifier includes a wallet system identifier, a wallet application identifier, a first user identifier of the target user logged into the wallet application, and a second payment account identifier of the target payment account. Determining the second card data based on the first card data and the first payment account identifier includes: Based on the wallet system identifier, the wallet application identifier, and the first user identifier, the second user identifier corresponding to the target user is determined; Based on the second user identifier and the second payment account identifier, generate a temporary first payment account identifier or a permanent first payment account identifier; The temporary card data is determined based on the first card data and the temporary first payment account identifier; or, The permanent card data is determined based on the first card data and the permanent first payment account identifier.

6. The method according to any one of claims 1-5, characterized in that, After sending the second card data to the wallet application via the wallet system, the method further includes: The merchant terminal receives first transaction data sent via the acquiring system. The first transaction data is generated based on a first transaction amount and second card data. The second card data is read by the merchant terminal from the security chip of the user terminal via a contactless method. Based on the first payment account identifier in the first transaction data, the target user's target payment account and the target payment account system corresponding to the target payment account are determined; The first transaction data is sent to the target payment account system so that the target payment account system makes a payment based on the first transaction data.

7. The method according to claim 6, characterized in that, Before sending the first transaction data to the target payment account system, the method further includes: Based on the target discount information corresponding to the target payment account, the first transaction amount in the first transaction data is updated to the second transaction amount to obtain the second transaction data; Sending the first transaction data to the target payment account system includes: The second transaction data is sent to the target payment account system so that the target payment account system can make a payment based on the second transaction data.

8. The method according to claim 6, characterized in that, The second card data is permanent card data. Before sending the second card data to the wallet application via the wallet system, the method further includes: Set risk control information corresponding to the second card data, wherein the risk control information includes at least one of the following: number of transactions, transaction validity period, and transaction limit; Sending the first transaction data to the target payment account system includes: Based on the risk control information, the first transaction data is verified to obtain the verification result; If the verification result is successful, the first transaction data is sent to the target payment account system.

9. The method according to claim 6, characterized in that, The second card data is temporary card data. After sending the first transaction data to the target payment account system, the method further includes: Receive payment response information sent by the target payment account system upon completion of payment; In response to the payment response information, a card data deletion instruction is sent to the wallet application via the wallet system to instruct the wallet application to delete the second card data from the security chip.

10. A payment implementation method, characterized in that, Applied to wallet applications, the method includes: Receive the first input for converting the code to a card for the target user's target payment account; In response to the first input, obtain the wallet application identifier, the first user identifier of the target user who is logged into the wallet application, and the second payment account identifier of the target payment account; Based on the wallet application identifier, the first user identifier, and the second payment account identifier, a third code transfer request is generated; The system sends the third code-to-card request to the wallet system so that the wallet system can obtain the wallet system identifier. Based on the wallet application identifier, the wallet system identifier, the first user identifier, and the second payment account identifier, the system determines the first payment account identifier. Based on the first payment account identifier, the system generates the first code-to-card request and sends the first code-to-card request to the code-to-card system so that the code-to-card system can determine the target payment account of the target user corresponding to the first payment account identifier, as well as the target payment account system corresponding to the target payment account. The system also obtains the first card data corresponding to the target payment account from the target payment account system and determines the second card data based on the first card data and the first payment account identifier. The first card data is used for contactless payment. Receive the second card data sent by the code-to-card system via the wallet system; The second card data is stored in the security chip of the user terminal, so that, based on the second card data in the security chip, the target payment account can be used for payment using a contactless payment method.

11. The method according to claim 10, characterized in that, Before receiving the first input for code-to-card conversion of the target user's target payment account, the method further includes: Receive a second input for converting the code to a card for the target user's payment account; In response to the second input, obtain the wallet application identifier and the first user identifier; Based on the wallet application identifier and the first user identifier, a fourth code transfer request is generated; The system sends the fourth code-to-card request to the wallet system so that the wallet system can obtain the wallet system identifier. Based on the wallet application identifier, the wallet system identifier, and the first user identifier, it generates a second code-to-card request and sends the second code-to-card request to the code-to-card system so that the code-to-card system responds to the second code-to-card request. Based on the wallet system identifier, the wallet application identifier, and the first user identifier, it determines the second user identifier corresponding to the target user and obtains a list of payment accounts corresponding to the second user identifier. The list of payment accounts includes multiple payment accounts that have enabled the code-to-card function. Receive the list of payment accounts sent by the code-to-card system via the wallet system; Display the list of payment accounts; The receiving of the first input for converting the code to a card for the target user's target payment account includes: Receive the first input to select the target payment account from the list of payment accounts.

12. The method according to claim 11, characterized in that, The receiving of the payment account list sent by the code-to-card system via the wallet system includes: Receive the list of payment accounts and the corresponding discount information for each of the multiple payment accounts sent by the code-to-card system via the wallet system; The display of the payment account list includes: Display the list of payment accounts and the promotional information.

13. The method according to claim 11, characterized in that, Receiving the second card data sent by the code-to-card system via the wallet system includes: Receive the second card data and its corresponding target discount information sent by the code-to-card system via the wallet system; Based on the target discount information, output discount reminder information.

14. The method according to claim 10, characterized in that, The second card data is temporary card data. After storing the second card data in the security chip of the user terminal, the method further includes: Receive the card data deletion command sent by the code-to-card system via the wallet system; In response to the card data deletion command, the second card data is deleted from the security chip.

15. A payment implementation method, characterized in that, Applied to a wallet system, the method includes: Receive a third code transfer request sent by a wallet application, wherein the third code transfer request includes a wallet application identifier, a first user identifier of the target user who is logged into the wallet application, and a second payment account identifier of the target payment account; In response to the third code transfer request, obtain the wallet system identifier; The first payment account identifier is determined based on the wallet application identifier, the wallet system identifier, the first user identifier, and the second payment account identifier; Based on the first payment account identifier, a first code transfer request is generated; Send the first code-to-card request to the code-to-card system so that the code-to-card system can determine the target payment account of the target user corresponding to the first payment account identifier, and the target payment account system corresponding to the target payment account, and obtain the first card data corresponding to the target payment account from the target payment account system, and determine the second card data based on the first card data and the first payment account identifier, wherein the first card data is used for contactless payment; Receive the second card data sent by the code-to-card system; The second card data is sent to the wallet application so that the wallet application stores the second card data in the security chip of the user terminal, and then uses the resources in the target payment account to make payment based on the second card data in the security chip using a contactless payment method.

16. The method according to claim 15, characterized in that, The step of determining the first payment account identifier based on the wallet application identifier, the wallet system identifier, the first user identifier, and the second payment account identifier includes: Based on the wallet application identifier, the wallet system identifier, and the first user identifier, the second user identifier corresponding to the target user is determined; The first payment account identifier is determined based on the second user identifier and the second payment account identifier.

17. A payment realization device, characterized in that, The device, used in a code-to-card system, includes: The first receiving module is used to receive a first code-to-card request sent by the wallet system. The first code-to-card request includes a first payment account identifier, which is used to identify the target user's target payment account. The first determining module is used to, in response to the first code-to-card request, determine the target payment account of the target user corresponding to the first payment account identifier, and the target payment account system corresponding to the target payment account; The first acquisition module is used to acquire first card data corresponding to the target payment account from the target payment account system. The first card data is used for contactless payment. The first determining module is further configured to determine the second card data based on the first card data and the first payment account identifier; The first sending module is used to send the second card data to the wallet application via the wallet system, so that the wallet application stores the second card data in the security chip of the user terminal, and makes payment using the resources in the target payment account based on the second card data in the security chip using a contactless payment method.

18. A payment realization device, characterized in that, For use in wallet applications, the device includes: The second receiving module is used to receive the first input for converting the code to the card of the target user's target payment account; The second acquisition module is used to acquire, in response to the first input, a wallet application identifier, a first user identifier of the target user who is logged into the wallet application, and a second payment account identifier of the target payment account. The second generation module is used to generate a third code-to-card request based on the wallet application identifier, the first user identifier, and the second payment account identifier; The second sending module is used to send the third code-to-card request to the wallet system, so that the wallet system can obtain the wallet system identifier, determine the first payment account identifier based on the wallet application identifier, the wallet system identifier, the first user identifier, and the second payment account identifier, generate the first code-to-card request based on the first payment account identifier, and send the first code-to-card request to the code-to-card system, so that the code-to-card system can determine the target payment account of the target user corresponding to the first payment account identifier, and the target payment account system corresponding to the target payment account, and obtain the first card data corresponding to the target payment account from the target payment account system, and determine the second card data based on the first card data and the first payment account identifier, wherein the first card data is used for contactless payment; The second receiving module is further configured to receive the second card data sent by the code-to-card system via the wallet system; The storage module is used to store the second card data in the security chip of the user terminal, so as to make payment using the resources in the target payment account based on the second card data in the security chip using a contactless payment method.

19. A payment realization device, characterized in that, The device, used in a wallet system, includes: The third receiving module is used to receive a third code transfer request sent by the wallet application. The third code transfer request includes a wallet application identifier, a first user identifier of the target user who is logged into the wallet application, and a second payment account identifier of the target payment account. The third acquisition module is used to acquire the wallet system identifier in response to the third code transfer request; The third determining module is used to determine the first payment account identifier based on the wallet application identifier, the wallet system identifier, the first user identifier, and the second payment account identifier; The third generation module is used to generate a first code-to-card request based on the first payment account identifier; The third sending module is used to send the first code-to-card request to the code-to-card system so that the code-to-card system can determine the target payment account of the target user corresponding to the first payment account identifier, and the target payment account system corresponding to the target payment account, and obtain the first card data corresponding to the target payment account from the target payment account system, and determine the second card data based on the first card data and the first payment account identifier, wherein the first card data is used for contactless payment; The third receiving module is also used to receive the second card data sent by the code-to-card system; The third sending module is further configured to send the second card data to the wallet application, so that the wallet application stores the second card data in the security chip of the user terminal, and makes payment using the resources in the target payment account based on the second card data in the security chip using a contactless payment method.

20. An electronic device, characterized in that, The electronic device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the payment implementation method as described in any one of claims 1-9, 10-14, or 15-16.

21. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the payment implementation method as described in any one of claims 1-9, 10-14, or 15-16.

22. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the payment implementation method as described in any one of claims 1-9, 10-14, or 15-16.

Images