Payment method and system, and related apparatus

Abstract

Disclosed in the present application are a payment method and system, and a related apparatus. The method is applied to an electronic device, said method comprising: receiving first payment information sent by a payment collection device upon entering a radio frequency field of the payment collection device , the first payment information including the identifiers of one or more payment modes supported by the payment collection device; determining a first payment mode on the basis of the first payment information; determining a first authorization code corresponding to the first payment mode, the first authorization code being used for authorizing a server to complete a payment by means of the first payment mode; encrypting the first authorization code by means of an asymmetric cryptography algorithm on the basis of a first random number and a first public key to obtain a first payment permit; generating key metadata on the basis of the first random number and the asymmetric cryptography algorithm; and sending a first payment account, the first payment permit, and the key metadata, which correspond to the first payment mode, to the server, the key metadata being used for decrypting the first authorization code from the first payment permit. In this way, the first authorization code can be encrypted on the basis of a random key, thereby improving payment security.

Description

A payment method, system and related device

[0001] This application claims priority to Chinese Patent Application No. 202410980446.9, filed on July 19, 2024, entitled "A Payment Method, System and Related Device", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, and in particular to a payment method, system and related apparatus. Background Technology

[0003] With the continuous development of communication technology, communication plays an increasingly important role in daily life. For example, in daily consumption scenarios, users can use communication technology to make quick payments.

[0004] When a user makes a payment using an electronic device, the electronic device needs to send a payment authorization code to the payment cloud server. The payment authorization code is used to authorize the payment cloud server to deduct the corresponding amount from the payment account corresponding to the electronic device to complete the payment.

[0005] However, payment authorization codes are easily leaked during transmission, resulting in poor security. Summary of the Invention

[0006] This application provides a payment method, system, and related apparatus that encrypts the payment authorization code using a randomly generated key, thereby improving payment security.

[0007] In a first aspect, this application provides a payment method applied to an electronic device. The method includes: after entering the radio frequency field of a receiving device, receiving first payment information sent by the receiving device, the first payment information including identifiers of one or more payment methods supported by the receiving device; determining a first payment method from the one or more payment methods supported by the receiving device; determining a first authorization code corresponding to the first payment method, the first authorization code being used to authorize a server to complete payment using the first payment method; encrypting the first authorization code using an asymmetric encryption algorithm based on a first random number and a first public key to obtain a first payment permission; generating key metadata based on the first random number and the asymmetric encryption algorithm; and sending a first payment account, a first payment permission, and key metadata to a server, the first payment account being the payment account corresponding to the first payment method, and the key metadata being used to decrypt the first authorization code from the first payment permission.

[0008] In this way, electronic devices can generate a random key for each payment and use that key to encrypt the payment authorization code. This improves the security of the payment authorization code during transmission and ensures payment security.

[0009] In one possible implementation, the first authorization code is encrypted using an asymmetric encryption algorithm based on the first random number and the first public key to obtain the first payment license. Specifically, this includes: determining the first key using an asymmetric encryption algorithm based on the first random number and the first public key; encrypting the first authorization code based on the first key to obtain the first ciphertext; and determining the first payment license based on the first ciphertext.

[0010] In this way, the first payment authorization can carry the first ciphertext, which is based on the encrypted payment authorization code.

[0011] In one possible implementation, the method further includes: determining a second key based on a first random number and a first public key using an asymmetric encryption algorithm; determining a first check value based on a first ciphertext and the second key, the first check value being used to verify the integrity of the first ciphertext; and determining a first payment authorization based on the first ciphertext, specifically including: determining a first payment authorization based on the first ciphertext and the first check value.

[0012] Thus, the first payment authorization may also include an integrity check value (i.e., the first check value) of the payment authorization code, which can verify the integrity of the first ciphertext and determine whether the first ciphertext has been tampered with during transmission.

[0013] In one possible implementation, determining the first payment authorization based on the first ciphertext and the first verification value specifically includes: encrypting the first verification value based on the first key to obtain a second verification value; and determining the first payment authorization based on the first ciphertext and the second verification value, wherein the first payment authorization includes the first ciphertext and the second verification value.

[0014] In this way, the first payment authorization can carry an encrypted integrity verification value, i.e., the second verification value. Transmitting the encrypted integrity verification value can improve payment security and prevent leakage during transmission.

[0015] In one possible implementation, the key metadata and the first random number are a public-private key pair. The key metadata is used to decrypt the first authorization code from the first payment license with the first private key. The first private key and the first public key are a public-private key pair.

[0016] In one possible implementation, the key metadata includes a first key and a second key.

[0017] In one possible implementation, sending the first payment account, first payment license, and key metadata to the server specifically includes: sending the first payment account, first payment license, and key metadata to the server via the payment receiving device.

[0018] In this way, electronic devices can interact with the server through the payment device to complete the payment.

[0019] In one possible implementation, the first payment information further includes a first amount; after determining the first payment method from one or more payment methods supported by the receiving device, the method further includes: determining a second amount based on the first payment method and the first amount, the second amount being the amount paid by the electronic device through the first payment method; sending the first payment account, the first payment license, and key metadata to the server through the receiving device, specifically including: if the first payment method enables password-free payment, and the second amount is less than or equal to the password-free payment limit of the first payment method, sending the first payment account, the first payment license, and key metadata to the server through the receiving device.

[0020] In this way, in the context of password-free payment, electronic devices can interact with the server through the payment device to complete the payment.

[0021] In one possible implementation, sending the first payment account, first payment license, and key metadata to the server specifically includes: sending the first payment account to the server via the payment device; and sending the first payment license and key metadata to the server.

[0022] In this way, electronic devices can also send the first payment authorization and key metadata to the server through a communication connection.

[0023] In one possible implementation, the first payment information further includes a first amount; after determining the first payment method from one or more payment methods supported by the receiving device, the method further includes: determining a second amount based on the first payment method and the first amount, the second amount being the amount paid by the electronic device through the first payment method; sending a first payment account to the server through the receiving device, specifically including: if the first payment method does not have password-free payment enabled, or the second amount is greater than the password-free payment limit of the first payment method, sending the first payment account to the server through the receiving device; sending a first payment authorization and key metadata to the server, specifically including: receiving and responding to a first operation by the user, sending the first payment authorization and key metadata to the server, the first operation being used to complete payment verification.

[0024] In this way, in non-password-free payment scenarios, when a user completes payment verification, the electronic device may leave the radio frequency field of the receiving device. In this case, the electronic device can send the first payment authorization and key metadata to the server after the user completes payment verification.

[0025] In one possible implementation, before sending the first payment authorization and key metadata to the server, the method further includes: receiving a first request sent by the server, the first request being used to request the electronic device to complete payment verification.

[0026] In this way, electronic devices can also respond to the first request sent by the server by sending the first payment authorization and key metadata to the server.

[0027] In one possible implementation, the first payment information further includes a first amount and a first receiving account; the method further includes sending the first amount and the first receiving account to the server.

[0028] In this way, during the payment process, the electronic device can obtain the initial amount and the initial receiving account through interaction with the receiving device, and complete the payment based on the interaction between the electronic device and the server. Using this method, the electronic device does not need to interact with the server through the receiving device; therefore, it is unnecessary to consider whether the electronic device leaves the radio frequency field of the receiving device during the payment process.

[0029] In one possible implementation, the method further includes: receiving a first notification sent by a server, the first notification being used to notify the electronic device that the payment was successful.

[0030] In this way, after the payment is successful, the electronic device can receive the first notification through the communication connection with the server.

[0031] In one possible implementation, receiving the first notification sent by the server specifically includes: receiving the first notification sent by the server through the payment device.

[0032] In this way, after the payment is successful, the electronic device can receive the first notification sent by the server through the receiving device.

[0033] In one possible implementation, the first authorization code is used to authorize the server to complete the payment of the first payment method, specifically including: the first authorization code is used to authorize the server to complete the payment of the first payment method within a first time period.

[0034] In this way, the first authorization code can have an expiration time, meaning that the first authorization code becomes invalid after the first time period ends, thus improving the security of payment.

[0035] In one possible implementation, before receiving the first payment information sent by the receiving device, the method further includes: receiving a probe frame sent by the receiving device, the probe frame indicating that the receiving device supports a specified NFC protocol; sending a probe ACK frame to the receiving device, the probe ACK frame indicating that the electronic device supports the specified NFC protocol; receiving a pick frame sent by the receiving device, the pick frame carrying device feature information of the receiving device, the device feature information including a service identifier and a device organization identifier, wherein the service identifier indicates the type of NFC service supported by the receiving device, and the device organization identifier indicates the manufacturer using the receiving device to provide NFC services; determining, based on the device feature information of the receiving device, that the type of NFC service of the receiving device is codeless payment; and sending a pick ACK frame to the receiving device, the pick ACK frame indicating that the electronic device has determined the type of NFC service of the receiving device.

[0036] In this way, the electronic device can interact with the receiving device through the first protocol to determine that the receiving device's service type is NFC service.

[0037] In one possible implementation, asymmetric encryption algorithms may include elliptic curve algorithms, RSA algorithms, etc.

[0038] Secondly, this application provides a payment method applied to a server, the method comprising: the server receiving a first payment account, a first payment license, and key metadata; the server receiving a first receiving account and a first amount; and the server completing the payment based on the first receiving account, the first amount, the first payment account, the first payment license, and the key metadata.

[0039] In this way, the server can complete the payment based on the first receiving account, the first amount, the first payment account, the first payment license, and key metadata.

[0040] In one possible payment method, the server receives first payment account, first payment authorization, and key metadata, specifically including: the server receiving first payment account, first payment authorization, and key metadata sent by an electronic device.

[0041] In this way, the electronic device can send the first payment authorization and key metadata to the server when it is determined that the payment is password-free, or when it is determined that the user has completed payment verification.

[0042] In another possible payment method, the server receives first payment account, first payment authorization, and key metadata, specifically including: the server receiving first payment account, first payment authorization, and key metadata sent by an electronic device through a payment receiving device.

[0043] In this way, electronic devices can interact with the server through the payment device to complete the payment.

[0044] In one possible payment method, the server receives a first receiving account and a first amount, specifically including: the server receiving the first receiving account and the first amount sent by the receiving device.

[0045] In one possible payment method, the server receives a first receiving account and a first amount, specifically including: the server receiving the first receiving account and the first amount sent by the receiving device via an electronic device.

[0046] In this way, the receiving device can first send the first receiving account and the first amount to the electronic device, and then the electronic device interacts with the server to complete the payment.

[0047] In one possible implementation, the server completes the payment based on the first receiving account, the first amount, the first payment account, the first payment license, and key metadata, specifically including: the server decrypting the first authorization code from the first payment license based on the key metadata; and the server completing the payment based on the first authorization code, the first payment account, the first receiving account, and the first amount.

[0048] In this way, after the server decrypts the first authorization code from the first payment license based on the key metadata, it can deduct the payment from the first payment account based on the first authorization code to complete the payment.

[0049] In one possible implementation, the server decrypts the first authorization code from the first payment license based on the key metadata, specifically including: the server decrypts the first authorization code from the first payment license using an asymmetric encryption algorithm based on the key metadata and the first private key.

[0050] In this way, the server can decrypt the first payment license using the first private key and key metadata, determine the first authorization code, and complete the payment.

[0051] Thirdly, this application provides a payment system, including an electronic device, a receiving device, and a server; the electronic device is used to receive first payment information sent by the receiving device after entering the radio frequency field of the receiving device, the first payment information including identifiers of one or more payment methods supported by the receiving device; the electronic device is also used to determine a first payment method from the one or more payment methods supported by the receiving device; the electronic device is also used to determine a first authorization code corresponding to the first payment method, the first authorization code being used to authorize the server to complete the payment of the first payment method; the electronic device is also used to encrypt the first authorization code based on a first random number and a first public key using an asymmetric encryption algorithm to obtain a first payment license; the electronic device is also used to generate key metadata based on the first random number and the asymmetric encryption algorithm; the electronic device is also used to send a first payment account, a first payment license, and key metadata corresponding to the first payment method to the server, the key metadata being used to decrypt the first authorization code from the first payment license; the receiving device is used to send the first payment information to the electronic device; the server is used to receive the first payment account, the first payment license, and the key metadata; the server is also used to receive a first receiving account and a first amount; the server is also used to complete the payment based on the first receiving account, the first amount, the first payment account, the first payment license, and the key metadata.

[0052] In one possible implementation, the server is further configured to complete the payment based on the first receiving account, the first amount, the first payment account, the first payment license, and key metadata, specifically including: the server is further configured to decrypt the first authorization code from the first payment license based on the key metadata; the server is further configured to complete the payment based on the first authorization code, the first payment account, the first receiving account, and the first amount.

[0053] In one possible implementation, the server is further configured to decrypt the first authorization code from the first payment license based on the key metadata, specifically including: the server is further configured to decrypt the first authorization code from the first payment license using an asymmetric encryption algorithm based on the key metadata and the first private key.

[0054] In one possible implementation, the payment device is also used to send a first payment account and a first amount to the server.

[0055] In one possible implementation, the first payment information also includes a first receiving account and a first amount; the electronic device is also used to send the first receiving account and the first amount to the server.

[0056] In one possible implementation, the electronic device is also used to send the first payment account, first payment license, and key metadata to the server, specifically including: the electronic device is also used to send the first payment account, first payment license, and key metadata to the server through the receiving device.

[0057] In one possible implementation, the electronic device is further used to send the first payment account, the first payment license, and key metadata to the server, specifically including: the electronic device is further used to send the first payment account to the server via the receiving device; the electronic device is further used to send the first payment license and key metadata to the server.

[0058] Fourthly, this application provides an electronic device, including: one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer instructions, which, when the one or more processors execute the computer instructions, implement the payment method in any possible implementation of any of the above aspects.

[0059] Fifthly, this application provides a chip system comprising: a processing circuit and an interface circuit, wherein the interface circuit is used to receive code instructions and transmit them to the processing circuit, and the processing circuit is used to execute the code instructions to perform the payment method in any possible implementation of any of the above aspects.

[0060] Sixthly, this application provides a readable storage medium storing computer instructions that, when executed by a processor, implement the payment method in any of the possible implementations of any of the above aspects.

[0061] In a seventh aspect, this application provides a computer program product, including computer instructions, which, when executed by a processor, implement the payment method in any of the possible implementations of any of the above aspects.

[0062] The beneficial effects of aspects three through seven can be referenced from the beneficial effects of aspects one and two mentioned above. Attached Figure Description

[0063] Figure 1 is a schematic diagram of the working principle of NFC provided in an embodiment of this application;

[0064] Figure 2A is a schematic diagram of the system architecture of a payment system provided in an embodiment of this application;

[0065] Figure 2B is a schematic diagram of the communication interaction between an electronic device and a payment cloud server provided in an embodiment of this application;

[0066] Figure 2C is a schematic diagram of the device configuration of an electronic device provided in an embodiment of this application;

[0067] Figure 2D is a schematic diagram of the device configuration of a card reader in a payment device provided in an embodiment of this application;

[0068] Figure 2E is a schematic diagram of the positional relationship of an electronic device communicating with a card reader based on NFC technology according to an embodiment of this application;

[0069] Figure 3A is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0070] Figure 3B is a schematic diagram of a layered architecture of an NFC protocol stack provided in an embodiment of this application;

