+

WO2020024710A1 - 一种支付二维码的生成方法和装置 - Google Patents

一种支付二维码的生成方法和装置 Download PDF

Info

Publication number
WO2020024710A1
WO2020024710A1 PCT/CN2019/091535 CN2019091535W WO2020024710A1 WO 2020024710 A1 WO2020024710 A1 WO 2020024710A1 CN 2019091535 W CN2019091535 W CN 2019091535W WO 2020024710 A1 WO2020024710 A1 WO 2020024710A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
code
dimensional code
account
display device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2019/091535
Other languages
English (en)
French (fr)
Inventor
韩喆
郑梦雪
吴军
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Priority to SG11202010354RA priority Critical patent/SG11202010354RA/en
Publication of WO2020024710A1 publication Critical patent/WO2020024710A1/zh
Priority to US17/084,284 priority patent/US11107062B2/en
Anticipated expiration legal-status Critical
Priority to US17/461,461 priority patent/US11836703B2/en
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3226—Use of secure elements separate from M-devices
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce

Definitions

  • the present disclosure relates to the field of payment technology, and in particular, to a method and device for generating a payment two-dimensional code.
  • one or more embodiments of the present specification provide a method and device for generating a payment two-dimensional code to improve the security of bar code payment.
  • a method for generating a payment two-dimensional code is provided.
  • the method is performed by a security chip in a two-dimensional code display device.
  • the method includes:
  • the two-dimensional code display device displays the code information as a two-dimensional code for payment, the two-dimensional code including the account ID, and the The QR code changes dynamically.
  • a payment transaction method is provided. The method is executed by a payment server, and the method includes:
  • the payment transaction request is sent by scanning a dynamic QR code on a QR code display device, and the payment transaction request carries an account ID of a payment account obtained by parsing the dynamic QR code
  • the account identification is signed by a private key via a security chip on a two-dimensional code display device;
  • a payment two-dimensional code generating device is provided.
  • the device is applied to a security chip in a two-dimensional code display device.
  • the device includes:
  • An information receiving module configured to receive code information to be signed, where the code information includes an account identifier of a payment account bound to the two-dimensional code display device;
  • a signature processing module configured to use the private key to sign code information when confirming that the private key stored in the security chip is available; the available state indicates that the private key has obtained a digital certificate;
  • a code sending module is configured to return the signed code information to the two-dimensional code display device, so that the two-dimensional code display device displays the code information as a two-dimensional code for payment, and the two-dimensional code includes all The account ID is described, and the two-dimensional code is dynamically changed.
  • a payment transaction device is provided.
  • the device is applied to a payment server, and the device includes:
  • the request receiving module is configured to receive a payment transaction request, where the payment transaction request is sent by scanning a dynamic two-dimensional code on a two-dimensional code display device, and the payment transaction request carries the dynamic two-dimensional code obtained by analyzing The account ID of the payment account of which the private key is signed by the security chip on the QR code display device;
  • the transaction processing module is configured to perform payment transaction processing according to the account ID of the payment account after the public key verification of the account ID of the payment account is passed.
  • a display device for paying a two-dimensional code includes a security chip.
  • the security chip stores security data, and the security data is displayed by the payment server according to the payment bound by the two-dimensional code.
  • the account is obtained and issued to the security chip;
  • the security chip includes a memory, a processor, and computer instructions stored on the memory and executable on the processor. When the processor executes the instructions, the following steps are implemented:
  • Receiving code information to be signed where the code information includes an account identifier of a payment account bound to the two-dimensional code display device; and the code information is generated according to the security data;
  • the signed code information is returned to the two-dimensional code display device, so that the two-dimensional code display device displays the two-dimensional code corresponding to the code information for payment on the display screen, and the two-dimensional code includes the account number Identification, and the two-dimensional code changes dynamically.
  • a payment server includes a memory, a processor, and computer instructions stored on the memory and executable on the processor. When the processor executes the instructions, the following steps are implemented:
  • the payment transaction request is sent by scanning a dynamic QR code on a QR code display device, and the payment transaction request carries an account ID of a payment account obtained by parsing the dynamic QR code
  • the account identification is signed by a private key via a security chip on a two-dimensional code display device;
  • the method and device of one or more embodiments of this specification digitally sign a two-dimensional code by using an SE chip in the device, and the private key used for signing has been digitally authenticated. This method ensures the security of the two-dimensional code transaction Sex.
  • FIG. 1 is an application system architecture diagram of a payment transaction method provided by one or more embodiments of the present specification
  • FIG. 2 is a schematic diagram of a chip execution process provided by one or more embodiments of the present specification
  • FIG. 3 is a schematic diagram of generating a two-dimensional code provided by one or more embodiments of the present specification
  • FIG. 5 is a flowchart of a chip signing process provided by one or more embodiments of the present specification.
  • FIG. 6 is a schematic structural diagram of a two-dimensional code generating device provided by one or more embodiments of the present specification
  • FIG. 7 is a schematic structural diagram of a payment transaction device provided by one or more embodiments of the present specification.
  • At least one embodiment of the present specification provides a payment transaction method, which uses a method including a digital certificate and an electronic signature to verify the transaction, and is also generating a payment code.
  • a secure chip (Secure Element, usually provided in chip form) is used to ensure the security of barcode payment.
  • the merchant can present the payment code, and the payment code can be generated by the payment QR code generation method of at least one embodiment of this specification, and the payer can scan the payment code to pay ;
  • the payment code presented by the merchant is a dynamic code that can change dynamically. It can be understood that this method can also be applied to the generation of payment codes. In the following description, the generation of a payment code is taken as an example for description.
  • Figure 1 illustrates the application system architecture of this payment transaction method.
  • a merchant can purchase a QR code display device 11, which can include a security chip (SE) 12, which can be downloaded in the security chip 12.
  • SE security chip
  • An applet 13 can be installed.
  • the applet 13 can be an application running in the Javacard operating system, and generally runs in an SE chip.
  • the Applet 13 can be used to perform processing such as signing a payment code in the SE chip.
  • the two-dimensional code display device 11 may have a device operating system.
  • the system may be an embedded system (or other systems such as Android).
  • a code processing component SDK 14 can be included, and the code processing component 14 can cooperate with Applet 13 to complete the generation of a dynamic receipt code.
  • the finally generated dynamic receipt code can be displayed on the display 15 for the payer to scan the receipt code for payment.
  • the SDK in FIG. 1 is an example of an embedded operating system set on a two-dimensional code display device, but the setting position of the SDK is not limited to this.
  • the SDK can also be set in an SE chip. , This can be more secure.
  • the SDK is set in the embedded system as an example.
  • the security chip 12 can be connected to the payment server 16 in the cloud, and the payment server 16 can send some information required during the generation of the payment code to the security chip 12; and the security chip 12 and the payment server 16 can also perform payment transactions. China cooperates with security protection.
  • the security chip 12 can use the private key to sign the payment code, and the payment server can use the corresponding public key to decrypt to obtain the information in the payment code, thereby ensuring the security of the payment transaction.
  • QR code as a payment code as an example to illustrate how a merchant uses the method provided in at least one embodiment of this manual to collect money. It also describes how to use a QR code to display the device and how the device and the payment server Interaction and cooperation.
  • the two-dimensional code display device 11 is connected to a cloud payment server for binding.
  • the payment server 16 may generate a unique ID for device management inside the server according to the MAC address of the device (or other attributes unique to the device), and the unique ID may be referred to as a device identifier (deviceId).
  • deviceId device identifier
  • the payment server 16 may send the device identification to a two-dimensional code display device for storage, and may specifically store the device identification in the security chip 12.
  • the SE can also store an encryption key. Whenever the device ID needs to be read from the SE, the SE can use the encryption key to authenticate the device.
  • the identification is encrypted (or the device identification may be mixed with other information such as random numbers and timestamps before being encrypted to increase the complexity of decryption) to prevent other systems other than the cloud payment server from obtaining this information.
  • the payment server 16 can also send some other device-related configuration information to the security chip 12, for example, a key to connect to the network, which can be used for subsequent QR code display devices and payments.
  • the data transmitted after the connection between the servers is encrypted to ensure data security.
  • the device is bound to the merchant's payment account, and the device is initialized:
  • the storage device identification in the above-mentioned two-dimensional code display device may be completed before the device leaves the factory. Therefore, when a merchant purchases a two-dimensional code display device, the device identification is already stored in the device. When the device is used for the first time, the merchant can activate the purchased QR code display device.
  • the device can display a QR code, and the QR code includes the above-mentioned device identification stored in the SE chip.
  • the device identification in the two-dimensional code can also be encrypted by using a key, and the payment server can also store a decryption key in advance, and can decrypt the encrypted device identification to obtain the identification.
  • the merchant can scan the two-dimensional code with his mobile phone.
  • the payment application corresponding to the payment server is installed on the mobile phone, and the code can be scanned by using the "scan and scan" function in the payment application. After scanning the code, the payment application can send a message to the payment server 16 which carries: the device identification of the encrypted two-dimensional code display device and the payment account used by the merchant's payment application (the payment application uses the account login).
  • the payment server 16 may perform a binding operation with the payment account of the merchant and the two-dimensional code display device purchased by the merchant according to the message. For example, you can record the following correspondence on the server side:
  • QR code display equipment Payment account ID-1 Account-1
  • the payment server can notify the SE chip that the binding has been completed, and trigger the chip to start the process shown in FIG. 2, and the SE chip starts to generate the public and private key pair. It should be noted that this example does not limit the execution order between steps:
  • step 200 the security chip generates a public-private key pair.
  • step 202 the security chip uploads the public key to a cloud payment server.
  • step 204 the payment server sends the public key to a certificate center for authentication.
  • step 206 the payment server receives the digital certificate returned by the authentication.
  • the digital certificate indicates that the public key in the public-private key pair has been authenticated.
  • step 208 the payment server issues a digital certificate to the security chip.
  • step 210 the security chip stores the digital certificate and sets the private key to a usable state.
  • the SE chip After receiving the digital certificate, the SE chip knows that the public key in the public and private key that it just generated has been recognized, and the public and private key pair can be used for signing and checking later, otherwise, if the authentication is not passed, the SE The chip will not use the public-private key pair just generated.
  • the SE chip can store the digital certificate and set the corresponding private key to a usable state.
  • step 212 the payment server generates secure data according to the payment account.
  • the payment server can perform two aspects of processing:
  • the payment server can store the public key in the corresponding relationship in Table 1.
  • the storage of the public key can be used for subsequent payment requests initiated by scanning the payment code on the QR code display device, using the public key for Decrypt.
  • the updated correspondence can be seen in Table 2:
  • the payment server can generate secure data.
  • the security data is related to the user. For example, if different merchants have different payment accounts, the corresponding security data can be different.
  • the security data here may include related configuration parameters used to generate the two-dimensional code, and may also include other parameters not related to the two-dimensional code generation.
  • step 214 the payment server sends the secure data to the secure chip storage.
  • the initialization of the two-dimensional code display device is completed.
  • the cloud payment server can be triggered to transfer the merchant ’s
  • the payment account is bound to the device, and triggers the generation of the device's public and private keys and the issuing of configuration parameters.
  • the security chip of the QR code display device already stores the digital certificate and available private keys, and also stores some configuration parameters to be used in the QR code generation process. You can then use the device to collect payments.
  • the SE can also be triggered to delete the public and private key pair.
  • a merchant can unbind through a payment application on its mobile phone. After receiving the unbinding request, the payment server can notify the SE to delete the public and private key pair.
  • the merchant then uses the device to collect payments:
  • the merchant can use the device to receive payments.
  • the device can generate and display a dynamic QR code, and the payer can scan the dynamic QR code for payment.
  • the embedded system of the two-dimensional code display device can send instructions to the SE chip, indicating that subsequent operations are processed by the applet in the chip.
  • Figure 3 illustrates the process of generating a two-dimensional code in cooperation with the SDK and Applet. As shown in Figure 3, it can include the following processing:
  • the applet can pass the security data stored in the chip to the code processing component SDK.
  • the SDK processes the security data and generates code information to be signed based on the security data.
  • the code information may include an account ID of a payment account bound to the two-dimensional code display device, the payer can parse and obtain the account ID when scanning the code, and the payment server can obtain the payment account accordingly.
  • the applet can complicate the code information, for example, at least one of the code information is mixed with a timestamp or a random number; the complex code information is explicitly processed, and the private key is used.
  • the code information after signing can be converted into a two-dimensional code for display.
  • the applet can determine whether the private key is available. If it is not available (for example, it is not marked as available), it can refuse to sign to prevent possible transaction risks.
  • the chip can send the signed code information to the embedded system of the two-dimensional code display device, so that the device operating system displays the code information as a two-dimensional code and displays it on the display screen.
  • the two-dimensional code also includes the account ID.
  • the generated two-dimensional code is a dynamic two-dimensional code.
  • the implementation of the dynamic two-dimensional code generation includes the following two examples of two-dimensional code refresh mechanisms:
  • Figure 3 illustrates the generation process of a two-dimensional code. Then, after a preset period of time, the security chip can pass the code seed to the code processing component SDK in the two-dimensional code display device. , And then execute each process in FIG. 3 in order to generate a two-dimensional code for display. For example, the process of FIG. 3 is executed every interval t.
  • the security chip of the device can transmit the security data to the code processing component SDK in the two-dimensional code display device to start a new two-dimensional code generation.
  • the code refresh notification is sent by the payment server when it receives a code scan event trigger. For example, when a payer scans a code, a code scan will notify the payment server. When the payment server receives a code scan event trigger, it can report to the SE. The chip sends a code refresh notification. Then, after one payer makes a payment, the payment code on the device will be refreshed once; after the other payer makes a payment, the payment code on the device will be refreshed again, thereby achieving a dynamic refresh.
  • the generated two-dimensional code may be different.
  • the difference may be: the code information generated by the code processing component according to the security data is dynamically changed, so that the receipt code changes accordingly; or, When the security chip signs the code information, the code information is mixed with a random number or a timestamp that dynamically changes, so that the two-dimensional code changes correspondingly.
  • FIG. 4 illustrates payment processing on the payment server side in at least one embodiment of the present specification.
  • the payment processing may be executed after the payment server receives a payment request initiated by the payer scanning the dynamic payment code, as shown in FIG. 4, Can include:
  • step 400 the payment server receives a payment transaction request sent by the payer, where the payment transaction request is sent after the payer scans the dynamic payment code on the two-dimensional code display device.
  • the payment transaction request may carry code information signed by a security chip private key on a two-dimensional code display device, and the code information may include an account identifier that uniquely identifies a payment account.
  • step 402 the payment server obtains the payment account of the payee according to the account ID, and obtains the public key corresponding to the payment account.
  • the payment server may search the correspondence relationship between the pre-stored payment account and the public key, and obtain the public key used for signature verification.
  • step 404 the payment server performs public key verification on the account ID signed by the private key.
  • step 406 the payment server performs payment transaction processing according to the payment account after the verification is passed.
  • the payment account of the payer transfers to the payment account of the merchant.
  • the main processing is performed by the applet.
  • the processing performed by the applet may be the process shown in FIG. 5, including:
  • code information transmitted by a two-dimensional code display device is received.
  • it may be code information transmitted by the SDK in the embedded system of the device to the SE chip, or may also be code information sent by the SDK located in the SE chip.
  • step 502 when it is confirmed that the private key stored in the security chip is in a usable state, the code information is signed using the private key; the available state indicates that the private key has obtained a digital certificate.
  • step 504 the signed code information is returned to the two-dimensional code display device, so that the two-dimensional code display device displays the code information as a two-dimensional code for payment, and the two-dimensional code dynamically changes.
  • At least one embodiment of the present specification also provides a two-dimensional code display device, which uses a digital certificate and digital signature to generate a dynamic two-dimensional code to ensure the security of the two-dimensional code transaction, and,
  • the two-dimensional code display device can enable a merchant to use a dynamic payment code to collect money, which is convenient and safe.
  • the apparatus may include: an information receiving module 61, a signature processing module 62, and a code sending module 63.
  • An information receiving module 61 configured to receive code information to be signed, where the code information includes an account identifier of a payment account bound to the two-dimensional code display device;
  • a signature processing module 62 configured to use the private key to sign code information when confirming that the private key stored in the security chip is available; the available state indicates that the private key has obtained a digital certificate;
  • the code sending module 63 is configured to return the signed code information to the two-dimensional code display device, so that the two-dimensional code display device displays the code information as a two-dimensional code for payment, and the two-dimensional code includes The account ID, and the two-dimensional code changes dynamically.
  • the information receiving module 61 is further configured to receive security data issued by a payment server, where the security data is obtained by the payment server according to a payment account bound to a two-dimensional code display device; storing the security data;
  • the code sending module 63 is further configured to transmit the security data to a code processing component (SDK) in a two-dimensional code display device, so that the code processing component generates code information to be signed according to the security data.
  • SDK code processing component
  • the signature processing module 62 is further configured to generate a public-private key pair; upload the public key to the payment server, so that the payment server sends the public key to a certificate center for authentication; and receives and stores the payment server
  • the issued digital certificate indicates that the public key in the public-private key pair has been authenticated; and sets the private key in the public-private key pair to the available state.
  • the apparatus may include: a request receiving module 71 and a transaction processing module 72.
  • the request receiving module 71 is configured to receive a payment transaction request, where the payment transaction request is sent by scanning a dynamic two-dimensional code on a two-dimensional code display device, and the payment transaction request carries an analysis of the dynamic two-dimensional code.
  • the obtained account ID of the payment account where the account ID is signed by a private key via a security chip on the QR code display device;
  • the transaction processing module 72 is configured to perform payment transaction processing according to the account ID of the payment account after the public key verification of the account ID of the payment account is passed.
  • each step in the process shown in the foregoing method embodiment is not limited to the order in the flowchart.
  • the description of each step may be implemented in the form of software, hardware, or a combination thereof.
  • those skilled in the art may implement it in the form of software code, and may be computer-executable capable of implementing the logical functions corresponding to the steps. instruction.
  • the executable instructions may be stored in a memory and executed by a processor in the device.
  • one or more embodiments of the present specification simultaneously provide a display device for paying a two-dimensional code.
  • the device includes a security chip.
  • the security chip stores security data.
  • the security data is provided by
  • the payment server obtains and issues to the security chip according to the payment account bound to the two-dimensional code display device;
  • the security chip may include a processor, a memory, and computer instructions stored on the memory and executable on the processor.
  • the processor executes the instructions to implement the following steps:
  • Receiving code information to be signed where the code information includes an account identifier of a payment account bound to the two-dimensional code display device; and the code information is generated according to the security data;
  • the signed code information is returned to the two-dimensional code display device, so that the two-dimensional code display device displays the two-dimensional code corresponding to the code information for payment on the display screen, and the two-dimensional code includes the account number Identification, and the two-dimensional code changes dynamically.
  • one or more embodiments of the present specification simultaneously provide a payment server, the server including a processor, a memory, and computer instructions stored on the memory and executable on the processor, the processing The processor executes the instructions to implement the following steps:
  • the payment transaction request is sent by scanning a dynamic QR code on a QR code display device, and the payment transaction request carries an account ID of a payment account obtained by parsing the dynamic QR code
  • the account identification is signed by a private key via a security chip on a two-dimensional code display device;
  • the payment server After the public key verification of the account ID of the payment account is passed, the payment server performs payment transaction processing according to the account ID of the payment account.
  • the devices or modules described in the foregoing embodiments may be specifically implemented by a computer chip or entity, or may be implemented by a product having a certain function.
  • a typical implementation device is a computer, and the specific form of the computer may be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email sending and receiving device, and a game control Desk, tablet computer, wearable device, or a combination of any of these devices.
  • one or more embodiments of the present specification may be provided as a method, a system, or a computer program product. Therefore, one or more embodiments of this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of the present specification may adopt a computer program implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code therein The form of the product.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to work in a particular manner such that the instructions stored in the computer-readable memory produce a manufactured article including an instruction device, the instructions
  • the device implements the functions specified in one or more flowcharts and / or one or more blocks of the block diagram.
  • These computer program instructions can also be loaded on a computer or other programmable data processing device, so that a series of steps can be performed on the computer or other programmable device to produce a computer-implemented process, which can be executed on the computer or other programmable device.
  • the instructions provide steps for implementing the functions specified in one or more flowcharts and / or one or more blocks of the block diagrams.
  • One or more embodiments of the specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules.
  • program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types.
  • One or more embodiments of the present specification may also be practiced in distributed computing environments in which tasks are performed by remote processing devices connected through a communication network.
  • program modules may be located in local and remote computer storage media, including storage devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Signal Processing (AREA)
  • Finance (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Cash Registers Or Receiving Machines (AREA)

Abstract

本说明书实施例提供一种支付二维码的生成方法和装置，其中，方法可以包括：接收待加签的码信息，所述码信息中包括绑定了所述二维码显示设备的支付账号的账号标识；在确认安全芯片中存储的私钥处于可用状态时，使用私钥对码信息进行加签；可用状态表示私钥已经获得了数字证书；将加签后的码信息返回给二维码显示设备，以使得二维码显示设备将码信息显示成用于支付的二维码，所述二维码中包括所述账号标识，且所述二维码动态变化。

Description

一种支付二维码的生成方法和装置 技术领域
本公开涉及支付技术领域，特别涉及一种支付二维码的生成方法和装置。
背景技术
目前绝大部分的基于二维码的支付机具都是被扫模式，即用户出示手机上的付款码/条码，店主主动扫描用户的付款码，并进行扣款。这需要商户的设备有摄像头模块，且对摄像头的精度有一定要求，每次需要商户手动输入金额，并不适合小额高频的商户使用。并且，在条码支付业务中，对安全性有较高的要求，如果安全性较低，可以对支付限额进行控制。
发明内容
有鉴于此，本说明书一个或多个实施例提供一种支付二维码的生成方法和装置，以提高条码支付的安全性。
具体地，本说明书一个或多个实施例是通过如下技术方案实现的：
第一方面，提供一种支付二维码的生成方法，所述方法由二维码显示设备中的安全芯片执行，所述方法包括：
接收待加签的码信息，所述码信息中包括绑定了所述二维码显示设备的支付账号的账号标识；
在确认安全芯片中存储的私钥处于可用状态时，使用所述私钥对所述码信息进行加签；所述可用状态表示所述私钥已经获得了数字证书；
将加签后的码信息返回给二维码显示设备，以使得二维码显示设备将码信息显示成用于支付的二维码，所述二维码中包括所述账号标识，且所述二维码动态变化。
第二方面，提供一种支付交易方法，所述方法由支付服务器执行，所述方法包括：
接收支付交易请求，所述支付交易请求是通过扫描二维码显示设备上的动态二维码后发送，并且，所述支付交易请求中携带通过解析该动态二维码得到的支付账号的账号 标识，所述账号标识经二维码显示设备上的安全芯片进行私钥加签；
在对所述支付账号的账号标识进行公钥验签通过后，根据支付账号的账号标识进行支付交易处理。
第三方面，提供一种支付二维码的生成装置，所述装置应用于二维码显示设备中的安全芯片，所述装置包括：
信息接收模块，用于接收待加签的码信息，所述码信息中包括绑定了所述二维码显示设备的支付账号的账号标识；
签名处理模块，用于在确认安全芯片中存储的私钥处于可用状态时，使用所述私钥对码信息进行加签；所述可用状态表示所述私钥已经获得了数字证书；
显码发送模块，用于将加签后的码信息返回给二维码显示设备，以使得二维码显示设备将码信息显示成用于支付的二维码，所述二维码中包括所述账号标识，且所述二维码动态变化。
第四方面，提供一种支付交易装置，所述装置应用于支付服务器，所述装置包括：
请求接收模块，用于接收支付交易请求，所述支付交易请求是通过扫描二维码显示设备上的动态二维码后发送，并且，所述支付交易请求中携带通过解析该动态二维码得到的支付账号的账号标识，所述账号标识经二维码显示设备上的安全芯片进行私钥加签；
交易处理模块，用于在对所述支付账号的账号标识进行公钥验签通过后，根据支付账号的账号标识进行支付交易处理。
第五方面，提供一种支付二维码的显示设备，所述设备包括：安全芯片，所述安全芯片中存储有安全数据，所述安全数据由支付服务器根据二维码显示设备绑定的支付账号得到并下发至安全芯片；
所述安全芯片包括存储器、处理器，以及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行指令时实现以下步骤：
接收待加签的码信息，所述码信息中包括绑定了所述二维码显示设备的支付账号的账号标识；且所述码信息是根据所述安全数据生成得到；
在确认安全芯片中存储的私钥处于可用状态时，使用所述私钥对所述码信息进行加签；所述可用状态表示所述私钥已经获得了数字证书；
将加签后的码信息返回给二维码显示设备，以使得二维码显示设备将码信息对应的 用于支付的二维码在显示屏上显示，所述二维码中包括所述账号标识，且所述二维码动态变化。
第六方面，提供一种支付服务器，所述服务器包括存储器、处理器，以及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行指令时实现以下步骤：
接收支付交易请求，所述支付交易请求是通过扫描二维码显示设备上的动态二维码后发送，并且，所述支付交易请求中携带通过解析该动态二维码得到的支付账号的账号标识，所述账号标识经二维码显示设备上的安全芯片进行私钥加签；
在对所述支付账号的账号标识进行公钥验签通过后，根据支付账号的账号标识进行支付交易处理。
本说明书一个或多个实施例的方法和装置，通过利用设备中的SE芯片对二维码进行数字签名，并且用于签名的私钥经过了数字认证，该方法保证了二维码交易的安全性。
附图说明
为了更清楚地说明本说明书一个或多个实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书一个或多个实施例中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本说明书一个或多个实施例提供的支付交易方法的应用系统架构图；
图2为本说明书一个或多个实施例提供的芯片执行流程示意图；
图3为本说明书一个或多个实施例提供的二维码生成的示意图；
图4为本说明书一个或多个实施例提供的支付服务器的交易处理；
图5为本说明书一个或多个实施例提供的芯片加签处理的流程图；
图6为本说明书一个或多个实施例提供的二维码生成装置的结构示意图；
图7为本说明书一个或多个实施例提供的支付交易装置的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本说明书一个或多个实施例中的技术方案，下面将结合本说明书一个或多个实施例中的附图，对本说明书一个或多个实施例中的技术 方案进行清楚、完整地描述，显然，所描述的实施例仅仅是一部分实施例，而不是全部的实施例。基于本说明书一个或多个实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
近年来，扫码支付几乎渗透到人们生活中的各个角落，现在很多商店，超市，零售商店，街边摊位和生活用品的小商贩，他们都有着自己的收款码，买东西的人也早已经习惯了这种方便快捷的付钱方式。商家在收款时一般采用静态条码，例如粘贴的静态收款码。通过扫“条码”或者“二维码”，完成收付款的支付方式，都称之为条码支付。
然而，条码支付本身存在一定的技术风险，并且随着市场日益壮大，安全问题也越发凸出。为了提高条码支付的安全性，本说明书至少一个实施例提供了一种支付交易方法，该方法使用了包括数字证书和电子签名在内的方式对交易进行验证，并且还在收款码的生成中使用了安全芯片(Secure Element，安全元件，通常以芯片形式提供)，以保证条码支付的安全。
在本说明书至少一个例子的应用场景中，可以由商家出示收款码，通过本说明书至少一个实施例的支付二维码的生成方式来生成该收款码，付款方可以扫描该收款码付款；并且，该商家出示的收款码是可以动态变化的动态码。可以理解的是，该方法同样也可以应用于付款码的生成。在如下的描述中，是以收款码的生成为例进行描述。
图1示例了本支付交易方法的应用系统架构图，如图1所示，商家可以购买一个二维码显示设备11，在该设备中可以包括安全芯片(SE)12，安全芯片12中可以下载和安装一个Applet 13，该Applet 13可以是Javacard操作系统中运行的应用，一般运行在SE芯片中。在本说明书提供的支付交易方法中，Applet 13可以用于在SE芯片中执行收款码的加签等处理。
请继续参见图1，二维码显示设备11在SE芯片中的Javacard操作系统之外，还可以具有一个设备操作系统，该系统可以是嵌入式系统(或者是安卓等其他系统)，在该嵌入式系统中，可以包括一个码处理组件SDK 14，该码处理组件14可以与Applet 13配合共同完成动态收款码的生成。最终生成的动态收款码可以显示在显示屏15上，以供付款方扫描该收款码进行付款。此外，需要说明的是，图1中的SDK是以设置在二维码显示设备的嵌入式操作系统为例，但是SDK的设置位置并不局限于此，比如，SDK也可以设置在SE芯片中，这样可以更加安全。如下的例子描述中，以SDK设置在嵌入式系统为例。
此外，安全芯片12可以与云端的支付服务器16连接，支付服务器16可以向安全芯片12下发一些收款码生成过程中所需要的信息；并且，安全芯片12与支付服务器16也可以在支付交易中配合进行安全保障，比如，安全芯片12可以使用私钥对收款码进行加签，而支付服务器可以利用对应的公钥解密来获取收款码中的信息，从而保证支付交易的安全。
如下以二维码是收款码为例，示例一个商家如何使用本说明书至少一个实施例提供的方法来进行收款，其中，还将描述如何使用二维码显示设备以及该设备与支付服务器之间的交互配合。
首先，设备与支付服务器的绑定：
在可信环境中，将二维码显示设备11连接到云端的支付服务器进行绑定。
例如，支付服务器16可以根据该设备的MAC地址(也可以是设备特有的其他属性)，生成服务器内部进行设备管理使用的唯一ID，该唯一ID可以称为设备标识(deviceId)。
支付服务器16可以将所述的设备标识下发到二维码显示设备中存储，具体可以是将该设备标识存储在安全芯片12中。
此外，如果出于安全考虑，设备标识不允许被直接读取，则SE中还可以存储加密密钥，当每次需要由SE中读取该设备标识时，SE可以使用该加密密钥对设备标识进行加密(或者，还可以将该设备标识混合随机数、时间戳等其他信息后再加密，以提高解密的复杂度)，防止除云端支付服务器之外的其他系统获取到该信息。
在设备标识之外，支付服务器16还可以向安全芯片12中下发其他一些只与设备有关的配置信息，例如，连接网络的密钥，该密钥可以用于后续二维码显示设备与支付服务器之间连接后的传输数据进行加密使用，以保证数据安全。
接着，设备与商家的支付账户之间绑定，且将设备进行初始化操作：
例如，上述的二维码显示设备中存储设备标识，可以是在设备出厂前就已经完成。因此，当商家购买了一个二维码显示设备后，该设备中已经存储有上述的设备标识。在第一次使用该设备时，商家可以启动购买的二维码显示设备，该设备上可以显示一个二维码，二维码中包括SE芯片中存储的上述设备标识。此外，二维码中的设备标识也可以使用密钥加密，支付服务器也可以预先存储了解密密钥，能够对加密的设备标识进行解密获得该标识。
商家可以用自己的手机扫描该二维码，手机上安装有支付服务器对应的支付应用，可以是用支付应用中的“扫一扫”功能来进行扫码。当扫码后，支付应用可以向支付服务器16发送一个消息，其中携带：加密的二维码显示设备的设备标识、以及商家的支付应用使用的支付账号(支付应用使用账号登录)。
支付服务器16可以根据该消息，将商家的支付账号与商家购买的二维码显示设备进行绑定操作。例如，可以在服务器侧记录如下对应关系：
表1 支付账号和设备绑定
二维码显示设备 支付账号
ID-1 Account-1
在绑定了商家的支付账号和商家的二维码显示设备后，支付服务器可以通知SE芯片已经完成绑定，并触发芯片开始执行图2所示的流程，SE芯片开始生成公私钥对。需要说明的是，本例子并不限制各步骤之间的执行顺序：
在步骤200中，安全芯片生成公私钥对。
在步骤202中，安全芯片将公钥上传到云端的支付服务器。
在步骤204中，支付服务器将公钥发往证书中心进行认证。
在步骤206中，支付服务器接收到认证通过返回的数字证书。所述数字证书表明所述公私钥对中的公钥已经被认证通过。
在步骤208中，支付服务器将数字证书下发到安全芯片。
在步骤210中，安全芯片存储该数字证书，并将私钥置为可用状态。
本步骤中，SE芯片在接收到数字证书后，知晓自己刚刚生成的公私钥中的公钥已经被认可，后面都可以使用该公私钥对进行加签验签，否则，如果没通过认证，SE芯片不会使用刚刚生成的公私钥对。SE芯片可以存储该数字证书，并将对应的私钥设置为可用状态。
在步骤212中，支付服务器根据支付账号生成安全数据。
本步骤中，支付服务器可以进行两方面的处理：
一个方面是，支付服务器可以将公钥存储在表1的对应关系中，存储该公钥可以用于后续对扫描该二维码显示设备上的收款码发起的支付请求，使用该公钥进行解密。更新后的对应关系可以参见表2所示：
表2 支付账号和设备绑定
二维码显示设备的设备标识 支付账号 公钥
ID-1 Account-1 public key-1
另一个方面是，支付服务器可以生成安全数据。其中，安全数据都是与用户有关的，比如，不同的商家具有不同的支付账号，那么对应的安全数据就可以不同。这里的安全数据，可以包括用于生成二维码的相关配置参数，也可以包括与二维码生成无关的其他参数。
在步骤214中，支付服务器将安全数据下发到安全芯片存储。
至此，完成了二维码显示设备的初始化。由上述描述可以看到，商家在拿到二维码显示设备以后，只要用手机上的支付应用中的“扫一扫”扫描设备上的二维码，就可以触发云端的支付服务器将商家的支付账号和设备绑定，并且触发设备公私钥的生成、以及配置参数的下发等处理。设备初始化完成后，二维码显示设备的安全芯片中已经存储了数字证书和可用的私钥，还存储了二维码生成过程中要使用到的一些配置参数。接下来就可以使用该设备进行收款了。
此外，当商户解绑后，也可以触发SE删除公私钥对。比如，商户可以通过自己手机上的支付应用来解绑，支付服务器接收到解绑请求后，可以通知SE删除公私钥对。
然后，商家使用设备进行收款：
在设备初始化完成后，商家就可以使用该设备进行收款。在日常使用中，设备可以生成并显示动态二维码，付款方可以扫描该动态二维码进行付款。
其中，二维码显示设备的嵌入式系统可以向SE芯片发送指令，表明后续操作都由芯片中的Applet进行处理。图3示意了SDK与Applet配合生成二维码的过程，如图3所示，可以包括如下处理：
首先，Applet可以将芯片中存储的安全数据传给码处理组件SDK。
接着，SDK对安全数据进行处理，根据安全数据生成待加签的码信息。该码信息中可以包括绑定了所述二维码显示设备的支付账号的账号标识，付款方扫码时就可以解析得到账号标识，并且支付服务器可以据此得到支付账号。
最后，在SE芯片中，Applet可以对码信息进行复杂化处理，例如，对码信息混合时间戳或者随机数的至少一种；并对复杂处理后的码信息进行显码处理，并使用私钥进行加签，加签后的码信息就可以转换成二维码进行显示了。其中，Applet在使用私钥前， 可以先确定该私钥是否可用，如果不可用(比如，未标记为可用状态)，则可以拒绝加签，以防止可能发生的交易风险。
在加签后，芯片可以将加签后的码信息发送给二维码显示设备的嵌入式系统，以使得设备操作系统将码信息显示成二维码，在显示屏上进行显示，该二维码中也包括了账号标识。通过将二维码的生成放入SE芯片中进行黑盒处理，提高了二维码的安全性，使得二维码信息很难被篡改。
此外，生成的二维码是动态二维码，该动态二维码生成的实现，如下列举两种示例的二维码刷新机制：
例如，可以是定时刷新，图3示例的是一次二维码的生成过程，那么可以在每隔预设的时间段后，安全芯片将码种子传给二维码显示设备中的码处理组件SDK，然后依次执行图3中的各个处理，生成二维码进行显示。比如，每间隔时间t，就执行一次图3的流程。
又例如，还可以是事件触发二维码刷新。每次一个付款方扫描了设备上的收款码后，将向支付服务器发送支付交易请求，请求付款。设备的安全芯片可以在接收到支付服务器发送的码刷新通知后，将安全数据传给二维码显示设备中的码处理组件SDK，开始新的一次二维码生成。所述码刷新通知是支付服务器在接收到扫码事件触发时发送，比如，一个付款方在扫码付款时，一扫码将通知支付服务器，支付服务器接收到扫码事件触发，则可以向SE芯片发送码刷新通知。那么，一个付款方付款后，设备上的收款码将刷新一次；另一个付款方付款后，设备上的收款码又将刷新一次，从而实现动态刷新。
每次执行图3的二维码生成过程，生成的二维码可以不同，这种不同可以是：码处理组件根据安全数据生成的码信息是动态变化的，使得收款码对应变化；或者，安全芯片在对所述码信息进行加签时，对码信息混合动态变化的随机数或者时间戳，使得二维码对应变化。
上述说明了二维码显示设备如何生成动态的二维码进行收款，在该收款码的生成过程中，使用了数字证书和电子签名，而且是动态的收款码。接着，图4示意了本说明书至少一个实施例中的支付服务器侧的支付处理，该支付处理可以是支付服务器收到了付款方扫描动态收款码发起的支付请求后执行，如图4所示，可以包括：
在步骤400中，支付服务器接收付款方发送的支付交易请求，所述支付交易请求是付款方扫描二维码显示设备上的动态收款码后发送。
例如，所述支付交易请求中可以携带：通过二维码显示设备上的安全芯片私钥加签的码信息，该码信息中可以含有唯一标识支付账号的账号标识。
在步骤402中，支付服务器根据所述账号标识得到收款方的支付账号，并获取支付账号对应的公钥。
例如，支付服务器可以查找预先存储的支付账号和公钥的对应关系，得到用于验签的公钥。
在步骤404中，支付服务器对私钥加签的账号标识进行公钥验签。
在步骤406中，支付服务器在验签通过后，根据支付账号进行支付交易处理。例如，由付款方的付款账号向商家的支付账号进行转账。
由上述的支付交易方法的描述可以看到，在SE芯片中，主要的处理是由Applet来执行的。在收款码的生成过程中，Applet所执行的处理可以是图5所示的流程，包括：
在步骤500中，接收二维码显示设备传入的码信息。例如，可以是设备的嵌入式系统中的SDK传给SE芯片的码信息，或者还可以是位于SE芯片中的SDK发送的码信息。
在步骤502中，在确认安全芯片中存储的私钥处于可用状态时，使用所述私钥对所述码信息进行加签；所述可用状态表示所述私钥已经获得了数字证书。
在步骤504中，将加签后的码信息返回给二维码显示设备，以使得二维码显示设备将码信息显示成用于支付的二维码，所述二维码动态变化。
此外，本说明书的至少一个实施例，还提供了一种二维码显示设备，该设备利用了数字证书和数字签名，来生成动态二维码，保证了二维码交易的安全性，并且，该二维码显示设备可以使得商家能够利用动态收款码进行收款，收款方便且安全。
为了实现上述的支付二维码的生成方法，本说明书至少一个实施例提供了一种支付二维码的生成装置，该装置应用于二维码显示设备中的安全芯片。如图6所示，该装置可以包括：信息接收模块61、签名处理模块62和显码发送模块63。
信息接收模块61，用于接收待加签的码信息，所述码信息中包括绑定了所述二维码显示设备的支付账号的账号标识；
签名处理模块62，用于在确认安全芯片中存储的私钥处于可用状态时，使用所述私钥对码信息进行加签；所述可用状态表示私钥已经获得了数字证书；
显码发送模块63，用于将加签后的码信息返回给二维码显示设备，以使得二维码显示设备将码信息显示成用于支付的二维码，所述二维码中包括所述账号标识，且所述二维码动态变化。
在一个例子中，信息接收模块61，还用于接收支付服务器下发的安全数据，所述安全数据是支付服务器根据二维码显示设备绑定的支付账号得到；存储所述安全数据；
所述显码发送模块63，还用于将所述安全数据传给二维码显示设备中的码处理组件(SDK)，以使得所述码处理组件根据安全数据生成待加签的码信息。
在一个例子中，签名处理模块62，还用于生成公私钥对；将公钥上传到所述支付服务器，以使得所述支付服务器将公钥发往证书中心进行认证；接收并存储支付服务器下发的数字证书，所述数字证书表明所述公私钥对中的公钥已经被认证通过；设置公私钥对中的私钥为所述可用状态。
为了实现上述的支付交易方法，本说明书至少一个实施例提供了一种支付交易装置，该装置应用于支付服务器。如图7所示，该装置可以包括：请求接收模块71和交易处理模块72。
请求接收模块71，用于接收支付交易请求，所述支付交易请求是通过扫描二维码显示设备上的动态二维码后发送，并且，所述支付交易请求中携带通过解析该动态二维码得到的支付账号的账号标识，所述账号标识经二维码显示设备上的安全芯片进行私钥加签；
交易处理模块72，用于在对所述支付账号的账号标识进行公钥验签通过后，所述支付服务器根据支付账号的账号标识进行支付交易处理。
上述方法实施例中所示流程中的各个步骤，其执行顺序不限制于流程图中的顺序。此外，各个步骤的描述，可以实现为软件、硬件或者其结合的形式，例如，本领域技术人员可以将其实现为软件代码的形式，可以为能够实现所述步骤对应的逻辑功能的计算机可执行指令。当其以软件的方式实现时，所述的可执行指令可以存储在存储器中，并被设备中的处理器执行。
例如，对应于上述方法，本说明书一个或多个实施例同时提供一种支付二维码的显示设备，所述设备包括：安全芯片，所述安全芯片中存储有安全数据，所述安全数据由支付服务器根据二维码显示设备绑定的支付账号得到并下发至安全芯片；所述安全芯片可以包括处理器、存储器、以及存储在存储器上并可在处理器上运行的计算机指令， 所述处理器通过执行所述指令，用于实现如下步骤：
接收待加签的码信息，所述码信息中包括绑定了所述二维码显示设备的支付账号的账号标识；且所述码信息是根据所述安全数据生成得到；
在确认安全芯片中存储的私钥处于可用状态时，使用所述私钥对所述码信息进行加签；所述可用状态表示所述私钥已经获得了数字证书；
将加签后的码信息返回给二维码显示设备，以使得二维码显示设备将码信息对应的用于支付的二维码在显示屏上显示，所述二维码中包括所述账号标识，且所述二维码动态变化。
例如，对应于上述方法，本说明书一个或多个实施例同时提供一种支付服务器，所述服务器包括处理器、存储器、以及存储在存储器上并可在处理器上运行的计算机指令，所述处理器通过执行所述指令，用于实现如下步骤：
接收支付交易请求，所述支付交易请求是通过扫描二维码显示设备上的动态二维码后发送，并且，所述支付交易请求中携带通过解析该动态二维码得到的支付账号的账号标识，所述账号标识经二维码显示设备上的安全芯片进行私钥加签；
在对所述支付账号的账号标识进行公钥验签通过后，所述支付服务器根据支付账号的账号标识进行支付交易处理。
上述实施例阐明的装置或模块，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白，本说明书一个或多个实施例可提供为方法、系统、或计算机程序产品。因此，本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本说明书一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书一个或多个实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于数据采集设备或者数据处理设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本 公开，凡在本公开的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本公开保护的范围之内。

Claims (13)

  1. 一种支付二维码的生成方法，所述方法由二维码显示设备中的安全芯片执行，所述方法包括：
    接收待加签的码信息，所述码信息中包括绑定了所述二维码显示设备的支付账号的账号标识；
    在确认安全芯片中存储的私钥处于可用状态时，使用所述私钥对所述码信息进行加签；所述可用状态表示所述私钥已经获得了数字证书；
    将加签后的码信息返回给二维码显示设备，以使得二维码显示设备将码信息显示成用于支付的二维码，所述二维码中包括所述账号标识，且所述二维码动态变化。
  2. 根据权利要求1所述的方法，在所述接收待加签的码信息之前，所述方法还包括：
    接收支付服务器下发的安全数据，所述安全数据是支付服务器根据二维码显示设备绑定的支付账号得到；
    存储所述安全数据；
    将所述安全数据传给二维码显示设备中的码处理组件，以使得所述码处理组件根据所述安全数据生成待加签的码信息。
  3. 根据权利要求2所述的方法，所述将所述安全数据传给二维码显示设备中的码处理组件，包括：
    在每隔预设的时间段后，将所述安全数据传给所述码处理组件；
    或者，在接收到支付服务器发送的码刷新通知后，将所述安全数据传给二维码显示设备中的码处理组件，所述码刷新通知是支付服务器在接收到扫码事件触发时发送。
  4. 根据权利要求2所述的方法，所述接收支付服务器下发的安全数据之前，所述方法还包括：
    生成公私钥对；
    将公钥上传到所述支付服务器，以使得所述支付服务器将公钥发往证书中心进行认证；
    接收并存储支付服务器下发的数字证书，所述数字证书表明所述公私钥对中的公钥已经被认证通过；
    设置公私钥对中的私钥为所述可用状态。
  5. 根据权利要求2所述的方法，所述二维码动态变化，包括：
    所述码处理组件根据安全数据生成的码信息动态变化，使得二维码对应变化；或者， 安全芯片在对所述码信息进行加签时，对码信息混合动态变化的随机数或者时间戳，使得二维码对应变化。
  6. 一种支付交易方法，所述方法由支付服务器执行，所述方法包括：
    接收支付交易请求，所述支付交易请求是通过扫描二维码显示设备上的动态二维码后发送，并且，所述支付交易请求中携带通过解析该动态二维码得到的支付账号的账号标识，所述账号标识经二维码显示设备上的安全芯片进行私钥加签；
    在对所述支付账号的账号标识进行公钥验签通过后，根据支付账号的账号标识进行支付交易处理。
  7. 根据权利要求6所述的方法，所述方法还包括：查找预先存储的对应关系，得到与所述支付账号对应的公钥。
  8. 一种支付二维码的生成装置，所述装置应用于二维码显示设备中的安全芯片，所述装置包括：
    信息接收模块，用于接收待加签的码信息，所述码信息中包括绑定了所述二维码显示设备的支付账号的账号标识；
    签名处理模块，用于在确认安全芯片中存储的私钥处于可用状态时，使用所述私钥对码信息进行加签；所述可用状态表示所述私钥已经获得了数字证书；
    显码发送模块，用于将加签后的码信息返回给二维码显示设备，以使得二维码显示设备将码信息显示成用于支付的二维码，所述二维码中包括所述账号标识，且所述二维码动态变化。
  9. 根据权利要求8所述的装置，
    所述信息接收模块，还用于接收支付服务器下发的安全数据，所述安全数据是支付服务器根据二维码显示设备绑定的支付账号得到；存储所述安全数据；
    所述显码发送模块，还用于将所述安全数据传给二维码显示设备中的码处理组件，以使得所述码处理组件根据所述安全数据生成待加签的码信息。
  10. 根据权利要求8所述的装置，
    所述签名处理模块，还用于生成公私钥对；将公钥上传到所述支付服务器，以使得所述支付服务器将公钥发往证书中心进行认证；接收并存储支付服务器下发的数字证书，所述数字证书表明所述公私钥对中的公钥已经被认证通过；设置公私钥对中的私钥为所述可用状态。
  11. 一种支付交易装置，所述装置应用于支付服务器，所述装置包括：
    请求接收模块，用于接收支付交易请求，所述支付交易请求是通过扫描二维码显示 设备上的动态二维码后发送，并且，所述支付交易请求中携带通过解析该动态二维码得到的支付账号的账号标识，所述账号标识经二维码显示设备上的安全芯片进行私钥加签；
    交易处理模块，用于在对所述支付账号的账号标识进行公钥验签通过后，根据支付账号的账号标识进行支付交易处理。
  12. 一种支付二维码的显示设备，所述设备包括：安全芯片，所述安全芯片中存储有安全数据，所述安全数据由支付服务器根据二维码显示设备绑定的支付账号得到并下发至安全芯片；
    所述安全芯片包括存储器、处理器，以及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行指令时实现以下步骤：
    接收待加签的码信息，所述码信息中包括绑定了所述二维码显示设备的支付账号的账号标识；且所述码信息是根据所述安全数据生成得到；
    在确认安全芯片中存储的私钥处于可用状态时，使用所述私钥对所述码信息进行加签；所述可用状态表示所述私钥已经获得了数字证书；
    将加签后的码信息返回给二维码显示设备，以使得二维码显示设备将码信息对应的用于支付的二维码在显示屏上显示，所述二维码中包括所述账号标识，且所述二维码动态变化。
  13. 一种支付服务器，所述服务器包括存储器、处理器，以及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行指令时实现以下步骤：
    接收支付交易请求，所述支付交易请求是通过扫描二维码显示设备上的动态二维码后发送，并且，所述支付交易请求中携带通过解析该动态二维码得到的支付账号的账号标识，所述账号标识经二维码显示设备上的安全芯片进行私钥加签；
    在对所述支付账号的账号标识进行公钥验签通过后，根据支付账号的账号标识进行支付交易处理。
PCT/CN2019/091535 2018-08-02 2019-06-17 一种支付二维码的生成方法和装置 Ceased WO2020024710A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
SG11202010354RA SG11202010354RA (en) 2018-08-02 2019-06-17 Method and apparatus for generating two-dimensional payment code
US17/084,284 US11107062B2 (en) 2018-08-02 2020-10-29 Method and apparatus for generating two-dimensional payment code
US17/461,461 US11836703B2 (en) 2018-08-02 2021-08-30 Method and apparatus for generating two-dimensional payment code

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810872872.5A CN109345230B (zh) 2018-08-02 2018-08-02 一种支付二维码的生成方法和装置
CN201810872872.5 2018-08-02

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/084,284 Continuation US11107062B2 (en) 2018-08-02 2020-10-29 Method and apparatus for generating two-dimensional payment code

Publications (1)

Publication Number Publication Date
WO2020024710A1 true WO2020024710A1 (zh) 2020-02-06

Family

ID=65291282

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/091535 Ceased WO2020024710A1 (zh) 2018-08-02 2019-06-17 一种支付二维码的生成方法和装置

Country Status (5)

Country Link
US (2) US11107062B2 (zh)
CN (1) CN109345230B (zh)
SG (1) SG11202010354RA (zh)
TW (1) TW202008220A (zh)
WO (1) WO2020024710A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113298209A (zh) * 2020-02-24 2021-08-24 中国电信股份有限公司 动态二维码生成方法、系统和服务器
CN113643024A (zh) * 2021-07-06 2021-11-12 阿里巴巴新加坡控股有限公司 图形码处理方法、装置及电子设备
CN115484224A (zh) * 2022-09-16 2022-12-16 北京奇艺世纪科技有限公司 信息关联方法、二维码生成方法、装置、电子设备及介质

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109345230B (zh) * 2018-08-02 2021-07-30 创新先进技术有限公司 一种支付二维码的生成方法和装置
CN113614740B (zh) * 2019-03-29 2024-11-19 飞力凯网路股份有限公司 信息处理设备、信息处理方法、程序、通信设备、通信方法和信息处理系统
CN110335035A (zh) * 2019-04-25 2019-10-15 深圳市德名利电子有限公司 一种防盗摄的动态支付图形码验证方法和系统以及设备
CN111080302A (zh) * 2019-11-26 2020-04-28 支付宝(杭州)信息技术有限公司 一种交易风险识别方法及装置
CN111160504A (zh) * 2019-12-31 2020-05-15 天津津滨信钥信息技术有限公司 动态二维码的生成方法、装置、设备及存储介质
CN111178915A (zh) * 2019-12-31 2020-05-19 天津津滨信钥信息技术有限公司 一种动态二维码生成装置
CN112288426B (zh) * 2020-12-31 2024-03-01 飞天诚信科技股份有限公司 一种收款方法及收款系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140310182A1 (en) * 2013-04-12 2014-10-16 Mastercard International Incorporated Systems and methods for outputting information on a display of a mobile device
CN105407079A (zh) * 2015-09-25 2016-03-16 中城智慧科技有限公司 一种新型的终端安全软密钥管理方法
CN107194695A (zh) * 2017-04-25 2017-09-22 国民技术股份有限公司 交易码生成及扫描终端、交易码生成及交易方法
CN109345230A (zh) * 2018-08-02 2019-02-15 阿里巴巴集团控股有限公司 一种支付二维码的生成方法和装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9076170B2 (en) * 2010-07-01 2015-07-07 Ncr Corporation Self-service checkout pay station located remote from a produce weighing scale and methods of operating such a self-service checkout pay station
US9020886B2 (en) * 2010-12-23 2015-04-28 Ncr Corporation Peer to peer diagnostic tool
CN102842081A (zh) 2011-06-23 2012-12-26 上海易悠通信息科技有限公司 一种移动电话生成二维码并实现移动支付的方法
CN104144419B (zh) * 2014-01-24 2017-05-24 腾讯科技（深圳）有限公司 一种身份验证的方法、装置及系统
CN110502887B (zh) 2015-09-11 2023-07-18 创新先进技术有限公司 电子支付方法和装置
CN206378885U (zh) * 2016-11-14 2017-08-04 深圳市壹卡付科技有限公司 一种多卡合一的多功能壹卡支付卡
CN108256863A (zh) * 2018-01-26 2018-07-06 鼎讯网络安全技术有限公司 基于se的二维码生成、存储、识别和相关加解密的方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140310182A1 (en) * 2013-04-12 2014-10-16 Mastercard International Incorporated Systems and methods for outputting information on a display of a mobile device
CN105407079A (zh) * 2015-09-25 2016-03-16 中城智慧科技有限公司 一种新型的终端安全软密钥管理方法
CN107194695A (zh) * 2017-04-25 2017-09-22 国民技术股份有限公司 交易码生成及扫描终端、交易码生成及交易方法
CN109345230A (zh) * 2018-08-02 2019-02-15 阿里巴巴集团控股有限公司 一种支付二维码的生成方法和装置

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113298209A (zh) * 2020-02-24 2021-08-24 中国电信股份有限公司 动态二维码生成方法、系统和服务器
CN113643024A (zh) * 2021-07-06 2021-11-12 阿里巴巴新加坡控股有限公司 图形码处理方法、装置及电子设备
CN115484224A (zh) * 2022-09-16 2022-12-16 北京奇艺世纪科技有限公司 信息关联方法、二维码生成方法、装置、电子设备及介质
CN115484224B (zh) * 2022-09-16 2023-09-29 北京奇艺世纪科技有限公司 信息关联方法、二维码生成方法、装置、电子设备及介质

Also Published As

Publication number Publication date
US20220051224A1 (en) 2022-02-17
US11107062B2 (en) 2021-08-31
SG11202010354RA (en) 2020-11-27
US11836703B2 (en) 2023-12-05
US20210049582A1 (en) 2021-02-18
CN109345230A (zh) 2019-02-15
TW202008220A (zh) 2020-02-16
CN109345230B (zh) 2021-07-30

Similar Documents

Publication Publication Date Title
WO2020024710A1 (zh) 一种支付二维码的生成方法和装置
TWI706351B (zh) 二維碼支付的安全控制方法和裝置
KR102693434B1 (ko) 전자 결제 기능을 제공하는 전자 장치 및 그의 동작 방법
TWI676945B (zh) 綁定可穿戴設備的方法和裝置、電子支付方法和裝置
TWI585701B (zh) 交易請求的方法、裝置以及記錄媒體
CN111656380B (zh) 用于在进行电子钱包支付时支持具有增强的安全方法的自动Wi-Fi连接的电子装置和方法
CN106688004A (zh) 一种交易认证方法、装置、移动终端、pos终端及服务器
JP2019512192A (ja) セキュアデバイス機能へのオンラインアクセスの妥当性検査
JP2015508541A (ja) ポータブルコンピューティングデバイスを使用して安全なオフライン支払いトランザクションを行うためのシステムおよび方法
KR20150026233A (ko) 디지털 카드 기반의 결제 시스템 및 방법
WO2017079984A1 (zh) 一种注册移动销售点终端pos的方法、对应装置及系统
WO2021082466A1 (zh) 离线支付
US10382428B2 (en) Systems and methods for providing single sign-on authentication services
US20250158983A1 (en) Methods and apparatus for facilitating distribution of authenticated data with reduced hardware requirements
US20200273037A1 (en) Payment-system-based user authentication and information access system and methods
CN113904774B (zh) 一种区块链地址认证方法、装置及计算机设备
TWM589842U (zh) 以實名制手機實現的行動交易櫃檯
WO2017076173A1 (zh) 一种移动终端及其交易确认方法、装置以及一种智能卡
WO2020082833A1 (zh) 转账方法、装置及设备
HK40004383B (zh) 一种支付二维码的生成方法和装置
US12314941B2 (en) Enabling cryptographic transfers
HK40004383A (zh) 一种支付二维码的生成方法和装置
HK40036399B (zh) 一种二维码支付的安全控制方法和装置
HK40036399A (zh) 一种二维码支付的安全控制方法和装置
HK40002155A (zh) 一种二维码支付的安全控制方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19843417

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19843417

Country of ref document: EP

Kind code of ref document: A1

WWG Wipo information: grant in national office

Ref document number: 11202010354R

Country of ref document: SG

WWP Wipo information: published in national office

Ref document number: 11202010354R

Country of ref document: SG

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载