[0071] Figure 4A is a schematic diagram of the scheme logic of a payment method provided in an embodiment of this application;

[0072] Figure 4B is a schematic diagram of the scheme logic of a payment method provided in an embodiment of this application;

[0073] Figure 4C is a schematic diagram of the plaintext structure of a payment authorization code provided in an embodiment of this application;

[0074] Figure 4D is a schematic diagram of the structure of the encrypted text of a payment authorization code provided in an embodiment of this application;

[0075] Figure 4E is a schematic diagram of a payment license provided in an embodiment of this application;

[0076] Figure 5A is a logical schematic diagram of an encryption algorithm for a payment authorization code provided in an embodiment of this application;

[0077] Figure 5B is a schematic diagram of the process by which an electronic device encrypts a payment authorization code according to an embodiment of this application;

[0078] Figure 6A is a logical schematic diagram of a payment authorization code decryption algorithm provided in an embodiment of this application;

[0079] Figure 6B is a schematic diagram of the process of a payment cloud server decrypting an encrypted payment authorization code according to an embodiment of this application;

[0080] Figure 7 is a flowchart illustrating a payment method provided in an embodiment of this application;

[0081] Figure 8 is a schematic diagram of a process provided by an embodiment of this application, in which an electronic device completes payment based on whether or not to use password-free payment after determining the payment method;

[0082] Figure 9 is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0083] Figures 10-13 are schematic diagrams of a set of communication devices provided in the embodiments of this application;

[0084] Figure 14 is a flowchart illustrating a payment method provided in an embodiment of this application. Detailed Implementation

[0085] The technical solutions in the embodiments of this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0086] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0087] The term "user interface (UI)" used in the following embodiments of this application refers to the medium interface through which an application or operating system interacts and exchanges information with the user. It realizes the conversion between the internal form of information and the form that the user can accept. The user interface is source code written in a specific computer language such as Java or Extensible Markup Language (XML). The interface source code is parsed and rendered on the electronic device, ultimately presenting content that the user can recognize. A common form of user interface is the graphical user interface (GUI), which refers to a user interface related to computer operation displayed graphically. It can be visible interface elements such as text, icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, and widgets displayed on the screen of an electronic device.

[0088] The working principle of near field communication (NFC) technology in the embodiments of this application is described below.

[0089] Figure 1 shows a schematic diagram of the working principle of NFC provided in an embodiment of this application.

[0090] As shown in Figure 1, the two parties communicating using NFC technology can include a proximity coupling device (PCD) (also known as an NFC reader) and a proximity integrated circuit card (PICC). The PCD can achieve contactless communication with the PICC in close proximity. The PCD and PICC can allow near-field communication at specific data rates (e.g., 106, 212, 424, or 848 kilobits per second, kbps) and specific frequencies (e.g., 13.56 MHz). Communication between the PCD and PICC can occur at close range, for example, within a range of approximately 2 to 4 centimeters.

[0091] The PCD (Polymer Capacitor) can generate high-frequency alternating current to produce a radio frequency (RF) field of a specified frequency (e.g., 13.56 MHz), and transmit data to the PICC (Peripherally Input Cell) via this RF field. When the PICC is near the PCD, it can sense the RF field emitted by the PCD. Upon entering the RF field, the PICC can obtain energy from the PCD's RF field through electromagnetic induction, and use this energy to generate electricity to drive the internal circuitry of the PICC, thus enabling data transmission from the PCD to the PICC. Alternatively, the PICC can also transmit data to the PCD by modulating the RF field with a load, achieving data transmission from the PICC to the PCD.

[0092] In the embodiments of this application, the PICC can be a physical NFC tag card. Some NFC devices (e.g., mobile phones, tablets, smartwatches, and other electronic devices) can also simulate themselves as PICCs that conform to NFC-related standards through the data of NFC emulation cards to realize the functions of PICCs and communicate with the PCD based on NFC technology.

[0093] The following describes the system architecture of a payment system 10 provided in an embodiment of this application.

[0094] Figure 2A shows a schematic diagram of the system architecture of a payment system 10 provided in an embodiment of this application.

[0095] As shown in Figure 2A, the payment system 10 may include an electronic device 100, a payment receiving device 200, and a payment cloud server 300. The electronic device 100 and the payment receiving device 200 may have NFC functionality. When the electronic device 100 enters the radio frequency field of the payment receiving device 200, the electronic device 100 can communicate with the payment receiving device 200 based on NFC technology. The electronic device 100 can also establish a wireless communication connection with the payment cloud server 300, and the payment receiving device 200 can also establish a communication connection with the payment cloud server 300.

[0096] When the electronic device 100 enters the radio frequency field of the payment receiving device 200 (e.g., comes into contact with the payment receiving device 200), the electronic device 100 can communicate with the payment receiving device 200 based on NFC technology to determine the final payment method and send the payment account corresponding to the payment method to the payment receiving device 200. In some embodiments, after determining the payment method, the electronic device 100 can generate a one-time random key, encrypt the payment authorization code based on the random key, and send the encrypted payment authorization code to the payment receiving device 200. In other embodiments, the electronic device 100 can also generate a one-time random key after receiving a payment verification request from the payment cloud server 300, encrypt the payment authorization code based on the random key, and send the encrypted payment authorization code to the payment cloud server 300.

[0097] In some embodiments, the payment receiving device 200 may include a card reader 210 (e.g., a POS machine) and a merchant backend server 220. The card reader 210 may have NFC functionality to enable communication with the electronic device 100; the merchant backend server 220 may communicate with the payment cloud server 300. In other embodiments, the payment receiving device 200 may include only one device, which can communicate with both the payment cloud server 300 and the electronic device 100 via NFC technology. The payment receiving device 200 can determine the final payment method based on its communication with the electronic device 100. The payment receiving device 200 can also receive the payment account corresponding to the payment method sent by the electronic device 100. After determining the final payment method and the corresponding payment account, the payment receiving device 200 can send the payment account to the payment cloud server 300 based on the payment method. In some embodiments, if the payment receiving device 200 receives an encrypted payment authorization code from the electronic device 100, the payment receiving device 200 can also send the encrypted payment authorization code to the payment cloud server 300.

[0098] The payment cloud server 300 can be a server cluster, which may include one or more servers (or server modules). The communication and interaction methods between each server in the payment cloud server 300 and the electronic device 100 can be referred to the relevant description in the embodiment shown in Figure 2B below, and will not be detailed here. In some embodiments, the payment cloud server 300 can deduct funds from the payment account and transfer the payable amount to the payment account based on the payable amount, payment account, payment account, and payment authorization code sent by the payment receiving device 200. In some embodiments, after receiving the payable amount, payment account, and payment account sent by the payment receiving device 200, the payment cloud server 300 can obtain the encrypted payment authorization code from the electronic device 100 based on the communication connection with the electronic device 100, and perform the deduction operation only after decrypting the payment authorization code and confirming its validity.

[0099] It is understood that the embodiment shown in Figure 2A above is only an example. In the embodiments of this application, the payment system 10 may also include more, fewer or different electronic devices than the above embodiments, and this application does not limit it.

[0100] The following describes the communication interaction between various applications in an electronic device 100 and various servers (or server modules) in a payment cloud server 300, as provided in an embodiment of this application.

[0101] For example, Figure 2B shows a schematic diagram of communication interaction between an electronic device 100 and a payment cloud server 300 provided in an embodiment of this application.

[0102] As shown in Figure 2B, the electronic device 100 may have one or more payment applications installed, such as payment application A and payment application B. Each payment application may include one or more payment mini-programs, and each payment mini-program may correspond to a payment method. For example, payment application A may include payment methods such as bank card D1 and balance D2, while payment application B may include payment methods such as membership card D3.

[0103] The payment cloud server 300 may include one or more servers, such as server 310, server 320, and server 330. Each server may also include one or more sub-servers; for example, server 310 may include sub-server 311 and sub-server 312, etc.

[0104] Server 310 can be the server of payment application A, and electronic device 100 can interact with server 310 through payment application A. Specifically, sub-server 311 in server 310 can interact with the payment mini-program corresponding to bank card D1 in payment application A, and sub-server 312 can interact with the payment mini-program corresponding to balance D2 in payment application A. Furthermore, server 330 can be the server of the bank corresponding to bank card D1. When electronic device 100 interacts with sub-server 311 through the payment mini-program corresponding to bank card D1 in payment application A, it can also interact with server 330 through sub-server 311. Server 320 can be the server of payment application B. Electronic device 100 can interact with server 320 through payment application B.

[0105] It is understood that the embodiment shown in Figure 2B is merely an illustrative example. The electronic device 100 can communicate with the server (or server module) corresponding to the payment application installed on it. In this embodiment, the electronic device 100 may also have more, fewer, or different payment applications than those in the above embodiments. The receiving device 200 may also include more or fewer card readers 210 than those in the above embodiments. The payment cloud server 300 may also include more, fewer, or different servers than those in the above embodiments. This application does not impose any limitations on these aspects.

[0106] The following describes the device configuration of electronic device 100 and payment device 200, as well as their positional relationship when communicating based on NFC technology.

[0107] Figure 2C shows a schematic diagram of the device configuration of an electronic device 100 provided in an embodiment of this application.

[0108] As shown in Figure 2C, the electronic device 100 may include a front and a back. The front of the electronic device 100 may have a display screen 11. Optionally, the front of the electronic device 100 may also have one or more of the following: a front-facing camera 12, an earpiece 13, etc. The back of the electronic device 100 may include an NFC area 14. Optionally, the back of the electronic device 100 may also include one or more of the following: a rear-facing camera 15, a flashlight 16, etc. When the electronic device 100 touches the payment receiving device 200, the NFC area 14 is used to make contact with the payment receiving device 200 to facilitate NFC-based communication between the electronic device 100 and the payment receiving device 200.

[0109] It is understood that the embodiment shown in Figure 2C is only an example. In this application embodiment, the NFC area of ​​the electronic device 100 can also be set in other locations of the electronic device 100, and this application does not limit it. In addition, the electronic device 100 can be a mobile phone, a tablet computer, a wearable device, or other electronic devices, and this application does not limit it.

[0110] Figure 2D shows a schematic diagram of the device configuration of a card reader 210 in a payment device 200 provided in an embodiment of this application.

[0111] As shown in Figure 2D, the card reader 210 can be a POS machine, and the payment device can include a card swiping area 211 and a display screen 212. Optionally, the card reader 210 may also include a button 213. When the electronic device 100 touches or approaches the card swiping area 211 of the card reader 210, it facilitates NFC-based communication between the electronic device 100 and the card reader 210. The display screen 212 can be used to display the amount due, and also to display payment success notifications, etc. In some embodiments, the areas where the card swiping area 211 and the display screen 212 are located may partially or completely overlap. The button 213 can be used for user interaction, such as outputting the amount due to the card reader 210. In some embodiments, the card reader 210 may not have physical buttons, but instead achieve interaction between the card reader 210 and the user through touch screen operation of the display screen 212.

[0112] It is understood that the embodiment shown in Figure 2D above is only an example. In the embodiments of this application, the card reader 210 may be the POS machine shown in Figure 2D above, or it may be a device form different from the above embodiment, such as including more, fewer or different devices than those shown in the embodiment of Figure 2D above. This application does not limit it here.

[0113] In other embodiments, the payment device 200 may also be a POS machine as described in the embodiment of FIG2D above. In this case, the POS machine can communicate with the payment cloud server 300. This application does not limit the scope of the invention.

[0114] Figure 2E shows a schematic diagram of the positional relationship between an electronic device 100 and a card reader 210 based on NFC technology, according to an embodiment of this application.

[0115] As shown in Figure 2E, the user can touch the NFC area 14 on the back of the electronic device 100 to the card reader area 211 of the card reader 210 to complete the contact between the electronic device 100 and the card reader 210. In this way, the electronic device 100 and the card reader 210 can communicate based on NFC technology to complete the payment.

[0116] It is understood that the embodiment shown in Figure 2E is only an illustrative example of the positional relationship between the electronic device 100 and the card reader 210 when they touch. In this embodiment, if the position of the NFC area 14 or the card swiping area 211 is different from that in the above embodiment, the electronic device 100 and the card reader 210 may also communicate based on NFC technology using a different positional relationship than that in the above embodiment. This application does not limit this.

[0117] The following is a schematic diagram of the structure of an electronic device 100 provided in the embodiments of this application.

[0118] Figure 3A shows a schematic diagram of the structure of an electronic device 100 provided in an embodiment of this application.

[0119] As shown in Figure 3A, the electronic device 100 may include a processor 101 and an NFC module 102. The processor 101 may run one or more applications. These applications may include one or more of the following: a wallet application, one or more host-based card emulation (HCE) applications, etc. Optionally, the electronic device 100 may also include a secure element (SE) 103 and / or a subscriber identity module (SIM) card. The processor 101 may be connected to the NFC module 102, the SE 103, and the SIM card 104, respectively. The NFC module 102 may also be connected to the SE 103 and the SIM card 104.

[0120] The NFC module 102 may include an NFC controller (not shown in Figure 3A), an NFC transceiver (not shown in Figure 3A), and an NFC memory (not shown in Figure 3A). The NFC controller may be connected to the processor 101, and may also be connected to the NFC transceiver and the NFC memory, respectively.

[0121] The NFC controller is primarily used for modulation and demodulation of contactless communication signals, controlling the input and output of data in the NFC memory, and interacting with the processor 101. The NFC transceiver is used to transmit and receive NFC signals (e.g., 13.56MHz radio frequency signals), and may include an electromagnetic compatibility (EMC) filter circuit, a matching circuit, a receiving circuit, and an NFC antenna, where the NFC antenna may be a loop antenna, used to enable proximity-based contactless communication capabilities of the NFC module 102. The NFC memory can be used to store data sent by the NFC module 102 to the payment device 200, as well as data received from the payment device 200. In some embodiments, the NFC memory can be a shared memory that can be used by the various components in the NFC module 102; for example, some data in the NFC memory can be accessed by the NFC controller, while other data can be accessed by the SE 103.

[0122] In other embodiments, the NFC memory may be a collection of multiple memories. For example, the NFC controller may include a first memory among these multiple memories. The first memory may include instructions or data that the NFC controller has used or reused. If the NFC controller needs to use the instruction or data again, it can directly retrieve it from the first memory, thus reducing the waiting time of the NFC controller. SE103 may include a second memory among these multiple memories. The second memory may include card information such as that of the NFC emulator based on the secure element. Thus, if SE103 needs to read the card information of the NFC emulator, it can read the card information of the NFC emulator from the second memory in SE103. SIM card 104 may include a third memory among these multiple memories. The third memory may include card information such as that of the NFC emulator based on the SIM card. Thus, if SIM card 104 needs to read the card information of the NFC emulator, it can read the card information of the NFC emulator from the third memory in SIM card 104.

[0123] In some embodiments, the NFC memory described above may also store routing information. In some embodiments, this routing information may be controlled or managed by the NFC controller, and may include a routing table consisting of a list of routing rules. Each routing rule contains an applet identifier (AID) and a destination; the destination is the location where the applet used to implement the business logic of the NFC emulator card runs. The destination may include an HCE application running in the processor 101 of the electronic device 100, or an SE 103 or SIM card 104 connected to the NFC controller.

[0124] The SE103 and NFC module 102 can be two separate chips. Alternatively, the SE103 and NFC module 102 can be packaged into a single chip.

[0125] Electronic device 100 can activate one or more NFC emulator cards in an application based on user input, thereby enabling electronic device 100 to support one or more NFC services. The specific business processing logic of the NFC emulator card in electronic device 100 is implemented by an applet. The applet can be stored and run in the corresponding hardware device or software module (e.g., HCE application, SIM card, SE, etc.) of the NFC emulator card.

[0126] The card emulation modes of electronic device 100 can be divided into hardware-based virtual card mode and software-based HCE mode. Among them,

[0127] 1. In hardware-based virtual card mode, electronic device 100 can provide the operating environment for the Applet corresponding to the NFC emulator card, as well as the storage and processing of the NFC emulator card's business data, through SE103 or SIM card 104. NFC module 102, as the front end of contactless communication, receives commands from the external PCD and forwards them to SE103 or SIM card 104. The Applet in SE103 or SIM card 104 then processes the commands and sends response data to the external PCD via NFC module 102. Users can activate one or more NFC emulator cards in a wallet application, which can write the Applets and card data of one or more NFC emulator cards into SE103. Alternatively, users can activate one or more NFC emulator cards in a SIM card application, which can write the Applets and card data of one or more NFC emulator cards into SIM card 104 for storage.

[0128] 2. In software-based HCE mode, the HCE application running in processor 101 can provide the operating environment for the Applet corresponding to the NFC emulator card, as well as the storage and processing of the NFC emulator card's business data. After receiving a command from an external PCD, NFC module 102 can send the command to the HCE application. The HCE application can process the command received by the NFC module through the Applet running in the HCE application or a cloud server, and generate response data for the PCD. The HCE application can then send the response data to NFC module 102. NFC module 102 can then send the response data to the external PCD. Users can activate one or more NFC emulator cards in the HCE application. The HCE application can run one or more NFC emulator card Applets and store the NFC emulator card data on the local memory of electronic device 100 or on a cloud server.

[0129] Optionally, the processor 101 can also run an NFC basic service module. The NFC basic service module can be used to provide common management functions for one or more NFC services. These common management functions may include file management, card activation, security management, service routing management, and other functions.

[0130] For example, in the payment scenario described above, the electronic device 100 has a native NFC-related application installed, and users can also download and install third-party applications from app stores. Generally, the native application can use a hardware-based virtual card solution, while the third-party application can use an HCE solution. The native application can be a wallet application, etc., and the third-party application can be, for example, a ticketing application, a payment application, etc. The above examples are merely for explaining this application and should not be construed as limiting it.

[0131] The following describes an NFC protocol stack provided in an embodiment of this application.

[0132] Figure 3B shows a schematic diagram of the layered architecture of an NFC protocol stack provided in an embodiment of this application.

[0133] As shown in Figure 3B, the NFC protocol stack can include a physical layer, a radio frequency layer, an access layer, a transport layer, and an application layer.

[0134] The physical layer can be used to implement the physical characteristics of NFC technology communication.

[0135] The radio frequency (RF) layer can be used to implement RF specifications for NFC technology communication, such as data rate and RF signal frequency.

[0136] The access layer can be used to implement functions such as polling and device discovery, service result notification, card conflict management, transmission protocol negotiation, timeout and retransmission mechanism, PICC / PCD mode switching, and converged card selection.

[0137] The transport layer includes a high-speed data transmission protocol, which enables data transmission between the PCD and PICC at the application layer.

[0138] The application layer can be used to implement one or more NFC services and one or more service management policies. The one or more NFC services may include code-free payment, electronic tickets, access control, digital ID cards, all-scenario contactless payment, and short-range data transmission. The one or more service management policies may include any one or more of file management, card long-term activation, security management, and service routing management. The processing logic of the NFC services can be executed by Applets. In one possible implementation, the processing logic of the service management policies can be executed by the NFC basic service module.

[0139] In this embodiment of the application, the NFC protocol stack shown in Figure 3B above can be referred to as the first protocol stack.

[0140] This application provides a payment method whereby, when a user makes a payment through an electronic device 100, the electronic device 100 can communicate with a receiving device 200 based on NFC to determine the final payment method. Afterward, the electronic device 100 can send the payment account corresponding to that payment method to the receiving device 200. Furthermore, the electronic device 100 can generate a one-time random key based on a preset key generation algorithm and encrypt the payment authorization code using this random key. Then, the electronic device 100 can send the encrypted payment authorization code to a payment cloud server 300, or send the encrypted payment authorization code to the payment cloud server 300 through the receiving device 200. The payment authorization code can be used to authorize the payment cloud server 300 to deduct funds from the payment account corresponding to the electronic device 100, completing the payment. The electronic device 100 can also receive a payment success notification sent by the payment cloud server 300 or the receiving device 200, which is used to notify the user that the payment has been completed.

[0141] In this way, the payment authorization code can be encrypted with a one-time random key, which improves the security of the payment authorization code during communication and protects the user's property security while realizing the payment function.

[0142] The following describes the scheme logic of a payment method provided in an embodiment of this application.

[0143] Figure 4A shows a schematic diagram of the scheme logic of a payment method provided in an embodiment of this application.

[0144] As shown in Figure 4A, after the electronic device 100 and the payment receiving device 200 determine the payment method, the interaction logic between the electronic device 100, the payment receiving device 200 (including the card reader 210 and the merchant backend server 220), and the payment cloud server 300 is as follows:

[0145] 1. Electronic device 100 sends payment account, payment license M and key metadata C1 to card reader 210.

[0146] The payment account is the deduction account, and the payment authorization M may include a payment authorization code encrypted with a random key. The key metadata C1 can be used to decrypt the payment authorization M to obtain the payment authorization code. In some embodiments, the key metadata C1 may be an encrypted key; in other embodiments, the key metadata C1 may also be information used to calculate the key.

[0147] 2. The card reader 210 sends payment data 1 to the merchant's back-end server 220, including the amount payable, payment account, payment license M, and key metadata C1.

[0148] The amount payable refers to the amount that the merchant should receive.

[0149] 3. The merchant backend server 220 sends a payment request 1 to the payment cloud server 300, including the payment account, merchant ID / collection account, amount payable, payment license M, and key metadata C1.

[0150] The merchant ID can be used to indicate the corresponding payment account of the merchant. In some embodiments, the merchant backend server 220 can also send the merchant's payment account to the payment cloud server 300.

[0151] After receiving a payment request 1 carrying a payment license M and key metadata C1, the payment cloud server 300 can decrypt the payment license M based on the key metadata C1 to obtain a payment authorization code. Then, the payment cloud server 300 can deduct funds from the payment account based on the decrypted payment authorization code and transfer the deducted amount to the receiving account. The amount transferred to the receiving account is the amount due, and the amount deducted from the payment account is less than or equal to the amount due.

[0152] 4. The payment cloud server 300 sends a payment success notification to the electronic device 100.

[0153] After the payment is deducted from the payment account, optionally, the payment cloud server 300 can send a payment success notification to the electronic device 100. The payment success notification can be used to notify the user of the electronic device 100 that the payment has been completed.

[0154] 5. The payment cloud server 300 sends a payment success notification to the merchant's backend server 220.

[0155] After the specified amount of money (i.e. the amount payable) is transferred to the receiving account, the payment cloud server 300 can send a payment success notification to the receiving device 200. The payment success notification is used to notify the receiving device 200 that the money has been successfully received.

[0156] 6. The merchant's backend server 220 sends a payment success notification to the card reader 210.

[0157] 7. The card reader 210 sends a payment success notification to the electronic device 100.

[0158] After receiving a payment success notification, the card reader 210 can send a payment success notification to the electronic device 100. The payment success notification can be used to notify the user of the electronic device 100 that the payment has been completed.

[0159] It is understood that the embodiment shown in Figure 4A is only an example. In some embodiments, such as when the electronic device 100 is always in the radio frequency field of the card reader 210 during the payment process, or when the electronic device 100 has enabled password-free payment, the electronic device 100 can use the payment method shown in the above embodiment to send information such as the payment account, payment authorization M, and key metadata C1 to the receiving device 200 to complete the payment. In this case, the payment cloud server 300 does not need to request a payment authorization code from the electronic device 100, and can deduct funds from the payment account based on the payment authorization code sent by the receiving device 200 to complete the payment. This application does not limit this.

[0160] Figure 4B shows a schematic diagram of the scheme logic of a payment method provided in an embodiment of this application.

[0161] As shown in Figure 4B, after the electronic device 100 and the payment receiving device 200 determine the payment method, the interaction logic between the electronic device 100, the payment receiving device 200 (including the card reader 210 and the merchant backend server 220), and the payment cloud server 300 is as follows:

[0162] 1. Electronic device 100 sends payment account information to card reader 210.

[0163] The payment account is the deduction account.

[0164] 2. The card reader 210 sends payment data 2, including the amount due and the payment account, to the merchant's back-end server 220.

[0165] The amount payable refers to the amount that the merchant should receive.

[0166] 3. The merchant backend server 220 sends a payment request 2 to the payment cloud server 300, including the payment account, merchant ID / collection account, and amount payable.

[0167] The merchant ID can be used to indicate the corresponding payment account of the merchant. In some embodiments, the merchant backend server 220 can also send the merchant's payment account to the payment cloud server 300.

[0168] 4. The payment cloud server 300 sends a payment verification request to the electronic device 100.

[0169] After receiving a payment request that does not carry a payment authorization code, the payment cloud server 300 can send a payment verification request to the electronic device 100. The payment verification request can be used to request the electronic device 100 to perform payment verification, and after completing the payment verification, send a payment authorization code to the payment cloud server 300.

[0170] 5. Electronic device 100 sends payment license M and key metadata C1 to payment cloud server 300.

[0171] The functional descriptions of the payment license M and the key metadata C1 can be found in the relevant descriptions in the embodiment shown in Figure 4A above, and will not be repeated here.

[0172] After receiving the payment license M and key metadata C1, the payment cloud server 300 can decrypt the payment license M based on the key metadata C1. After decrypting the payment license M, the payment cloud server 300 can deduct funds from the payment account based on the decrypted payment authorization code and transfer the deducted funds to the receiving account. The amount transferred to the receiving account is the amount due, and the amount deducted from the payment account is less than or equal to the amount due.

[0173] 6. The payment cloud server 300 sends a payment success notification to the electronic device 100.

[0174] After the payment is deducted from the payment account, the payment cloud server 300 can send a payment success notification to the electronic device 100. The payment success notification can be used to notify the user of the electronic device 100 that the payment has been completed.

[0175] 7. The payment cloud server 300 sends a payment success notification to the merchant's backend server 220.

[0176] After the specified amount of money (i.e. the amount payable) is transferred to the receiving account, the payment cloud server 300 can send a payment success notification to the receiving device 200. The payment success notification is used to notify the receiving device 200 that the money has been successfully received.

[0177] 8. The merchant's backend server 220 sends a payment success notification to the card reader 210.

[0178] 9. The card reader 210 sends a payment success notification to the electronic device 100.

[0179] After receiving a payment success notification, the card reader 210 can send a payment success notification to the electronic device 100. The payment success notification can be used to notify the user of the electronic device 100 that the payment has been completed.

[0180] It is understood that the embodiment shown in Figure 4B is only an example. In some embodiments of this application, such as when electronic device 100 has not enabled password-free payment, or when user payment verification is required, electronic device 100 can receive and respond to the payment verification request sent by payment cloud server 300, and send information such as payment license M and key metadata C1 to payment cloud server 300 to complete the payment.

[0181] Furthermore, it should be noted that Figures 4A and 4B illustrate the logic of the payment method using the example of a payment receiving device 200 including a card reader 210 and a merchant backend server 220. In other embodiments of this application, the payment receiving device 200 may also include more, fewer, or different devices than those in the above embodiments, and this application does not limit it here.

[0182] The following describes the structure of a payment authorization code provided in an embodiment of this application.

[0183] Figure 4C shows a schematic diagram of the plaintext C0 of a payment authorization code provided in an embodiment of this application.

[0184] As shown in Figure 4C, the plaintext C0 of the payment authorization code may include a fixed prefix M1, a token seed M2, and a token seed M3. The fixed prefix M1 can be used to indicate the payment method; the token seed M2 and token seed M3 can be used to represent credentials for this transaction.

[0185] In this embodiment of the application, each part of the payment authorization code may include one or more digits. For example, the fixed start M1 may include 2 digits; the token seed M2 and token seed M3 together include 11 digits, and the token seed M2 may include one digit, and the token seed M3 may include 10 digits.

[0186] After encrypting the plaintext C0 of the payment authorization code based on the random key Kr, the ciphertext C of the payment authorization code can be obtained.

[0187] For example, Figure 4D shows a schematic diagram of the structure of the encrypted text C of a payment authorization code provided in an embodiment of this application.

[0188] As shown in Figure 4D, the ciphertext C of the payment authorization code may include a fixed start M1, a token seed M2, and a token seed M3'. The token seed M3' can be obtained by encrypting the token seed M3 shown in Figure 4C using a random key Kr. In some embodiments, after encryption, the length of the token seed M3' can be the same as the length of the token seed M3.

[0189] In some embodiments, after obtaining the ciphertext C of the payment authorization code, the integrity check value C2 of the payment authorization code can be determined, and the payment authorization M can be determined based on the ciphertext C of the payment authorization code and the integrity check value C2. It should be noted that in some embodiments, the integrity check value C2 can be calculated based on the ciphertext C of the payment authorization code. In this case, the integrity check value C2 can be used to verify whether the ciphertext C of the payment authorization code has been modified. In other embodiments, the integrity check value C2 can also be calculated based on the plaintext C0 of the payment authorization code. In this case, the integrity check value C2 can be used to verify whether the plaintext C0 of the payment authorization code has been modified. It is understood that the embodiments here are only two examples, and the integrity check value C2 can also be obtained in other ways, which are not limited here.

[0190] For example, Figure 4E shows a schematic diagram of the structure of a payment license M provided in an embodiment of this application.

[0191] As shown in Figure 4E, the payment license M may include the following four parts: a fixed header M1, a token seed M2, and a token seed M3'. Optionally, the payment license M may also include a one-time proof (OTP) bit M4. The OTP bit M4 can be obtained by encrypting the integrity check value C2 using a random key Kr. For a description of the fixed header M1, token seed M2, and token seed M3', please refer to the relevant content in the embodiments shown in Figures 4C-4D above.

[0192] It should be noted that in some other embodiments, the payment license M may not include the single check bit M4. In this case, the payment license M does not carry an integrity check value, and the payment cloud server 300 does not need to perform integrity check on the payment license M after receiving it.

[0193] It is understood that the embodiments shown in Figures 4C-4E are merely examples. In the embodiments of this application, the electronic device 100 may also encrypt more, less, or different content from the plaintext C0 of the payment authorization code based on a random key Kr. Furthermore, the payment authorization M may also include more, less, or different content than the above embodiments, and this application does not impose limitations on it.

[0194] The following describes a specific method by which an electronic device 100 encrypts a payment authorization code, according to an embodiment of this application.

[0195] Figure 5A shows a logical schematic diagram of an encryption algorithm for a payment authorization code provided in an embodiment of this application.

[0196] As shown in Figure 5A, when the electronic device 100 detects a payment scenario, it can generate a random number R. After generating the random number R, the electronic device 100 can combine the random number R with a pre-stored public key Q. A Perform elliptic curve dot product with random number R and public key Q. A The formula for calculating the dot product of elliptic curves can be found in the following formula (1): S=[R]Q A =(x, y) formula (1)

[0197] In formula (1), S can represent the random number R and the public key Q. A The dot product of the elliptic curve S can be represented by two-dimensional coordinates (x, y).

[0198] The dot product result S can be used as input to the key derivation algorithm F1(·). Here, the key derivation algorithm F1(·) is an algorithm model pre-stored in the electronic device 100. Based on the input dot product result S = (x, y), the key derivation algorithm F1(·) outputs a key CK and a key IK. The key CK can be used to encrypt the payment authorization code, and the key IK can be used to verify the integrity of the payment authorization code. It should be noted that the key CK can refer to the random key Kr shown in Figures 4D-4E above.

[0199] After obtaining keys CK and IK, electronic device 100 can encrypt the plaintext C0 of the payment authorization code based on key CK to obtain the ciphertext C of the payment authorization code. For example, the encryption algorithm can be a format-preserving encrypt (FPE) encryption algorithm.

[0200] After obtaining the ciphertext C, the electronic device 100 can determine the integrity check value C2 based on the ciphertext C and the key IK using a cryptographic hash algorithm. For example, the cryptographic hash algorithm can be a keyed hash function (MAC), such as a hash-based message authentication code (HMAC), a cipher-based message authentication code (CMAC), or a Galois message authentication code (GMAC), etc.

[0201] Then, electronic device 100 can encrypt the integrity verification value C2 based on key CK, and determine the payment authorization M by combining the ciphertext C.

[0202] Furthermore, after generating a random number R, the electronic device 100 can also determine the key metadata C1 based on a preset generation point G and the random number R. The key metadata C1 can be used to decrypt the payment license M. For example, formula (2) shows a calculation formula for key metadata C1 provided in an embodiment of this application: C1 = [R]G Formula (2)

[0203] In the above formula (2), C1 represents the key data, R is a random number, G is the generation point, and C1 is the result of the elliptic curve dot product of the random number R and the generation point G.

[0204] After obtaining the payment authorization M and key metadata C1, the electronic device 100 can send the payment authorization M and key metadata C1 to the payment cloud server 300.

[0205] Figure 5B shows a schematic diagram of the process by which an electronic device 100 encrypts a payment authorization code according to an embodiment of this application.

[0206] As shown in Figure 5B, the specific process by which electronic device 100 encrypts the payment authorization code may include the following steps:

[0207] S501. Electronic device 100 generates plaintext C0 for payment authorization code.

[0208] In some embodiments, the payment authorization code may be preset. The electronic device 100 may determine the payment authorization code corresponding to the payment method after determining the payment method to be used.

[0209] In other embodiments, the payment authorization code may be one-time use, and it becomes invalid immediately after being used. It should be noted that the use of the payment authorization code means that the payment cloud server 300 deducts funds from the payment account corresponding to the electronic device 100 based on the payment authorization code, and the deduction is successful.

[0210] In other embodiments, the payment authorization code may also have an expiration period, that is, the payment authorization code is valid for a preset time period (e.g., 1 minute, 3 minutes, 5 minutes, etc.) after it is generated. If the payment authorization code is not used after the preset time period, the payment authorization code becomes invalid.

[0211] It should be noted that when the payment authorization code is set to have an expiration time, the electronic device 100 may indicate the time of generation of the payment authorization code by one or more digits at a specific position in the payment authorization code when generating the plaintext C0; or, the electronic device 100 may also indicate the time of generation of the ciphertext C by one or more digits at a specific position in the ciphertext C when generating the ciphertext C, etc., which are not limited in this application.

[0212] For example, the structure of the plaintext C0 of the payment authorization code can be referred to the relevant description in the embodiment shown in Figure 4C above.

[0213] S502. Electronic device 100 generates a random number R.

[0214] Electronic device 100 can store elliptic curve E.

[0215] In some embodiments, if the electronic device 100 uses the payment function for the first time, or if the electronic device 100 is powered on for the first time, the electronic device 100 may also obtain the elliptic curve E from the payment cloud server 300 through a secure channel.

[0216] When a payment scenario is detected, the electronic device 100 can generate a random number R based on the elliptic curve E.

[0217] It is understood that the embodiments described herein are merely examples, and in other embodiments, the electronic device 100 may also generate random numbers R in other ways, which are not limited herein.

[0218] S503. Electronic device 100 is based on a random number R and a pre-stored public key Q. A The keys CK and IK are determined.

[0219] Electronic device 100 may pre-store public key Q A And the key derivation algorithm F1(·).

[0220] In some embodiments, if the electronic device 100 uses the payment function for the first time, or if the electronic device 100 is powered on for the first time, the electronic device 100 can also obtain the public key Q from the payment cloud server 300 through a secure channel. A And the key derivation algorithm F1(·).

[0221] The input to the key derivation algorithm F1(·) can be a random number R and a public key Q. A The result S of the elliptic curve dot product can be output, which may include the key CK, and optionally, the output may also include the key IK. The key CK can be used to encrypt the plaintext C0 of the payment authorization code, and the key IK can be used to obtain the integrity verification value of the payment authorization code.

[0222] S504. Electronic device 100 determines key metadata C1 based on random number R and generation point G.

[0223] The generation point G can be data pre-stored by the electronic device 100.

[0224] In some embodiments, if the electronic device 100 uses the payment function for the first time, or if the electronic device 100 is powered on for the first time, the electronic device 100 may also obtain the generation point G from the payment cloud server 300 through a secure channel.

[0225] For example, the specific method by which electronic device 100 determines key metadata C1 based on random number R and generation point G can be referred to the embodiment shown in formula (2) above, and will not be repeated here.

[0226] In other embodiments, the electronic device 100 may also determine the key metadata C1 based on other preset algorithms based on random number R and generation point G, which is not limited herein.

[0227] S505. Electronic device 100 determines the ciphertext C of the payment authorization code based on the key CK and the plaintext C0 of the payment authorization code.

[0228] Electronic device 100 can store a preset encryption algorithm. After obtaining the key CK, electronic device 100 can obtain the ciphertext C of the payment authorization code based on the plaintext C0 and the key CK through the preset encryption algorithm.

[0229] For example, the structure of the ciphertext C of the payment authorization code can be referred to the relevant description in the embodiment shown in Figure 4D above, and the key CK can refer to the random key Kr in the embodiment shown in Figure 4D above.

[0230] In some embodiments, the preset encryption algorithm may be the FPE algorithm, which is an encryption algorithm that ensures that the ciphertext and plaintext have the same format and length. The FPE algorithm can maintain the same format between plaintext and ciphertext, such that English letters remain English letters after encryption, and numbers remain numbers after encryption. It is understood that the embodiments here are only examples. In the embodiments of this application, the preset encryption algorithm stored by the electronic device 100 may also be an encryption algorithm different from the FPE algorithm, or the electronic device 100 may also use multiple encryption algorithms to encrypt the plaintext C0 based on the key CK. This application does not limit this.

[0231] S506. Electronic device 100 determines the integrity check value C2 based on the ciphertext C of the payment authorization code and the key IK.

[0232] Step S506 is an optional step. In some embodiments, the payment license M may not carry a verification value for verifying integrity, in which case step S506 may not be performed.

[0233] Electronic device 100 may store a cryptographic hash algorithm, which can be used to obtain an integrity check value for the input message. The integrity check value can be used to verify the integrity of the input message.

[0234] In some embodiments, the integrity check value C2 can be calculated based on the ciphertext C of the payment authorization code. Specifically, after obtaining the ciphertext C, the electronic device 100 can use the ciphertext C and the key IK as inputs to a cryptographic hash algorithm. In this case, the output of the cryptographic hash algorithm can include the integrity check value C2, which can be used to verify the integrity of the ciphertext C of the payment authorization code.

[0235] In other embodiments, the integrity check value C2 can also be calculated based on the plaintext C0 of the payment authorization code. Specifically, after obtaining the plaintext C0 of the payment authorization code and the key IK, the electronic device 100 can use the plaintext C0 and the key IK as inputs to a cryptographic hash algorithm. In this case, the output of the cryptographic hash algorithm can include the integrity check value C2, which can be used to verify the integrity of the plaintext C0 of the payment authorization code.

[0236] It is understood that the embodiments described here are only two examples. In the embodiments of this application, the electronic device 100 may also determine the integrity verification value C2 based on other parts of the payment authorization code. This application does not limit this.

[0237] In some embodiments, the cryptographic hash algorithm stored in the electronic device 100 may be a MAC algorithm (such as HMAC, CMAC, or GMAC). HMAC is a mechanism for message authentication using hash functions in cryptography, which can authenticate message integrity and source identity. Message integrity authentication proves that the message has not been modified during transmission; source identity authentication means that the receiver and sender can share an authentication key, and the receiver can use this key to determine whether the source sending the message is the designated sender. In this embodiment, the shared authentication key may be key IK, and the message being authenticated may be ciphertext C.

[0238] S507. Electronic device 100 determines payment authorization M based on ciphertext C, payment authorization M including ciphertext C, and optionally, also including integrity check value C2.

[0239] In some embodiments, the payment license M may not carry information for verifying the payment authorization code. In this case, the electronic device 100 may determine the payment license M based on the ciphertext C. For example, the payment license M may be the ciphertext C.

[0240] In other embodiments, the payment authorization M may carry information for verifying the payment authorization code. In this case, the electronic device 100 can determine the payment authorization M based on the ciphertext C and the integrity check value C2. In one possible implementation, the payment authorization M may include the ciphertext C and the integrity check value C2. In another possible implementation, the payment authorization M may include the ciphertext C and the integrity check value C2 encrypted based on the key CK.

[0241] For example, taking Figure 4E above as an example, the ciphertext C may include the fixed start M1, token seed M2 and token seed M3' in the embodiment shown in Figure 4E above; the integrity verification value C2 encrypted based on the key CK may be the single verification bit M4 in the embodiment shown in Figure 4E above.

[0242] It is understood that the embodiments shown in Figures 5A and 5B are merely examples. In the embodiments of this application, the electronic device 100 may also generate a random key in a different manner than the embodiments shown in Figures 5A and 5B, and encrypt the payment authorization code based on the random key. This application does not limit this.

[0243] By employing the encryption method shown in the embodiments of Figures 5A and 5B, the electronic device 100 can determine the payment authorization code in a payment scenario and encrypt the payment authorization code, thereby improving the security of the payment authorization code during transmission and protecting the user's property security.

[0244] It should be noted that the embodiments shown in Figures 5A and 5B are merely exemplary in illustrating a logic for generating a random key based on an elliptic curve (ECC) algorithm and encrypting the payment authorization code based on the random key. In the embodiments of this application, the electronic device 100 may also use other asymmetric encryption algorithms (such as RSA algorithm, etc.) different from the ECC algorithm to generate a random key and encrypt the payment authorization code based on the random key. This application does not limit this.

[0245] The following describes a specific method by which a payment cloud server 300 decrypts a payment license M based on key metadata C1, as provided in an embodiment of this application.

[0246] Figure 6A shows a logical schematic diagram of a payment authorization code decryption algorithm provided in an embodiment of this application.

[0247] As shown in Figure 6A, after receiving the payment license M and key metadata C1, the payment cloud server 300 can process the key metadata C1 and the private key d. A Perform an elliptic curve dot product and obtain the result S1. It should be noted that the private key d... A and public key Q A It is a public-private key pair, with the private key d. A and public key Q A There exists a definite relationship between them, which can be expressed by the following formula (3): Q A =[G]d A Formula (3)

[0248] In formula (3), Q A Public key Q stored for electronic device 100 A G is the generation point, d A This is the private key stored in the payment cloud server 300.

[0249] According to formulas (1) to (3), the key metadata C1 and the private key d A The formula for calculating the dot product of an elliptic curve, S1, is as follows: S1 = [C1]d A =[R][G]d A =[R]Q A =S formula (4)

[0250] According to formula (4), the key metadata C1 and the private key d A The elliptic curve dot product result S1, and the random number R and public key Q in the embodiment shown in Figure 5A above. A The result S of the dot product of the elliptic curve is the same.

[0251] The dot product result S1 can be used as input to the key derivation algorithm F1(·). The payment cloud server 300 can also pre-store the key derivation algorithm F1(·). Based on the input dot product result S = (x, y), the key derivation algorithm F1(·) outputs keys CK and IK. Key CK can be used to decrypt the payment authorization code, and key IK can be used to verify the integrity of the payment authorization code.

[0252] After obtaining the keys CK and IK, the payment cloud server 300 can decrypt the payment authorization code M based on the key CK, obtaining the plaintext C0 of the payment authorization code and the integrity verification value C2. The payment cloud server 300 can store a decryption algorithm. It should be noted that this decryption algorithm is the inverse operation of the encryption algorithm stored in the electronic device 100. That is, the input of the decryption algorithm can include the key CK and the payment authorization code M, and the output can include the plaintext C0 of the payment authorization code and the integrity verification value C2.

[0253] For example, if the encryption algorithm stored in electronic device 100 is the FPE algorithm, then the decryption algorithm stored in payment cloud server 300 can also be the FPE algorithm. Electronic device 100 can encrypt the plaintext C0 of payment authorization code using the FPE algorithm based on key CK to obtain ciphertext C, and payment cloud server 300 can decrypt the ciphertext C in payment license M using the FPE algorithm based on key CK to obtain plaintext C0. Electronic device 100 can encrypt the integrity check value C2 using the FPE algorithm based on key CK, and payment cloud server 300 can decrypt the encrypted integrity check value C2 (e.g., single check bit M4) in payment license M using the FPE algorithm based on key CK to obtain integrity check value C2.

[0254] The payment cloud server 300 may also store a cryptographic hash algorithm, which is the same as the cryptographic hash algorithm stored in the electronic device 100. The payment cloud server 300 can calculate the verification value C3 of the ciphertext C based on the key IK and the ciphertext C carried in the payment authorization M using this cryptographic hash algorithm, and obtain the integrity verification value C2 carried in the payment authorization M based on the payment authorization M and the key CK. Then, the payment cloud server 300 can determine whether the ciphertext C of the payment authorization code has been modified during transmission based on the similarity or difference between the integrity verification value C2 and the verification value C3. If the integrity verification value C2 and the verification value C3 are the same, it means that the ciphertext C of the payment authorization code has not been modified; if the integrity verification value C2 and the verification value C3 are different, it means that the ciphertext C of the payment authorization code has been modified.

[0255] Figure 6B shows a schematic diagram of the process by which a payment cloud server 300 decrypts an encrypted payment authorization code, according to an embodiment of this application.

[0256] As shown in Figure 6B, the specific process by which the payment cloud server 300 decrypts the encrypted payment authorization code may include the following steps:

[0257] S601. The payment cloud server 300 receives the payment license M and key metadata C1.

[0258] S602. Payment Cloud Server 300 based on private key d A Generate keys CK and IK from key metadata C1.

[0259] The payment cloud server 300 can pre-store the private key d A Private key d A The public key Q stored in electronic device 100 A There exists a defined relationship between the private key dA and the public key Q. A They can be converted to each other through a preset generation point G.

[0260] For example, private key d A and public key Q A The relationship between them can be referred to the relevant description in the embodiment shown in formula (3) above, and will not be repeated here.

[0261] For example, the payment cloud server 300 is based on the private key d A The specific method for generating keys CK and IK from key metadata C1 can be found in the relevant description in the embodiment shown in Figure 6A above, and will not be repeated here.

[0262] S603. The payment cloud server 300 extracts the integrity verification value C2 from the payment license M.

[0263] Steps S603 to S606 are optional.

[0264] In some embodiments, if the payment license M does not carry information for verifying the integrity of the payment authorization code, the payment cloud server 300 may execute step S607 after executing step S602, without executing steps S603 to S606.

[0265] In some embodiments, after generating keys CK and IK, the payment cloud server 300 may also sequentially execute multiple steps S603 to S606, that is, first extract the integrity verification value C2 from the payment license M, and temporarily not decrypt the ciphertext C carried in the payment license M. In this way, the ciphertext C in the payment license M can be decrypted only after it is determined that the payment license M has not been modified, avoiding unnecessary power consumption.

[0266] In other embodiments, the payment cloud server 300 may execute steps S603 and S606 simultaneously, or execute one step first and then the other; this application does not limit this. This can improve execution efficiency and shorten decryption time.

[0267] In some embodiments, if the payment license M carries an encrypted integrity verification value, the payment cloud server 300 can first extract the encrypted integrity verification value, and then decrypt the encrypted integrity verification value using the key CK to obtain the integrity verification value C2. If the payment license M carries an unencrypted integrity verification value C2, the payment cloud server 300 can extract the integrity verification value C2 from the payment license M.

[0268] S604. The payment cloud server 300 determines the verification value C3 based on the payment license M and the key IK.

[0269] The payment cloud server 300 can store the same cryptographic hash algorithm as the cryptographic hash algorithm stored in the electronic device 100.

[0270] The payment cloud server 300 can determine the ciphertext C of the payment authorization code based on the payment license M, and use the ciphertext C and the key IK as inputs to the cryptographic hash algorithm. At this time, the output of the cryptographic hash algorithm is the verification value C3.

[0271] For example, the cryptographic hash algorithm can be the HMAC algorithm, CMAC algorithm, or GMAC algorithm, etc.

[0272] S605. Payment Cloud Server 300 determines whether the integrity check value C2 and the check value C3 are the same.

[0273] If the integrity check value C2 is different from the check value C3, the payment cloud server 300 determines that the payment license M has been modified, and the payment cloud server 300 can then perform the following step S607.

[0274] If the integrity check value C2 is the same as the check value C3, then the payment cloud server 300 determines that the payment license M has not been modified, and the payment cloud server 300 can execute the following step S606.

[0275] S606. The payment cloud server 300 sends an error notification to the electronic device 100. The error notification is used to notify the electronic device 100 that the payment authorization code has been modified.

[0276] In some embodiments, error notifications can also be used to notify electronic device 100 to resend the encrypted payment authorization code.

[0277] S607. The payment cloud server 300 determines the plaintext C0 of the payment authorization code based on the key CK and the payment license M.

[0278] It is understood that the embodiments shown in Figures 6A-6B are merely examples. In the embodiments of this application, the payment cloud server 300 may also decrypt the payment license M and perform integrity verification in a different manner than that shown in the embodiments shown in Figures 6A-6B. This application does not limit this.

[0279] Using the decryption method shown in Figures 6A-6B, the payment cloud server 300 can decrypt the payment authorization code M based on the key metadata C1, thereby completing the payment. This improves the security of the payment authorization code during transmission and protects the user's assets.

[0280] In another possible implementation, the key metadata C1 can also refer to the encrypted key (e.g., encrypted key CK, key IK, etc.). In this case, the payment cloud server 300 can also decrypt the key metadata C1 to obtain key CK and key IK, and decrypt the payment license M based on key CK and key IK to complete the payment.

[0281] The following describes the specific process of a payment method provided in an embodiment of this application.

[0282] Figure 7 shows a flowchart of a payment method provided in an embodiment of this application.

[0283] As shown in Figure 7, taking the payment receiving device 200, which includes a card reader 210 and a merchant backend server 220, as an example, the specific process of the payment method may include the following steps:

[0284] S701. Electronic device 100 is pre-configured with elliptic curve E and public key Q. A Generate point G.

[0285] In some embodiments, the electronic device 100 may preset the elliptic curve E and the public key Q in the factory settings. A Generate point G.

[0286] In other embodiments, the electronic device 100 may also obtain the elliptic curve E and public key Q from the payment cloud server 300 when the payment application (or payment mini-program) is first installed. A Generate point G.

[0287] In other embodiments, the electronic device 100 may also obtain the elliptic curve E and public key Q from the payment cloud server 300 upon first power-on or first use of the payment application or payment mini-program. A Generate point G.

[0288] It is understood that the above embodiments are merely examples. In the embodiments of this application, the electronic device 100 may also obtain the elliptic curve E and the public key Q at other times. A The generation point G is not limited in this application.

[0289] S702. Electronic device 100 enters the radio frequency field of card reader 210.

[0290] S703. The card reader 210 sends a probe frame to the electronic device 100.

[0291] The Probe frame can be used to indicate that the card reader 210 supports a specified NFC protocol, such as the first protocol. In some embodiments, the card reader 210 may periodically send Probe frames.

[0292] S704. Electronic device 100 sends a ProbeACK frame to card reader 210.

[0293] The Probe ACK can be used to indicate that the electronic device 100 supports the specified NFC protocol (e.g., the first protocol) indicated by the Probe frame.

[0294] If the electronic device 100 does not support the specified NFC protocol indicated by the Probe frame (e.g., the first protocol), the electronic device 100 may not send a Probe ACK frame.

[0295] S705. The card reader 210 sends a pick frame to the electronic device 100. The pick frame carries the device characteristic information of the card reader 210.

[0296] The device characteristic information may include the service identifier (SID) and the device organization identifier (also known as the NFC device organization unique identifier (ND_OUI)).

[0297] Optionally, device characteristic information may include Service Identifier (SID), Device Organization Identifier (ND_OUI), and Device Group Identifier (also known as NFC Device Group Identifier (ND_GID)).

[0298] 1. The Service Identifier (SID) can be used to indicate the type of NFC service supported by the card reader 210 on top of its NFC functionality.

[0299] In one possible implementation, the NFC service type may include a primary service type and a sub-service type. Therefore, the service identifier may include a primary service identifier and a sub-service identifier. The primary service identifier can be used to indicate the primary service type supported by the card reader 210, and the sub-service identifier can be used to indicate the sub-service types supported by the card reader 210 under a certain primary service type. The primary service type may include codeless payment; optionally, the primary service type may also include one or more of the following: access control, keys, transportation, banking, digital currency, digital certificates, electronic tickets, wireless charging, contactless payment, multi-function cards, etc. The sub-service types corresponding to codeless payment may include general services, membership card discount services, payment institution discount services, etc.

[0300] The main service identifier can occupy 1 byte, and the sub-service identifier can occupy 1 byte. For example, Table 1 shows the correspondence between the device main service identifier, the device sub-service identifier, and the sub-service type when the main service type is codeless payment, according to an embodiment of this application.

[0301] Table 1

[0302] As shown in Table 1, when the main service type is codeless payment, the device main service identifier can be 0x07; if the sub-service type is general service, the device sub-identifier can be 0x01; if the sub-service type is payment discount service (such as membership card discount service, payment institution discount service, etc.), the device sub-identifier can be 0x02; if a new sub-service type needs to be added, an unused identifier can be selected from the reserved identifiers, namely 0x00, 0x03 to 0xFF, as the device sub-service identifier corresponding to the new sub-service type.

[0303] It is understood that the embodiments shown in Table 1 are only examples. In the embodiments of this application, the device service identifier may also adopt a different identifier than the above embodiments. In addition, codeless payment may also include more, fewer or different sub-service types and device sub-service identifiers than the above embodiments. This application does not limit this.

[0304] As can be seen from the above embodiments, in this application embodiment, the Pick frame sent by the card reader 210 may carry a device service identifier for indicating codeless payment, such as 0x07 shown in Table 1 above. Optionally, it may also carry a device sub-service identifier for indicating the sub-service type of the card reader 210.

[0305] 2. The Device Organization Identifier (ND_OUI) can be used to indicate the manufacturer providing NFC services using the card reader device 210, such as merchant A, convenience store B, vending machine C, etc. The NFC protocol standards organization's registration management agency can assign different Device Organization Identifiers to different manufacturers.

[0306] 3. The Device Group Identifier (ND_GID) can be used to indicate the group to which the NFC service provided by the card reader 210 belongs. The Device Group Identifier can be assigned based on the purpose and location of the card reader 210. Different NFC services can be assigned to different groups.

[0307] In another possible implementation, the device feature identifier of the card reader 210 carried in the pick frame can also be replaced with the device feature identifier of the payment device 200.

[0308] S706. Electronic device 100 sends a PickACK frame to card reader 210.

[0309] In some embodiments, electronic device 100 may determine that the service type of card reader 210 is codeless payment based on the device service identifier of card reader 210.

[0310] In this embodiment, steps S704 and S706 can be executed by the access layer of electronic device 100. A detailed description of the access layer of electronic device 100 can be found in the relevant content of the embodiment shown in Figure 3B. After determining the service type, the access layer of electronic device 100 can report the service type of card reader 210 (or payment device 200) to the application layer through the transport layer shown in Figure 3B. The service type can be used to instruct the application layer to select one or more payment applications (also called a payment application set) with payment functionality based on the service type and routing rule list of card reader 210 (or payment device 200). In subsequent steps, the steps on the electronic device 100 side can be executed by the payment application set. The payment application set can communicate with card reader 210 based on NFC technology through the NFC module 102 of electronic device 100. It should be noted that in this embodiment, the payment application set can include one or more applications with payment functionality (also called payment applications), and each payment application can manage one or more mini-programs with payment functionality (also called payment mini-programs). Each payment mini-program can be considered a payment method.

[0311] In some embodiments, after determining the service type of the card reader 210 (or the payment device 200), the electronic device 100 may send a Pick ACK frame to the card reader 210.

[0312] S707. The card reader 210 sends payment information 1 to the electronic device 100. The payment information 1 includes the merchant ID, the identifier of the payment method supported by the card reader 210, and the amount payable 1.

[0313] The amount payable 1 refers to the amount that the merchant corresponding to the card reader 210 should receive. In some embodiments, the amount payable 1 may refer to the amount of goods purchased by the user of the electronic device 100. In other embodiments, if the merchant has its own promotional activities, the amount payable 1 may refer to the amount that the electronic device 100 should pay to the merchant after participating in the merchant's promotional activities.

[0314] S708. Electronic device 100 determines the payment method 1 to be used based on payment information 1.

[0315] Electronic device 100 can determine the payment methods supported by card reader 210 based on payment information 1, and select the final payment method 1 from the payment methods supported by both card reader 210 and electronic device 100.

[0316] In some embodiments, payment method 1 can be the payment method ranked first among the payment methods supported by both the card reader 210 and the electronic device 100. The payment ranking can refer to the payment ranking set by the user, or it can refer to the ranking of different payment methods based on the discount amount. It should be noted that in some embodiments, the electronic device 100 can obtain promotional activities for different payment methods from the payment cloud server 300, determine the discount amount for each payment method based on the promotional activities and the payable amount 1, and rank the payment methods based on the size of the discount amount.

[0317] S709. Electronic device 100 determines the actual payment amount 1 and payment account 1 corresponding to payment method 1.

[0318] The actual amount paid (1) can be less than or equal to the amount payable (1).

[0319] In some embodiments, if the discount amount 1 corresponding to payment method 1 is greater than zero, then the actual payment amount 1 can be the difference between the payable amount 1 and the discount amount 1. If the discount amount 1 corresponding to payment method 1 is equal to zero, then the actual payment amount 1 can be the same as the payable amount 1.

[0320] S710. Electronic device 100 determines whether payment method 1 is enabled for password-free payment.

[0321] If the electronic device 100 enables password-free payment for payment method 1, the electronic device 100 can perform the following step S711.

[0322] If payment method 1 of electronic device 100 is not enabled for password-free payment, electronic device 100 can perform the following step S712.

[0323] S711. Electronic device 100 determines whether the actual payment amount 1 is greater than the password-free payment amount.

[0324] When payment method 1 of electronic device 100 is enabled for password-free payment, electronic device 100 can also obtain the preset password-free payment amount of payment method 1.

[0325] If the actual payment amount 1 is less than or equal to the password-free payment amount, the electronic device 100 can perform the following step S714.

[0326] If the actual payment amount 1 is greater than the password-free payment amount, the electronic device 100 can perform the following step S712.

[0327] S712. Electronic device 100 outputs a payment verification prompt, which is used to prompt the user to perform payment verification.

[0328] The electronic device 100 can output payment verification prompts using one or more methods such as display screen, voice broadcast, vibration, and indicator light flashing.

[0329] Payment verification prompts can be used to prompt users to verify their payments using one or more methods such as fingerprint, facial recognition, or payment password.

[0330] S713. Electronic device 100 receives and responds to the user's operation of completing payment verification, and confirms that payment verification is complete.

[0331] S714. Electronic device 100 generates plaintext C0 of the payment authorization code corresponding to payment method 1.

[0332] In one possible implementation, the electronic device 100 may execute step S714 to generate plaintext C0 of the payment authorization code if it is determined that payment verification has been completed or that password-free payment can be used.

[0333] In another possible implementation, the electronic device 100 may also generate plaintext C0 of the payment authorization code after determining that payment method 1 will be used for payment.

[0334] Other details of step S714 can be found in the description of step S501 shown in Figure 5B above, and will not be repeated here.

[0335] S715. Electronic device 100 is based on elliptic curve E, generation point G, and public key Q. A Encrypt the plaintext C0 to obtain the payment authorization M and key metadata C1.

[0336] The specific method of step S715 can be referred to the relevant description in the embodiments shown in Figures 5A-5B above, and will not be repeated here.

[0337] S716. Electronic device 100 sends payment account 1, payment license M and key metadata C1 to card reader 210.

[0338] The payment authorization M may include a payment method indication identifier, which may be one or more digits located at a specific position in the payment authorization code. The payment method indication identifier is used to indicate that the payment method used for this payment is payment method 1. For example, the payment method indication identifier may be a fixed start as shown in the embodiment of Figure 4C above.

[0339] Optionally, the electronic device 100 may also send the actual payment amount 1 and / or discount amount 1 corresponding to payment method 1 to the card reader 210.

[0340] S717. The card reader 210 sends payment data 1 to the merchant's back-end server 220. The payment data 1 includes the amount payable 1, payment account 1, payment license M, and key metadata C1.

[0341] In some embodiments, payment data 1 may also include actual payment amount 1 and / or discount amount 1.

[0342] S718. Merchant backend server 220 sends payment request 1 to payment cloud server 300. Payment request 1 includes payment account 1, merchant ID / collection account, amount payable 1, payment license M and key metadata C1.

[0343] It should be noted that the merchant ID can be used to indicate the receiving account. Therefore, payment request 1 can include either the merchant ID or the receiving account.

[0344] In some embodiments, payment request 1 may also include actual payment amount 1 and / or discount amount 1.

[0345] S719. Payment Cloud Server 300 completes payment based on payment request 1.

[0346] When payment request 1 carries payment license M and key metadata C1, payment cloud server 300 can decrypt payment license M based on key metadata C1 to obtain plaintext payment authorization code C0. Based on plaintext payment authorization code C0, it deducts funds from payment account 1 and transfers funds to the receiving account. The deducted amount is the actual payment amount 1, and the transferred amount is the amount due. The specific process of payment cloud server 300 decrypting payment license M based on key metadata C1 can be referred to the relevant descriptions in the embodiments shown in Figures 6A-6B above, and will not be repeated here.

[0347] In some embodiments, before deducting funds from the payment account, the payment cloud server 300 can query the promotional activity corresponding to payment method 1, calculate the discount amount 1, and determine the actual payment amount 1 based on the discount amount 1. It should be noted that in some embodiments, the payment request 1 carries the actual payment amount 1 and / or the discount amount 1. In this case, the payment cloud server 300 can also determine the actual payment amount 1 based on the payment request 1, which is not limited in this application.

[0348] S720. Payment cloud server 300 sends a payment notification to merchant backend server 220.

[0349] After the payment cloud server 300 successfully transfers funds to the receiving account, the payment cloud server 300 can send a payment notification to the merchant's backend server 220. The payment notification can be used to notify the merchant that the payment has been successfully received.

[0350] S721. The merchant's backend server 220 sends a payment success notification to the electronic device 100 through the card reader 210.

[0351] A payment success notification can be used to inform users that they have successfully made a payment.

[0352] S722. The payment cloud server 300 sends a payment success notification to the electronic device 100.

[0353] Step S722 is an optional step.

[0354] It should be noted that there is no restriction on the execution order between step S722 and the above steps S720 to S721. When the payment cloud server 300 and the electronic device 100 have established a communication connection, the payment cloud server 300 can send a payment success notification to the electronic device 100 after deducting the payment from the payment account 1.

[0355] The specific content of the payment success notification can be found in the relevant description in step S721 above, and will not be repeated here.

[0356] S723. Electronic device 100 outputs payment success message.

[0357] The electronic device 100 can output a payment success notification through one or more methods such as display screen, voice broadcast, vibration, and indicator light flashing.

[0358] A payment success notification is used to inform the user that the payment has been completed.

[0359] It is understood that the embodiment shown in Figure 7 is only an example. In the embodiments of this application, the payment method may include more, fewer, or different steps than those in the above embodiments, and the execution order of some steps may also be different from those in the above embodiments. This application does not limit it here.

[0360] It should be noted that the embodiment shown in Figure 7 is only an exemplary illustration of a method for generating a random key based on the elliptic curve (ECC) algorithm and encrypting the payment authorization code based on the random key. In this embodiment, the electronic device 100 may also use other asymmetric encryption algorithms (such as RSA algorithm) different from the ECC algorithm to generate a random key and encrypt the payment authorization code based on the random key. This application does not limit this.

[0361] The payment method provided in this application embodiment can encrypt the payment authorization code using a randomly generated key, thereby improving payment security and ensuring the safety of users' assets. Furthermore, even when the electronic device 100 is not connected to the payment cloud server 300, such as when the electronic device 100 is offline, the electronic device 100 can still complete the payment using the payment method shown in Figure 7.

[0362] It should be noted that when the electronic device 100 is within the radio frequency field of the card reader 210, the electronic device 100 and the card reader 210 can communicate based on NFC technology. Therefore, in the embodiment shown in Figure 7 above, during the execution of steps S702 to S721, the electronic device 100 needs to be within the radio frequency field of the card reader 210. In this way, the electronic device 100 can send the payment authorization M and key metadata C1 to the card reader 210 based on NFC technology.

[0363] In some application scenarios, considering that the electronic device 100 may leave the radio frequency field of the card reader 210 during the payment verification process, in another possible implementation, after determining to use payment method 1, the electronic device 100 can determine whether to send a payment authorization M to the payment cloud server 300 through the receiving device 200 based on whether password-free payment can be used. If the electronic device 100 can use password-free payment in this payment, the electronic device 100 can send data such as the payment account, payment authorization M, and key metadata C1 to the payment cloud server 300 through the receiving device 200. The specific interaction method can be referred to the relevant description in the embodiment shown in Figure 7 above, and will not be repeated here. If electronic device 100 cannot use password-free payment in this payment, for example, if payment method 1 does not enable password-free payment, or if the actual payment amount is greater than the preset password-free payment amount, electronic device 100 can send the payment account to payment cloud server 300 through receiving device 200. After that, after detecting that the user has completed payment verification, electronic device 100 can send the payment license M and key metadata C1 to payment cloud server 300 based on the communication connection between it and payment cloud server 300.

[0364] Figure 8 shows a schematic diagram of the process provided in this application embodiment of electronic device 100 completing payment based on whether to use password-free payment after determining payment method 1.

[0365] As shown in Figure 8, after the electronic device 100 enters the radio frequency field of the card reader 210 and determines that payment method 1 is to be used based on communication with the card reader 210, the subsequent payment process may include the following steps:

[0366] S801. Electronic device 100 determines whether payment method 1 is enabled for password-free payment.

[0367] It should be noted that the specific method by which the electronic device 100 determines the payment method 1 based on communication with the card reader 210 can be referred to the relevant steps in the embodiment shown in Figure 7 above, and will not be repeated here.

[0368] If the payment method 1 of the electronic device 100 is enabled for password-free payment, the electronic device 100 can perform the following step S802.

[0369] If payment method 1 of electronic device 100 is not enabled for password-free payment, electronic device 100 can perform the following step S803.

[0370] S802. Electronic device 100 determines whether the actual payment amount is greater than the amount of password-free payment.

[0371] If the actual payment amount is greater than the amount of the password-free payment, the electronic device 100 can perform the following step S803.

[0372] If the actual payment amount is less than or equal to the amount of the password-free payment, the electronic device 100, the card reader 210, the merchant backend server 220, and the payment cloud server 300 can execute steps S714 to S723 in the embodiment shown in Figure 7 above.

[0373] S803. Electronic device 100 sends payment account 1 corresponding to payment method 1 to card reader 210.

[0374] Optionally, the electronic device 100 may also send the actual payment amount 1 and / or discount amount 1 corresponding to payment method 1 to the card reader 210.

[0375] It should be noted that the specific method by which the electronic device 100 determines the payment account 1, actual payment amount 1, discount amount 1, etc. of payment method 1 can be referred to the relevant steps in the embodiment shown in Figure 7 above, and will not be repeated here.

[0376] S804. The card reader 210 sends payment data 2 to the merchant's back-end server 220. The payment data 2 includes the payment account 1 and the amount payable 1.

[0377] S805. Merchant backend server 220 sends payment request 2 to payment cloud server 300. Payment request 2 includes payment account 1, merchant ID / collection account, and amount payable 1.

[0378] S806. The payment cloud server 300 detects that payment request 2 does not carry payment authorization M, and sends a payment verification request to electronic device 100.

[0379] Step S806 is an optional step.

[0380] In some embodiments, a payment verification request may be used to request electronic device 100 to confirm whether to make the payment, and to request electronic device 100 to send payment license M and key metadata C1 to payment cloud server 300 if payment is confirmed.

[0381] S807. Electronic device 100 outputs a payment verification prompt, which is used to prompt the user to perform payment verification.

[0382] In some embodiments, the electronic device 100 may output a payment verification prompt when it determines that the payment cannot be made using password-free payment.

[0383] In other embodiments, the electronic device 100 may also receive and respond to a payment verification request sent by the payment cloud server 300 and output a payment verification prompt.

[0384] S808. Electronic device 100 receives and responds to the user's operation of completing payment verification, and confirms that payment verification is complete.

[0385] S809. Electronic device 100 generates plaintext C0 of the payment authorization code corresponding to payment method 1.

[0386] S810. Electronic device 100 is based on elliptic curve E, generation point G, and public key Q. A Encrypt the plaintext C0 to obtain the payment authorization M and key metadata C1.

[0387] The specific details of steps S807 to S810 can be found in the description of steps S712 to S715 shown in Figure 7 above, and will not be repeated here.

[0388] S811. Electronic device 100 sends payment license M and key metadata C1 to payment cloud server 300.

[0389] In some embodiments, the electronic device 100 may also receive and respond to a payment verification request sent by the payment cloud server 300, and send a payment license M and key metadata C1 to the payment cloud server 300.

[0390] S812. Payment cloud server 300 completes payment based on key metadata C1, payment license M, and payment request 2.

[0391] The specific method by which the payment cloud server 300 decrypts the payment license M can also be referred to the relevant description in the embodiments shown in Figures 6A-6B above. The specific method by which the payment cloud server 300 completes the payment can be referred to the relevant description in step S719 shown in Figure 7 above, and will not be repeated here.

[0392] S813. The payment cloud server 300 sends a payment success notification to the electronic device 100.

[0393] S814. The payment cloud server 300 sends a payment success notification to the card reader 210 through the merchant backend server 220.

[0394] S815. Electronic device 100 outputs payment success message.

[0395] The specific details of steps S813 to S815 can be found in the description of steps S720 to S723 in the embodiment shown in Figure 7 above.

[0396] It is understood that the embodiment shown in Figure 8 is only an example. In the embodiments of this application, the payment method may include more, fewer, or different steps than those in the above embodiments, and the execution order of some steps may also be different from those in the above embodiments. This application does not limit it here.

[0397] The payment method provided in this application embodiment can also improve payment security, ensure the safety of users' property, and send payment license M and key metadata C1 to payment cloud server 300 through the communication connection between electronic device 100 and payment cloud server 300.

[0398] It should be noted that when the electronic device 100 is within the radio frequency field of the card reader 210, the electronic device 100 and the card reader 210 can communicate based on NFC technology. Therefore, in the embodiment shown in Figure 8 above, during the execution of steps S801 to S803, the electronic device 100 needs to be within the radio frequency field of the card reader 210. In the steps after step S803, the electronic device 100 can leave the radio frequency field of the card reader 210. In this case, the electronic device 100 can establish a communication connection with the payment cloud server 300 and send the payment license M and key metadata C1 to the card reader 210 through this communication connection. The communication method between the electronic device 100 and the payment cloud server 300 can be referred to the relevant description in the embodiment shown in Figure 2B above, and will not be repeated here.

[0399] In other application scenarios, after communicating with the card reader 210, the electronic device 100 can display multiple payment options, each corresponding to a payment method supported by the card reader 210. In this case, the electronic device 100 can also determine the final payment method 1 based on the user's selection of a payment option. It should be noted that, considering that the electronic device 100 may need to leave the radio frequency field of the card reader 210 during the user's selection of a payment option, in some embodiments, the electronic device 100 needs to determine the payment method based on the user's selection of a payment option. In this case, the electronic device 100 can send the payment account 1, merchant ID, payment license M, and key metadata C1 corresponding to payment method 1 to the payment cloud server 300 through the communication connection between the electronic device 100 and the payment cloud server 300. The payment cloud server 300 can determine the merchant's receiving account based on the merchant ID and complete the payment. Afterwards, the payment cloud server 300 can send a payment success notification to the electronic device 100 and send a payment notification to the card reader 210 through the merchant backend server 220.

[0400] In this way, even if the electronic device 100 leaves the radio frequency field of the card reader 210, the electronic device 100 can still complete the payment through the communication connection with the payment cloud server 300.

[0401] The following describes another hardware structure of an electronic device 100 provided in the embodiments of this application.

[0402] Figure 9 shows a schematic diagram of the hardware structure of an electronic device 100 provided in an embodiment of this application.

[0403] The following describes the embodiment using electronic device 100 as an example. It should be understood that the electronic device 100 shown in FIG. 9 is merely an example, and the electronic device 100 may have more or fewer components than shown in FIG. 9, may combine two or more components, or may have different component configurations. The various components shown in the figure can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.

[0404] Electronic device 100 may include: processor 110, external memory interface 120, internal memory 121, universal serial bus (USB) interface 130, charging management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, button 190, motor 191, indicator 192, camera 193, display screen 194, and subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include one or more of the following: pressure sensor 180A, gyroscope sensor 180B, barometric pressure sensor 180C, magnetic sensor 180D, accelerometer sensor 180E, distance sensor 180F, proximity sensor 180G, fingerprint sensor 180H, temperature sensor 180J, touch sensor 180K, ambient light sensor 180L, bone conduction sensor 180M, etc.

[0405] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0406] Processor 110 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors. The controller can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution. Processor 110 may also include memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that processor 110 has just used or is recurring. If processor 110 needs to reuse the instruction or data, it can directly retrieve it from the memory. This avoids repeated access, reduces the waiting time of processor 110, and thus improves system efficiency.

[0407] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0408] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0409] The charging management module 140 receives charging input from the charger. The power management module 141 connects to the battery 142, and the charging management module 140 connects to the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to power the processor 110, internal memory 121, external memory, display 194, camera 193, and wireless communication module 160, etc.

[0410] The wireless communication function of electronic device 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor. Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0411] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0412] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0413] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling electronic device 100 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

[0414] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0415] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD). The display panel can also be manufactured using organic light-emitting diodes (OLEDs), active-matrix organic light-emitting diodes (AMOLEDs), flexible light-emitting diodes (FLEDs), miniled, microled, micro-OLEDs, quantum dot light-emitting diodes (QLEDs), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is a positive integer greater than 1.

[0416] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0417] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The internal memory 121 can be used to store computer-executable program code, which includes instructions. The processor 110 executes various functional applications and data processing of the electronic device 100 by running the instructions stored in the internal memory 121. The internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of the electronic device 100 (such as audio data, phonebook, etc.). Furthermore, the internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0418] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0419] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. Gyroscope sensor 180B can be used to determine the motion posture of electronic device 100. Barometric pressure sensor 180C is used to measure air pressure. Magnetic sensor 180D includes a Hall sensor. Accelerometer sensor 180E can detect the magnitude of acceleration of electronic device 100 in various directions (generally three axes). Distance sensor 180F is used to measure distance. Proximity sensor 180G may include, for example, a light-emitting diode (LED) and a photodetector, such as a photodiode. Ambient light sensor 180L is used to sense ambient light intensity. Fingerprint sensor 180H is used to collect fingerprints. Temperature sensor 180J is used to detect temperature. Touch sensor 180K, also called a "touch panel". Touch sensor 180K can be set on display screen 194, and touch sensor 180K and display screen 194 form a touch screen, also called a "touch screen". Touch sensor 180K is used to detect touch operations applied to or near it. A touch sensor can transmit detected touch operations to an application processor to determine the type of touch event. Visual output related to the touch operation can be provided via display screen 194. In some embodiments, touch sensor 180K may also be located on the surface of electronic device 100, in a different position than display screen 194. Bone conduction sensor 180M can acquire vibration signals. Buttons 190 include a power button, volume buttons, etc. Motor 191 can generate vibration cues. Indicator 192 may be an indicator light, used to indicate charging status, battery level changes, or to indicate messages, missed calls, notifications, etc.

[0420] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with and separate from the electronic device 100. The electronic device 100 can support one or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, etc. Multiple cards can be inserted into the same SIM card interface 195 simultaneously. The multiple cards can be of the same or different types. The SIM card interface 195 is also compatible with different types of SIM cards. The SIM card interface 195 is also compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to realize functions such as calls and data communication. In some embodiments, the electronic device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

[0421] In some embodiments, the wireless communication module 160 can specifically be used to establish a short-range wireless communication link with the payment device 200, so that the two can perform short-range wireless data transmission. Exemplarily, the aforementioned short-range wireless communication link can be a Bluetooth link, a Wi-Fi link, an NFC link, etc. Therefore, the wireless communication module 160 can specifically include a Bluetooth communication module, a Wi-Fi communication module, or an NFC module. The NFC module can include any suitable components for enabling proximity-based contactless communication between the electronic device 100 and the payment device 200, thereby providing NFC functionality to the electronic device 100. A description of the NFC module can be found in the embodiment shown in FIG3A above, and will not be repeated here.

[0422] The foregoing details the method provided in this application. In order to facilitate better implementation of the above-described solutions in the embodiments of this application, the embodiments of this application also provide corresponding devices or equipment.

[0423] This application embodiment can divide the electronic device 100 and the payment device 200 into functional modules according to the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0424] The communication device of the present application embodiment will now be described in detail with reference to Figures 10 to 13.

[0425] Referring to FIG10, which is a schematic diagram of the structure of a communication device 1000 provided in an embodiment of this application, the communication device 1000 can be the electronic device 100 in the above embodiments. Optionally, the communication device 1000 can be a chip / chip system, such as an NFC chip. As shown in FIG10, the communication device 1000 may include a transceiver unit 1010 and a processing unit 1020.

[0426] The transceiver unit 1010 can also be used to perform NFC sending and NFC receiving functions performed by the electronic device 100 in the above embodiments of this application.

[0427] Optionally, the processing unit 1020 can also be used to perform functional steps related to NFC protocol parsing and encapsulation, NFC service processing flow, and display, which are performed by the electronic device 100 in the above embodiments of this application.

[0428] It should be understood that the communication device 1000 in this design can perform the method steps performed by the electronic device 100 in the aforementioned embodiments, and for the sake of brevity, they will not be described again here.

[0429] Referring to FIG11, which is a schematic diagram of the structure of a communication device 1100 provided in an embodiment of this application, the communication device 1100 can be the payment receiving device 200 in the above embodiments. Optionally, the communication device 1100 can be the payment receiving device 200. As shown in FIG11, the communication device 1100 may include a transceiver unit 1110 and a processing unit 1120.

[0430] Optionally, the transceiver unit 1110 can also be used to perform NFC sending and NFC receiving functions performed by the payment device 200 in the above embodiments of this application.

[0431] Optionally, the processing unit 1120 can also be used to execute the functional steps related to NFC protocol parsing and encapsulation and NFC service processing flow executed by the payment receiving device 200 in the above embodiments of this application.

[0432] It should be understood that the communication device 1100 in this design can perform the method steps executed by the payment device 200 in the aforementioned embodiment, and for the sake of brevity, it will not be described again here.

[0433] The above describes the electronic device 100 and the payment device 200 of the embodiments of this application. It should be understood that any product with the functions of the electronic device 100 described in FIG10 and any product with the functions of the payment device 200 described in FIG11 falls within the protection scope of the embodiments of this application.

[0434] As one possible product form, the electronic device 100 described in this application embodiment can be implemented using a general bus architecture.

[0435] Referring to Figure 12, Figure 12 is a schematic diagram of the structure of a communication device 1200 provided in an embodiment of this application. The communication device 1200 can be an electronic device 100, or a device therein. As shown in Figure 12, the communication device 1200 includes a processor 1201 and a transceiver 1202 internally connected and communicating with the processor 1201. The processor 1201 can be a general-purpose processor or a dedicated processor, etc. For example, it can be a central processing unit and / or an NFC controller, etc. The transceiver 1202 can be referred to as a transceiver unit, transceiver, or transceiver circuit, etc., and is used to implement transceiver functions. The transceiver 1202 can include a receiver and a transmitter. The receiver can be referred to as a receiver or receiving circuit, etc., and is used to implement a receiving function, such as an NFC receiving function; the transmitter can be referred to as a transmitter or transmitting circuit, etc., and is used to implement a transmitting function, such as an NFC transmitting function. Optionally, the communication device 1200 may also include an antenna 1203 and / or a radio frequency unit (not shown in Figure 12), for example, an NFC antenna, wherein the NFC antenna can be a coil-type antenna. The antenna 1203 and / or radio frequency unit may be located inside the communication device 1200 or separate from the communication device 1200, that is, the antenna 1203 and / or radio frequency unit may be deployed remotely or in a distributed manner.

[0436] Optionally, the communication device 1200 may include one or more memories 1204, which may store instructions, which may be computer programs, that can be executed on the communication device 1200 to cause the communication device 1200 to perform the method steps described in the above embodiments of this application. Optionally, the memory 1204 may also store data. The communication device 1200 and the memory 1204 may be provided separately or integrated together.

[0437] The processor 1201, transceiver 1202, and memory 1204 can be connected via a communication bus.

[0438] In one design, the communication device 1200 can be used to perform the functions of the electronic device 100 in the foregoing embodiments: the processor 1201 can be used to perform the functional steps related to NFC protocol parsing and encapsulation, NFC service processing flow and display performed by the electronic device 100 in the foregoing embodiments of this application and / or other processes used in the technology described herein; the transceiver 1202 can be used to perform the functional steps related to NFC sending and NFC receiving performed by the electronic device 100 in the foregoing embodiments of this application and / or other processes used in the technology described herein.

[0439] In any of the above designs, the processor 1201 may include a transceiver for implementing receiving and transmitting functions. For example, the transceiver may be a transceiver circuit, an interface, or an interface circuit. The transceiver circuit, interface, or interface circuit for implementing receiving and transmitting functions may be separate or integrated. The aforementioned transceiver circuit, interface, or interface circuit may be used for reading and writing code / data, or it may be used for transmitting or relaying signals.

[0440] In any of the above designs, the processor 1201 may store instructions, which may be computer programs. These computer programs, running on the processor 1201, cause the communication device 1200 to execute the method steps performed by the electronic device 100 in the above embodiments of this application. The computer program may be embedded in the processor 1201; in this case, the processor 1201 may be implemented in hardware.

[0441] In one implementation, the communication device 1200 may include circuitry capable of performing the functions of transmitting, receiving, or communicating as described in the aforementioned method embodiments. The processor and transceiver described in this application can be implemented on integrated circuits (ICs), analog ICs, radio frequency integrated circuits (RFICs), mixed-signal ICs, application-specific integrated circuits (ASICs), printed circuit boards (PCBs), electronic devices, etc. The processor and transceiver can also be manufactured using various IC process technologies, such as complementary metal-oxide-semiconductor (CMOS), n-metal-oxide-semiconductor (NMOS), p-type metal-oxide-semiconductor (PMOS), bipolar junction transistors (BJTs), bipolar CMOS (BiCMOS), silicon-germanium (SiGe), gallium arsenide (GaAs), etc.

[0442] The scope of the communication device described in this application is not limited thereto, and the structure of the communication device is not limited to that shown in Figure 12. The communication device 1200 can be a standalone device or part of a larger device. For example, the communication device 1200 can be:

[0443] (1) A standalone integrated circuit IC, or chip, or chip system or subsystem; (2) A collection of one or more ICs, optionally including storage components for storing data or computer programs; (3) An ASIC, such as an NFC chip; (4) A module that can be embedded in other devices; (5) A receiver, terminal, smart terminal, cellular phone, wireless device, handheld device, mobile unit, vehicle device, network device, cloud device, artificial intelligence device, etc.; (6) Others, etc.

[0444] As one possible product form, the payment device 200 described in this application embodiment can be implemented using a general bus architecture.

[0445] Referring to Figure 13, Figure 13 is a schematic diagram of the structure of the communication device 1300 provided in an embodiment of this application. The communication device 1300 can be a payment receiving device 200, or a device therein. As shown in Figure 13, the communication device 1300 includes a processor 1301 and a transceiver 1302 internally connected and communicating with the processor 1301. The processor 1301 can be a general-purpose processor or a dedicated processor, for example, an NFC controller. The transceiver 1302 can be referred to as a transceiver unit, transceiver, or transceiver circuit, etc., and is used to implement transceiver functions. The transceiver 1302 can include a receiver and a transmitter. The receiver can be referred to as a receiver or receiving circuit, etc., and is used to implement a receiving function; the transmitter can be referred to as a transmitter or transmitting circuit, etc., and is used to implement a transmitting function. Optionally, the communication device 1300 may also include an antenna 1303 and / or a radio frequency unit (not shown in the figure). The antenna 1303 and / or radio frequency unit may be located inside the communication device 1300 or separate from the communication device 1300, that is, the antenna 1303 and / or radio frequency unit may be deployed remotely or in a distributed manner.

[0446] Optionally, the communication device 1300 may include one or more memories 1304, which may store instructions, which may be computer programs, that can be executed on the communication device 1300 to cause the communication device 1300 to perform the method steps described in the above embodiments of this application. Optionally, the memory 1304 may also store data. The communication device 1300 and the memory 1304 may be provided separately or integrated together.

[0447] The processor 1301, transceiver 1302, and memory 1304 can be connected via a communication bus.

[0448] In one design, the communication device 1300 can be used to perform the functions of the payment device 200 in the foregoing embodiments: the processor 1301 can be used to perform the functional steps related to NFC protocol parsing and encapsulation, NFC service processing flow and / or other processes used in the technology described herein, performed by the payment device 200 in the embodiment shown in FIG13; the transceiver 1302 can be used to perform the functional steps related to NFC sending and NFC receiving performed by the payment device 200 in the embodiment shown in FIG13 and / or other processes used in the technology described herein.

[0449] In any of the above designs, the processor 1301 may include a transceiver for implementing receive and transmit functions. For example, the transceiver may be a transceiver circuit, an interface, or an interface circuit. The transceiver circuit, interface, or interface circuit for implementing receive and transmit functions may be separate or integrated. The aforementioned transceiver circuit, interface, or interface circuit may be used for reading and writing code / data, or it may be used for transmitting or relaying signals.

[0450] In any of the above designs, the processor 1301 may store instructions, which may be computer programs. These computer programs, running on the processor 1301, cause the communication device 1300 to execute the method steps performed by the payment receiving device 200 in the above method embodiments. The computer program may be embedded in the processor 1301; in this case, the processor 1301 may be implemented in hardware.

[0451] Figure 14 shows a flowchart of a payment method provided in an embodiment of this application.

[0452] As shown in Figure 14, the specific process of a payment method may include the following steps:

[0453] S1401. After entering the radio frequency field of the receiving device, the electronic device receives first payment information sent by the receiving device, the first payment information including an identifier of one or more payment methods supported by the receiving device.

[0454] The electronic device can be the electronic device 100 in the above embodiments, and the payment device can be the payment device 200 in the above embodiments.

[0455] For example, the first payment information may be payment information 1 in the embodiment shown in Figure 7 above.

[0456] S1402. An electronic device determines a first payment method from among one or more payment methods supported by a payment receiving device.

[0457] For example, the first payment method may be payment method 1 in the embodiment shown in Figure 7 above.

[0458] S1403. The electronic device determines the first authorization code corresponding to the first payment method, and the first authorization code is used to authorize the server to complete the payment of the first payment method.

[0459] The first authorization code can be the plaintext C0 of the payment authorization code in the above embodiment.

[0460] The server can be the payment cloud server 300 in the above embodiments.

[0461] S1404. The electronic device encrypts the first authorization code using an asymmetric encryption algorithm based on the first random number and the first public key to obtain the first payment permission.

[0462] The first random number can be the random number R in the above embodiments. The first public key can be the public key Q in the above embodiments. A .

[0463] The first payment license can be the payment license M in the above embodiments.

[0464] S1405. The electronic device generates key metadata based on a first random number and an asymmetric encryption algorithm.

[0465] The key metadata can refer to the key metadata C1 in the above embodiment.

[0466] S1406. The electronic device sends a first payment account, a first payment license, and key metadata to the server. The first payment account is the payment account corresponding to the first payment method, and the key metadata is used to decrypt the first authorization code from the first payment license.

[0467] For example, the first payment account may be payment account 1 in the embodiment shown in Figure 7 above.

[0468] The specific details of each step shown in Figure 14 can also be found in the relevant steps of the embodiment shown in Figure 7 above, and will not be repeated here.

[0469] Using the payment method provided in this application, electronic devices can generate a random key each time a payment is made, and use this key to encrypt the payment authorization code. This improves the security of the payment authorization code during transmission and ensures payment security.

[0470] In one possible implementation, the first authorization code is encrypted using an asymmetric encryption algorithm based on the first random number and the first public key to obtain the first payment license. Specifically, this includes: determining the first key using an asymmetric encryption algorithm based on the first random number and the first public key; encrypting the first authorization code based on the first key to obtain the first ciphertext; and determining the first payment license based on the first ciphertext.

[0471] For example, the first ciphertext can be the ciphertext C of the payment authorization code in the above embodiment.

[0472] In this way, the first payment authorization can carry the first ciphertext, which is based on the encrypted payment authorization code.

[0473] In one possible implementation, the method further includes: determining a second key based on a first random number and a first public key using an asymmetric encryption algorithm; determining a first check value based on a first ciphertext and the second key, the first check value being used to verify the integrity of the first ciphertext; and determining a first payment authorization based on the first ciphertext, specifically including: determining a first payment authorization based on the first ciphertext and the first check value.

[0474] For example, the first key may be the key CK in the above embodiments, the second key may be the key IK in the above embodiments, and the first check value may be the integrity check value C2 in the above embodiments.

[0475] Thus, the first payment authorization may also include an integrity check value (i.e., the first check value) of the payment authorization code, which can verify the integrity of the first ciphertext and determine whether the first ciphertext has been tampered with during transmission.

[0476] In one possible implementation, determining the first payment authorization based on the first ciphertext and the first verification value specifically includes: encrypting the first verification value based on the first key to obtain a second verification value; and determining the first payment authorization based on the first ciphertext and the second verification value, wherein the first payment authorization includes the first ciphertext and the second verification value.

[0477] For example, the second verification value can be the result of encrypting the integrity verification value C2 with the key CK in the above embodiments, such as the single verification bit M4 in the embodiment shown in Figure 4E.

[0478] In this way, the first payment authorization can carry an encrypted integrity verification value, i.e., the second verification value. Transmitting the encrypted integrity verification value can improve payment security and prevent leakage during transmission.

[0479] In one possible implementation, the key metadata and the first random number are a public-private key pair. The key metadata is used to decrypt the first authorization code from the first payment license with the first private key. The first private key and the first public key are a public-private key pair.

[0480] A public key and a private key are a key pair obtained using the same algorithm (i.e., a public key and a private key). One of these is made public and called the public key; the other is kept secret and called the private key. Keys obtained using this algorithm are unique. When using this key pair, if data is encrypted with one key, it must be decrypted with the other key. For example, data encrypted with the public key must be decrypted with the private key, and vice versa; otherwise, decryption will fail.

[0481] In this embodiment, the first public key and the first private key are generated by the server. The server retains the first private key (e.g., private key dA in the above embodiment), and the electronic device can obtain the first public key (e.g., public key Q in the above embodiment) from the server. A In addition, the key metadata and the first random number are generated by the electronic device. The first random number (e.g., random number R) is stored in the electronic device as a private key, and the key metadata (e.g., key metadata C1) is sent to the server as a public key.

[0482] In one possible implementation, the key metadata includes a first key and a second key.

[0483] In this way, the server can directly determine the first key and the second key based on the key metadata, and decrypt the first payment license to complete the payment.

[0484] In one possible implementation, sending the first payment account, first payment license, and key metadata to the server specifically includes: sending the first payment account, first payment license, and key metadata to the server via the payment receiving device.

[0485] In this way, electronic devices can interact with the server through the payment device to complete the payment.

[0486] In one possible implementation, the first payment information further includes a first amount; after determining the first payment method from one or more payment methods supported by the receiving device, the method further includes: determining a second amount based on the first payment method and the first amount, the second amount being the amount paid by the electronic device through the first payment method; sending the first payment account, the first payment license, and key metadata to the server through the receiving device, specifically including: if the first payment method enables password-free payment, and the second amount is less than or equal to the password-free payment limit of the first payment method, sending the first payment account, the first payment license, and key metadata to the server through the receiving device.

[0487] For example, the first amount may be the payable amount 1 in the embodiment shown in Figure 7 above.

[0488] In this way, in the context of password-free payment, electronic devices can interact with the server through the payment device to complete the payment.

[0489] In one possible implementation, sending the first payment account, first payment license, and key metadata to the server specifically includes: sending the first payment account to the server via the payment device; and sending the first payment license and key metadata to the server.

[0490] In this way, electronic devices can also send the first payment authorization and key metadata to the server through a communication connection.

[0491] In one possible implementation, the first payment information further includes a first amount; after determining the first payment method from one or more payment methods supported by the receiving device, the method further includes: determining a second amount based on the first payment method and the first amount, the second amount being the amount paid by the electronic device through the first payment method; sending a first payment account to the server through the receiving device, specifically including: if the first payment method does not have password-free payment enabled, or the second amount is greater than the password-free payment limit of the first payment method, sending the first payment account to the server through the receiving device; sending a first payment authorization and key metadata to the server, specifically including: receiving and responding to a first operation by the user, sending the first payment authorization and key metadata to the server, the first operation being used to complete payment verification.

[0492] In this way, in non-password-free payment scenarios, when a user completes payment verification, the electronic device may leave the radio frequency field of the receiving device. In this case, the electronic device can send the first payment authorization and key metadata to the server after the user completes payment verification.

[0493] In one possible implementation, before sending the first payment authorization and key metadata to the server, the method further includes: receiving a first request sent by the server, the first request being used to request the electronic device to complete payment verification.

[0494] In this way, electronic devices can also respond to the first request sent by the server by sending the first payment authorization and key metadata to the server.

[0495] In one possible implementation, the first payment information further includes a first amount and a first receiving account; the method further includes sending the first amount and the first receiving account to the server.

[0496] In this way, during the payment process, the electronic device can obtain the initial amount and the initial receiving account through interaction with the receiving device, and complete the payment based on the interaction between the electronic device and the server. Using this method, the electronic device does not need to interact with the server through the receiving device; therefore, it is unnecessary to consider whether the electronic device leaves the radio frequency field of the receiving device during the payment process.

[0497] In one possible implementation, the method further includes receiving a first notification sent by a server, the first notification being used to notify the electronic device of successful payment. For example, the first notification could be the payment success notification in step S722 of Figure 7.

[0498] In this way, after the payment is successful, the electronic device can receive the first notification through the communication connection with the server.

[0499] In one possible implementation, receiving the first notification sent by the server specifically includes: receiving the first notification sent by the server through the payment device. For example, the first notification could be the payment success notification in step S721 of Figure 7.

[0500] In this way, after the payment is successful, the electronic device can receive the first notification sent by the server through the receiving device.

[0501] In one possible implementation, the first authorization code is used to authorize the server to complete the payment of the first payment method, specifically including: the first authorization code is used to authorize the server to complete the payment of the first payment method within a first time period.

[0502] In this way, the first authorization code can have an expiration time, meaning that the first authorization code becomes invalid after the first time period ends, thus improving the security of payment.

[0503] In one possible implementation, before receiving the first payment information sent by the receiving device, the method further includes: receiving a probe frame sent by the receiving device, the probe frame indicating that the receiving device supports a specified NFC protocol; sending a probe ACK frame to the receiving device, the probe ACK frame indicating that the electronic device supports the specified NFC protocol; receiving a pick frame sent by the receiving device, the pick frame carrying device feature information of the receiving device, the device feature information including a service identifier and a device organization identifier, wherein the service identifier indicates the type of NFC service supported by the receiving device, and the device organization identifier indicates the manufacturer using the receiving device to provide NFC services; determining, based on the device feature information of the receiving device, that the type of NFC service of the receiving device is codeless payment; and sending a pick ACK frame to the receiving device, the pick ACK frame indicating that the electronic device has determined the NFC service type of the receiving device.

[0504] In this way, the electronic device can interact with the receiving device through the first protocol to determine that the receiving device's service type is NFC service.

[0505] In one possible implementation, asymmetric encryption algorithms may include elliptic curve algorithms, RSA algorithms, etc.

[0506] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps performed by the electronic device 100 in the above-described method embodiments.

[0507] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps performed by the payment device 200 in the above-described method embodiments.

[0508] This application also provides a computer program product, including a computing program, which, when run on a computer, enables the computer to perform the steps executed by the electronic device 100 in the above-described method embodiments.

[0509] This application also provides a computer program product, including a computing program, which, when run on a computer, enables the computer to perform the steps executed by the payment receiving device 200 in the above-described method embodiments.

[0510] This application also provides a chip, which includes a processing circuit interface circuit. The interface circuit receives code instructions and transmits them to the processing circuit. The processing circuit executes the code instructions to enable the chip system to perform the steps executed by the electronic device 100 in any method embodiment of this application. The chip system can be a single chip or a chip module composed of multiple chips.

[0511] This application also provides a chip, which includes a processing circuit interface circuit. The interface circuit receives code instructions and transmits them to the processing circuit. The processing circuit executes the code instructions to enable the chip system to perform the steps executed by the payment receiving device 200 in any method embodiment of this application. The chip system can be a single chip or a chip module composed of multiple chips.

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

Claims

1. A payment method applied to an electronic device, characterized by, The method comprises: After entering the radio frequency field of the payment device, receiving first payment information sent by the payment device, the first payment information comprising identification of one or more payment methods supported by the payment device; Determining a first payment method from the one or more payment methods supported by the payment device; Determining a first authorization code corresponding to the first payment method, the first authorization code being used for authorizing a server to complete payment of the first payment method; Encrypting the first authorization code based on a first random number and a first public key by using an asymmetric encryption algorithm to obtain a first payment permission; Generating key metadata based on the first random number and the asymmetric encryption algorithm; Sending a first payment account, the first payment permission and the key metadata to the server, the first payment account being a payment account corresponding to the first payment method, and the key metadata being used for decrypting the first authorization code from the first payment permission.

2. The method of claim 1, wherein, The method further comprises: Determining a second key based on the first random number and the first public key by using the asymmetric encryption algorithm; Determining a first check value based on the first ciphertext and the second key, the first check value being used for checking the integrity of the first ciphertext; The method further comprises:

3. The method of claim 2, wherein, Determining a second key based on the first random number and the first public key by using the asymmetric encryption algorithm; Determining a first check value based on the first ciphertext and the second key, the first check value being used for checking the integrity of the first ciphertext; The method further comprises: Determining a second check value based on the first key and the first check value; Determining the first payment permission based on the first ciphertext and the second check value, the first payment permission comprising the first ciphertext and the second check value.

4. The method of claim 3, wherein, The key metadata and the first random number are a pair of public and private keys, and the key metadata is used for decrypting the first authorization code from the first payment permission with a first private key, the first private key and the first public key being a pair of public and private keys. The key metadata comprises the first key and the second key. The method further comprises:

5. The method according to any one of claims 1-4, characterized in that, Sending the first payment account, the first payment permission and the key metadata to the server by using the payment device.

6. The method according to claim 3 or 4, characterized in that, The first payment information further comprises a first amount; 7. The method according to any one of claims 1 to 6, characterized in that, After determining the first payment method from the one or more payment methods supported by the payment device, the method further comprises: Determining a second amount based on the first payment method and the first amount, the second amount being an amount paid by the electronic device through the first payment method; 8. The method of claim 7, wherein, ​ ​ ​ The sending, by the payment device, of the first payment account, the first payment permission, and the key metadata to the server specifically includes: If the first payment method supports password-free payment and the second amount is less than or equal to the password-free payment limit of the first payment method, the payment device sends the first payment account, the first payment permission, and the key metadata to the server.

9. The method according to any one of claims 1-6, characterized in that, The sending, by the payment device, of the first payment account, the first payment permission, and the key metadata to the server specifically includes: The payment device sends the first payment account to the server. The payment device sends the first payment permission and the key metadata to the server.

10. The method of claim 9, wherein, The first payment information further includes a first amount. After determining the first payment method from the one or more payment methods supported by the payment device, the method further includes: Determining a second amount based on the first payment method and the first amount, the second amount being an amount paid by the electronic device through the first payment method; The sending, by the payment device, of the first payment account, the first payment permission, and the key metadata to the server specifically includes: If the first payment method does not support password-free payment or the second amount is greater than the password-free payment limit of the first payment method, the payment device sends the first payment account to the server. The sending, by the payment device, of the first payment account, the first payment permission, and the key metadata to the server specifically includes: Receiving and responding to a first operation of a user, the payment device sends the first payment permission and the key metadata to the server, the first operation being used to complete payment verification.

11. The method according to claim 9 or 10, characterized in that, Before the sending, by the payment device, of the first payment permission and the key metadata to the server, the method further includes: Receiving a first request sent by the server, the first request being used to request the electronic device to complete payment verification.

12. The method of any one of claims 1-6, wherein, The first payment information further includes a first amount and a first payment account. The method further includes: The payment device sends the first amount and the first payment account to the server.

13. The method according to any one of claims 1-12, characterized in that, The method further includes: Receiving a first notification sent by the server, the first notification being used to notify the electronic device of payment success.

14. The method of claim 13, wherein, The receiving, by the payment device, of the first notification sent by the server specifically includes: The payment device receives the first notification sent by the server.

15. The method of any one of claims 1-14, wherein, The first authorization code is used to authorize the server to complete payment of the first payment method, specifically including: The first authorization code is used to authorize the server to complete payment of the first payment method within a first time period.

16. The method of any one of claims 1-15, wherein, Before receiving the first payment information sent by the payment device, the method further includes: Receiving a probe frame sent by the payment device, the probe frame being used to indicate that the payment device supports a specified NFC protocol; The electronic device sends a probe acknowledgement (Probe ACK) frame to the payment device, the Probe ACK frame being used to indicate that the electronic device supports the specified NFC protocol; Receiving a pick frame sent by the payment device, the pick frame carrying device characteristic information of the payment device, the device characteristic information of the payment device including a service identifier and a device organization identifier, wherein the service identifier is used to indicate a type of NFC service supported by the payment device, and the device organization identifier is used to indicate a manufacturer that provides the NFC service using the payment device; Based on the device characteristic information of the payment device, determining that the type of NFC service of the payment device is no-code payment; Sending a pick acknowledgement (PickACK) frame to the payment device, the PickACK frame being used to indicate that the electronic device has determined the type of NFC service of the payment device.

17. The method of any one of claims 1-16, wherein, The asymmetric encryption algorithm includes an elliptic curve algorithm.

18. A payment system characterized by, The electronic device, the payment device, and the server are included. The electronic device is configured to receive first payment information sent by the payment device after entering a radio frequency field of the payment device, the first payment information including an identifier of one or more payment methods supported by the payment device; The electronic device is further configured to determine a first payment method from the one or more payment methods supported by the payment device; The electronic device is further configured to determine a first authorization code corresponding to the first payment method, the first authorization code being used to authorize the server to complete payment in the first payment method; The electronic device is further configured to encrypt the first authorization code based on a first random number and a first public key by using an asymmetric encryption algorithm to obtain a first payment permission; The electronic device is further configured to generate key metadata based on the first random number and the asymmetric encryption algorithm; The electronic device is further configured to send, to the server, a first payment account corresponding to the first payment method, the first payment permission, and the key metadata, the key metadata being used to decrypt the first authorization code from the first payment permission; The payment device is configured to send the first payment information to the electronic device; The server is configured to receive the first payment account, the first payment permission, and the key metadata; The server is further configured to receive a first payment account and a first amount; The server is further configured to complete payment based on the first payment account, the first amount, the first payment account, the first payment permission, and the key metadata.

19. The system of claim 18, wherein, The server is further configured to complete payment based on the first payment account, the first amount, the first payment account, the first payment permission, and the key metadata, and specifically includes: The server is further configured to decrypt the first authorization code from the first payment permission based on the key metadata; The server is further configured to complete payment based on the first authorization code, the first payment account, the first payment account, and the first amount.

20. The system of claim 19, wherein, The server is further configured to decrypt the first authorization code from the first payment permission based on the key metadata, and specifically includes: The server is further configured to decrypt the first authorization code from the first payment permission based on the key metadata and a first private key by using the asymmetric encryption algorithm.

21. The system of any of claims 18-20, wherein, The payment device is further configured to send the first payment account and the first amount to the server.

22. The system of any of claims 18-20, wherein, The first payment information further includes the first payment account and the first amount. The electronic device is further configured to send the first payment account and the first amount to the server.

23. The system of any one of claims 18-21, wherein, The electronic device is further configured to send the first payment account, the first payment permission and the key metadata to the server, specifically including: The electronic device is further configured to send the first payment account, the first payment permission and the key metadata to the server through the payment device.

24. The system of any one of claims 18-21, wherein, The electronic device is further configured to send the first payment account, the first payment permission and the key metadata to the server, specifically including: The electronic device is further configured to send the first payment account to the server through the payment device. The electronic device is further configured to send the first payment permission and the key metadata to the server.

25. An electronic device, comprising: The chip system includes: processing circuit and interface circuit, the interface circuit is used for receiving code instruction and transmission to the processing circuit, the processing circuit is used for running the code instruction to execute the payment method of any one of the above claims 1-17.

26. A chip system, characterized by The chip system includes: processing circuit and interface circuit, the interface circuit is used for receiving code instruction and transmission to the processing circuit, the processing circuit is used for running the code instruction to execute the payment method of any one of the above claims 1-17.

27. A readable storage medium, characterized by, The computer instruction is stored, and the payment method of any one of the above claims 1-17 is realized when the computer instruction is executed by the processor.

28. A computer program product, characterised in that, The computer instruction is stored, and the payment method of any one of the above claims 1-17 is realized when the computer instruction is executed by the processor. The computer instruction is stored, and the payment method of any one of the above claims 1-17 is realized when the computer instruction is executed by the processor.

Images