System, device, and method for verifying payment validity

Abstract

A payment terminal including one or more physical computer-readable and non-transitory storage media containing program instructions for verifying payment validity, wherein execution of the program instructions by one or more processors causes the payment terminal to receive a payment token including a first public key of a public-private key pair issued by a software development kit (SDK) disposed on a wireless device and consumer identification information, generate a payment request including a transaction information message, transmit the first payment request message and the payment token to at least one backend platform for storage in at least one database, receive a payment and transaction confirmation message from the at least one backend platform based on a payment approval generated by the at least one backend platform, and verify ownership of the first public key, which is performed at least by one backend platform based on a comparison between the public key of the signed transaction information message and the public key of the payment token.

Description

Technical Field

[0001] Some of the things described herein generally relate to methods, systems, and apparatuses for verifying payment validity. More specifically, the present disclosure relates to verifying financial transactions.

Background Art

[0002] For example, while payment cards such as credit cards and debit cards are widely known to be vulnerable to fraud, they have proven to be very beneficial for both consumers and businesses.

[0003] The configuration of fraud prevention and a safe shopping environment for payment card holders has been the goal of much effort in the field since the establishment of payment cards in the 20th century.

[0004] The Europay, VISA, Mastercard (EMV) standard enables card issuers to verify the identity of card holders through the secure transmission of payment card numbers and 4-digit PIN numbers from point-of-sale information management (POS) for verification. Once the payment card number, 4-digit PIN, and expiration date details are exposed to unauthorized persons, this person will use the credit card to purchase goods and services.

[0005] Thus, there is a need for a more secure system and method to remedy the deficiencies described above.

[0006] The present invention regarding systems, methods, and products for verifying payment validity is described below only by way of example.

[0007] According to aspects of the disclosed subject matter, the present invention can include a payment terminal including one or more tangible computer-readable non-transitory storage media including program instructions for verifying payment validity. By executing the program instructions by one or more processors, the payment terminal receives a payment token including a public key of a public-private key pair issued by a software development kit (SDK) disposed on a wireless device, generates a payment request including a transaction information message, transmits the payment request and the payment token to at least one backend platform for storage in at least one database, receives a payment and transaction confirmation message from the at least one backend platform based on payment approval by the at least one backend platform, and verifying ownership of the public key is based on a comparison between the public key of the transaction information message signed by the private key of the wireless device and the public key of the payment token by the at least one backend platform.

[0008] For example, the program instructions of the storage medium include transmitting a hash value of the transaction information message to the wireless device that initiated the payment, and the transaction confirmation is received after the wireless device compares the transaction verification message with the hash value of the transaction information message.

[0009] For example, when the program instructions of the storage medium are executed, as a result, the payment token is received via at least one of radio frequency identification (RFID) communication, short-range wireless communication, and near-field communication (NFC).

[0010] For example, the consumer identification information of the payment token includes at least one of a random number stored in the at least one backend platform, a hash value of information associated with the user, and a unique serial number.

[0011] For example, the transaction information includes at least one of a payment due date, a product list, and a franchise store ID.

[0012] In one embodiment, it can include a method for verifying payment validity, generating a payment token including the public key of the public-private key pair and consumer identification information, generating, in a point-of-sale information management system, a first payment request message including a transaction information message for payment, and supplying the payment token to a payment terminal that transmits the payment request message and the payment token to at least one backend platform, providing a public-private key pair by a wireless device, generating, by the at least one backend platform, a transaction verification message from the transaction information message, providing the transaction verification message to a device associated with the public key of the payment token, signing the transaction verification message with the private key of the public-private key pair and sending the signed transaction verification message to the at least one backend platform, verifying the ownership of the first public key by comparing a second public key provided by a second transaction information signed with the private key in the wireless device with the first public key made by the at least one backend platform, approving the transaction with a customer platform of at least one financial entity, and the at least one backend platform notifying the payment verification result to the payment terminal, the wireless device, and the customer platform by sending a transaction confirmation message from the at least one backend platform.

[0013] For example, the consumer identification information of the payment token is at least one of a random number stored in the at least one backend platform, a hash value of information associated with the user, and a unique serial number.

[0014] For example, the transaction information includes at least one payment due date, a product list, and a franchise store ID.

[0015] For example, generating a secret key that is a random number, generating a public key by hashing the secret key, hashing consumer identification information including at least one of consumer contact information, wireless device ID, payment information, geographical location information, and consumer ID number, and constructing the payment token with the hash value of the public key and the consumer identification information, whereby the payment token is generated.

[0016] In another embodiment, it can include a wireless device including one or more physical computer-readable non-transitory storage media installed with an application including program instructions for verifying payment validity, and by executing the program instructions by one or more processors, as a result, a public-private key pair is provided, a payment token including the public key of the public-private key pair is generated, the payment token is provided to the payment terminal of the point-of-sale information management system, a transaction information message is received from the payment terminal, a transaction verification message is received from at least one backend platform, based on a comparison between the transaction verification message and the transaction information message, the transaction verification message is signed with the private key of the public-private key pair and sent to the at least one backend platform, after verifying the ownership of the public key based on a comparison between the signed transaction message and the public key of the payment token, a transaction confirmation is received, and the transaction confirmation will be received after the transaction is approved at the customer platform of at least one financial entity.

[0017] For example, the payment token includes consumer identification information including at least one of a random number stored in at least one backend platform and a hash value of information associated with the user.

[0018] For example, when the program instructions of the storage medium are executed, as a result, a payment token will be generated before each payment to be verified.

[0019] For example, when the program instructions of the storage medium are executed, as a result, a secret-public key pair will be generated in the first registration of consumers on the at least one back-end platform.

[0020] For example, when the program instructions of the storage medium are executed, as a result, an existing public-secret key pair will be imported for use in the payment token.

[0021] For example, when the program instructions of the storage medium are executed, as a result, when the geographical location information of the wireless device is similar to the geographical location information of the payment terminal and the transaction to be signed does not exceed a preset tolerance, the transaction verification message will be signed in at least one event of the wireless device that is unlocked.

[0022] For example, when the program instructions of the storage medium are executed, as a result, generating a secret key that is a random number, generating a public key by hashing the secret key, hashing consumer identification information including at least one of consumer contact information, wireless device ID, payment information, geographical location information, and consumer ID number, and constructing the payment token with the hash values of the public key and the consumer identification information.

[0023] Various objects, features, and aspects of the present invention will become even more apparent from the detailed description of the preferred embodiments of this invention, together with the accompanying drawings in which like numerals represent like components. To better understand the subject matter disclosed herein and to illustrate how it can be actually implemented, embodiments will now be described by way of non-limiting example only, with reference to the accompanying drawings.

Brief Description of the Drawings

[0024]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

[0025] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of some embodiments. However, it will be understood by those skilled in the art that some embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components, units, and / or circuits have not been described in detail so as not to obscure the present discussion.

[0026] For example, discussions made in this specification that utilize terms such as "processing", "computing", "calculating", "determining", "establishing", "analyzing", "checking", etc. refer to the operation and / or processing of a computer, computing platform, computing system, or other electronic computing device that operates on and / or transforms data represented as a physical quantity (e.g., electronically) in a computer's registers and / or memory into other data similarly represented as a physical quantity in the computer's registers and / or memory or in other information storage media capable of storing instructions for executing operations and processes.

[0027] As used herein, the terms "plurality" and "a plurality" include, for example, "multiple" or "two or more". For example, "a plurality of items" includes two or more items.

[0028] References to "one embodiment", "an embodiment", "demonstrative embodiment", "various embodiments", etc. indicate that the embodiments so described include certain features, structures, or characteristics, but not that all embodiments necessarily include the specific features, structures, or characteristics. Further, repeated use of the phrase "in one embodiment" can, but need not, refer to the same embodiment.

[0029] As used herein, unless otherwise specified, the use of the sequential adjectives "first", "second", "third", etc. to describe a common thing is only to indicate that different examples of the same thing are being referred to, and is not intended to mean that the things so described must be in a given order, whether in time, space, ranking, or any other way.

[0030] As used herein, the term "circuitry" can refer to or include one or more software or firmware programs, application specific integrated circuits (ASICs), integrated circuits, electronic circuits, processors (shared, dedicated, or grouped) and / or memories (shared, dedicated, or grouped), combinational logic circuits, and / or other suitable hardware components that provide the described functionality. In some exemplary embodiments, the circuitry can be implemented within one or more software or firmware modules, or the functionality associated with the circuitry can be implemented by one or more software or firmware modules. In some exemplary embodiments, the circuitry can include logic that is at least partially operable in hardware.

[0031] The term "logic" can refer to, for example, computing logic embedded in the circuitry of a computing device and / or computing logic stored in the memory of a computing device. For example, the logic can be made accessible by a processor of a computing device that executes the computing logic to perform computing functions and / or operations. In one example, the logic can be incorporated in various types of memory and / or firmware, such as silicon blocks of various chips and / or processors. The logic can be included and / or implemented as part of various circuits, such as radio circuits, receiving circuits, control circuits, transmitting circuits, transceiver circuits, processor circuits, and the like. In one example, the logic can be incorporated in volatile and / or non-volatile memory including random access memory, read-only memory, programmable memory, magnetic memory, flash memory, persistent memory, and the like. The logic can be executed by one or more processors using, for example, memory coupled to the one or more processors as needed to execute the logic, such as registers, stacks, buffers, and the like.

[0032] As used hereinafter, the term "module" is an object file that contains code to extend the execution kernel environment.

[0033] As used herein, the term "software engine" is an object file that contains code to extend the execution kernel environment, as used hereinafter.

[0034] As used hereinafter, the term "digital wallet" refers to both software and information components. A digital wallet can be stored on the client side. A digital wallet can use, for example, near field communication (NFC) of a smartphone to transfer payment amounts by touching the smartphone to a payment terminal at a store.

[0035] As used hereinafter, the term "loyalty club customer" refers to a customer of a business-to-business (B2B) transaction that has the benefits of a loyalty club and manages a loyalty-based mobile service, such as a customer-based loyalty card application.

[0036] As used hereinafter, the term "Back-End Platform" refers to a cloud platform or back-end server of a digital wallet system that is configured to manage and control digital wallet services and is configured to interact with selected third-party systems, digital wallet modules and / or digital wallet engines and / or digital wallet SDKs.

[0037] As used hereinafter, the term "digital wallet SDK" can include a digital wallet module and / or a digital wallet engine. A digital wallet SDK is the front end of a digital wallet software program that belongs to and is integrated within a customer mobile application. A digital wallet SDK can manage front-end payment interactions of end users through the customer's mobile application. A digital wallet SDK can use the NFC protocol to communicate with a POS terminal of a vendor POS in place of a digital wallet platform.

[0038] As used hereinafter, the term "customer relationship manager (CRM) application programming interface (API)" refers to an API configured to communicate with a CRM. The CRM is configured to manage one or more customer loyalty programs.

[0039] As used hereinafter, the term "Payment terminal" can include, for example, a specific merchant and / or vendor and / or store and / or other credit card terminal where various payment transactions can be made when, for example, an end user decides to execute a payment transaction using their consumer mobile application.

[0040] As used hereinafter, "Customer Platform" can include, for example, the customer technology platform of a partner configured to interact with a digital wallet for payment preparation through a digital wallet platform. The backend technology platform communicates with the customer mobile application, similar to the digital wallet SDK, depending on the payment settings selected by the customer and / or partner. For example, this platform will be cloud-based operating, for example, on Amazon Web Services (AWS) and / or Microsoft AZURE.

[0041] As used below, a "cryptowallet module" can refer to an application or SDK configured to generate and store random public-private key pairs at the address of each cryptowallet generated from a public key. The cryptowallet module can further be configured to interact with at least one blockchain network, such as the Ethereum blockchain or other similar blockchain networks like Bitcoin, Solana, Cardano, Polkadot, Avalanche, etc.

[0042] The term "hash value" refers to the output of a mathematical function that takes an input of arbitrary length, converts it to a fixed length, and results in the same hash value whenever the hash function is applied to the same input, although even the slightest difference in the input results in a completely different hash value of the output. Hash values are used to validate the content of a message. When the content is changed, the hash value of the new message will be different from the original message.

[0043] As used below, the term "Payment token" can include a unique placeholder, called a payment token, configured to include information that uniquely identifies a user, encrypted with a known public-private algorithm, such as the Rivest-Shamir-Adleman - "RSA" algorithm.

[0044] In some embodiments, the payment token can be composed of a public key representing an address on a blockchain network owned by the user and other identifying information such as, for example, name, contact information, mobile device metadata, time, geographical location information data, etc.

[0045] For example, if the user's uniquely identifiable information is parsed in a simple JSON format that includes the following.

[0046] {"address": "0xb794f5ea0ba39494ce839613fffba74279579268", "name" = "John Smith"}, the settlement token can then contain the following encrypted string.

[0047] NjXlHoGdktQHFF5hJOPsy+SJmOhCTEgcYFVvpJCwuoR6TDQjmTMJI6G+ ZlCf2mWYswjCz / 6pSW / 90EQmzp6Xiv4x8maycBsVwNIPa2t4dcWAGK0D9n5mkU aA2tz+pk1FrOYq4ttrLZc7pNzCaDpcNyOa8ZEnwAA7TSqNfsvqXfw=.

[0048] In another implementation example, only the identifiable information is encrypted, while the public address remains as is and is parsed in the JSON file. Where the identification string is "name: John = Smith", the JSON file reads as follows.

[0049] {"address": "0xb794f5ea0ba39494ce839613fffba74279579268", "idlnfo": "XFftAh5RGXtlzJ622+vrg2nUBozV97KdyHRL300xBIGdiCRzf4h+bsxbYGFqCxHzLp4HidpJAc3PvzjPwE1AuQ=="}

[0050] The above is merely an example to clarify the terminology used in this specification. In practice, additional parameters can be included in the settlement token, which also includes a disposable random number accumulated in the backend platform's database to ensure that a part of the hashed settlement token remains unique for each use.

[0051] As used hereinafter, the term "mobile application" can include at least one application installed on a customer's wireless device, such as a loyalty club application, an e-wallet application, etc. The customer application can include a digital wallet SDK and can interact with a digital wallet platform and a customer platform. The customer mobile application can be configured to operate on a wireless device operating system such as, for example, iOS and / or Android (registered trademark).

[0052] Some exemplary embodiments can be built on web3 ecosystem concepts and blockchain technology. For example, web3 ecosystem concepts and blockchain technology establish a secure and transparent decentralized payment system. The use of blockchain enables consumers and enterprises to directly exchange cryptocurrencies such as, for example, Bitcoin and Ethereum, via a cryptocurrency wallet without an intermediary. The payment is verified, registered anonymously on a distributed ledger, in which, for example, a copy thereof can be stored on the cryptocurrency wallet.

[0053] For example, while it is a basic premise that a public key is made available for use as a unique wallet identifier and only the owner of the cryptocurrency wallet can access the private key, the verification of the cryptocurrency wallet and the ownership of its funds can be achieved by using the private key - public key.

[0054] More than a decade after the first implementation of the Bitcoin blockchain, the technology has struggled to gain adoption as a consumer payment method and remains mostly a speculative investment channel.

[0055] There are many reasons why blockchain technology and cryptocurrencies have not yet achieved the goal of becoming a viable alternative to traditional centralized payment means and fiat currency.

[0056] Some of these reasons are related to, for example, the inefficiency of the inherent energy in blockchain design. Other reasons are related to the nature of the anonymity of transactions that present a platform for money laundering activities, and still other reasons are related to the high transaction fees given to transaction verification machines.

[0057] Embodiments of the present disclosure can relate to systems, apparatuses, and methods for verifying payment validity that avoid the use of complex standards for handling the transmission of credit card information subject to confidentiality. For example, using encrypted public-private key authentication in a combination of terminals of a point-of-sale information management system configured to process public keys instead of transmitting or using a credit card subject to confidentiality to validate ownership and payment would lead to savings and a simpler system since the use of complex standards for handling the transmission of credit card information (e.g., EMV) subject to confidentiality is currently avoided.

[0058] Other embodiments can relate to systems, apparatuses, and methods that enable verification of ownership of a published unique consumer identifier. For example, due to the nature of public-private cryptography, there is no reason to transmit confidential information such as credit card numbers, expiration dates, CVC numbers, and a four-digit PIN number to prove ownership. Instead, the public key can be transmitted along with additional information, and the present disclosure introduces apparatuses, systems, and methods that enable a consumer to prove ownership of the transmitted public key.

[0059] However, some embodiments can also be configured to enable cryptocurrency wallet-based payment verification without the transaction fees associated with blockchain. Blockchain-based payments can be considered secure, but for the purpose of payment verification, it can be considered inefficient that each payment has to be recorded in a public distributed ledger. As a blockchain network client in the use of the present disclosure, a large number of the public who already have access rights to a cryptocurrency wallet can use the wallet to purchase goods and services with their cryptocurrency wallet without the transaction fees associated with encrypted transactions and without concerns about privacy, since their purchases are not made public in the distributed public ledger.

[0060] Advantageously, the device and system settings allow for authenticating ownership of a payment account in the authentication of multiple factors therein, while only requiring one action from the user.

[0061] For example, when the user brings a Near Field Communication (NFC) chip of a smartphone close to a payment terminal at checkout, the user only performs one action. An application including a Software Development Kit (SDK) will send a payment token to the payment terminal with the public key representing the user, and the checkout information will be relayed from the payment terminal to the server. After cross-referencing the received payment token and the public key in the user database and associating the user with it, the server can relay the transaction information to the smartphone pre-associated with the user.

[0062] When a pre-set condition (e.g., if the smartphone screen is unlocked and the geographical location information of the smartphone is similar to that of the payment terminal) is realized, the SDK uses the private key corresponding to the public key to sign the pre-received transaction message and returns the signed transaction message to the original server. At that time, the server can decrypt the received and signed message and compare multiple parameters of the signed message with the database entry. The multiple parameters include at least one of the public key obtained from the signed message and the payment token, the pre-received public key, the content of the signed message and transaction information received from the payment terminal, the user information of the payment token received from the payment terminal, and the user information collected in the first registration.

[0063] As can be seen, although the user was required to perform only one action, the public-private authentication feature was utilized from two different perspectives, and the user's identity and transactions were verified by multi-factor authentication. The first perspective is when comparing the public key of the payment token with the public key provided during registration. The second perspective is when comparing the public key of the payment token with the message signed by the corresponding private key.

[0064] Referring first to FIG. 1, which depicts an exemplary embodiment of the present invention, a system 10 for verifying payment validity is shown. The system 10 can include at least one consumer wireless device 100, a backend platform 110, at least one payment terminal 120, and a customer platform 131 of a financial entity 130.

[0065] In some exemplary embodiments, the wireless device 100 can include a processor 101, an NFC communication suite 102, an Internet modem 103, a cryptocurrency wallet application 104, a digital wallet SDK 105, and a payment token storage module 106. The processor 101 can be configured to operate at least one mobile application 107 that can include the digital wallet SDK 105 and the cryptocurrency wallet module 104. The mobile application 107 can be configured to interact with a blockchain network such as, for example, the Ethereum blockchain.

[0066] In some exemplary embodiments, the cryptocurrency wallet 104 can include at least one public-private key pair 108, and the payment token storage module 106 can include at least one payment token 109.

[0067] In some exemplary embodiments, the Internet modem 103 can use a shared wireless communication protocol such as, for example, 60Ghz, 5G, 6G, WiFi, any one of the cellular communication protocols, any one of the IEEE811 protocols, etc.

[0068] In some exemplary embodiments, the payment terminal 120 of the merchant's POS can include, for example, a processing circuit 121, an NFC communication suite 122, an Internet modem 123, a transaction generator module 124 for generating at least one payment request message, and a payment token transceiver module 125.

[0069] For example, the processing circuit 121 can be configured to operate an application that includes the transaction generator module 124 and the payment token transceiver module 125.

[0070] The payment terminal 120 can exist within digital communication with the backend platform 110 and the consumer wireless device 100.

[0071] For example, the backend platform 110 can exist within digital communication with one or more payment terminals 120, consumer wireless devices 100, and the customer platforms 131 of various financial entities 130. The backend platform 110 can include a processing circuit (not shown) configured to execute the functions of a transaction database 111, a message generation module 112, a consumer database 116, a payment token decryption module 113, a message signature decryption module 114, and a transaction verification module 115.

[0072] Referring to FIG. 2, a representative implementation of some embodiments will be understood from the following method. While this method can be implemented in other embodiments of the present invention, for clarity, structural components are referred to by their collation in FIG. 1.

[0073] To verify payment validity, the method can include providing a public-private key pair 108 (text box 201), for example, by using a mobile application 107 installed on the consumer wireless device 100.

[0074] In some exemplary embodiments, when the user signs into the mobile application, a command can be passed to the cryptocurrency wallet module 104 and configured to generate a public-private key pair 108 (FIG. 1) that can include a public key and a private key. In some embodiments, the public key of the public-private key pair 108 (FIG. 1) can be used to create a cryptocurrency wallet address in a process compliant with at least one blockchain network.

[0075] In some other exemplary embodiments, the public-private key pair 108 (FIG. 1) can be generated before verifying each payment. In yet other embodiments, the public-private key pair 108 can be generated during the user's first registration to the mobile application 107. In other embodiments, the user can import an existing public-private key pair into the cryptocurrency wallet module 104 (FIG. 1).

[0076] In some exemplary embodiments, the method can proceed to generate a payment token 109 for payment validity verification by a mobile application 107 (FIG. 1) that can be installed on the consumer wireless device 100 (FIG. 1) (text box 202). In some embodiments, the public key and / or cryptocurrency wallet address and / or any other user identification information can be passed to the payment terminal 120 (FIG. 1) to generate the payment token.

[0077] In some exemplary embodiments, the payment token 109 (FIG. 1) includes the public key and the user ID associated with the consumer wireless device.

[0078] In other exemplary embodiments, the payment token 109 (FIG. 1) can be generated by the digital wallet SDK 105 (FIG. 1) and can be stored in the payment token storage database 106 (FIG. 1).

[0079] In some embodiments, the digital wallet SDK 105 (FIG. 1) can obtain the public key of the public-private key pair 108 (FIG. 1) from the crypto wallet module 104 (FIG. 1), and then can generate a payment token 109 (FIG. 1) thereby. In this embodiment, the private key of the public-private key pair 108 (FIG. 1) can remain securely stored in a database on the consumer wireless device 100 (FIG. 1), and the public key of the public-private key pair 108 (FIG. 1) can also be later transferred and stored in the consumer database 116 (FIG. 1) on the backend platform 110 (FIG. 1) and on the payment terminal 120 (FIG. 1).

[0080] In some exemplary embodiments, the method can continue by providing the payment token 109 (FIG. 1) of the consumer wireless device 100 (FIG. 1) to the payment terminal 120 (FIG. 1) (text box 203). In some embodiments, the payment token can be transmitted from the consumer wireless device 100 (FIG. 1) to the payment terminal 120 (FIG. 1) via at least one of the NFC radio 102 (FIG. 1) and / or the Internet modem 103 (FIG. 1) (e.g., LTE, GSM, WiFi, Bluetooth radio).

[0081] In some exemplary embodiments, the method can continue by providing transaction information (text box 204). For example, the processing circuit 121 (FIG. 1) of the payment terminal 120 (FIG. 1) can be configured to generate a payment request 126 (FIG. 1) including a transaction information message such as, for example, a payment due date, a product list, and / or a merchant ID and the payment token 109 (FIG. 1). The payment request 126 can be transmitted to the backend platform 110 (FIG. 1) provided by the consumer wireless device 100 via the Internet modem 123 (FIG. 1).

[0082] The following is an example. That is, when scanning products, their prices and other information are acquired by the payment terminal 120 (FIG. 1). After the consumer associates and / or brings their wireless device 100 (FIG. 1) closer to the payment terminal 120 (FIG. 1) and provides their payment token 109 (FIG. 1) to the payment terminal 120 (FIG. 1) via NFC communication, the information related to the payment request can be displayed on the payment terminal 120 (FIG. 1). The payment terminal 120 (FIG. 1) can aggregate and provide a payment request 126 (FIG. 1) including a transaction information message. For example, the transaction information can include a payment due date and a merchant ID. In some embodiments, the payment terminal 120 (FIG. 1) can also be configured to send the transaction information message and / or its hash value to the consumer wireless device 100 (FIG. 1) for validity before signing the message.

[0083] In some exemplary embodiments, the method can continue by interpreting and storing the transaction information message of the payment token 109 (FIG. 1) data and the payment request message (text box 205). For example, the interpretation can be performed by a payment token decoding module 113 (FIG. 1), and the storing can be performed in a transaction database on the backend platform 110 (FIG. 1).

[0084] In some exemplary embodiments, where the payment token 109 (FIG. 1) can be encrypted with a public key associated with a service provider, the payment token 109 (FIG. 1) can be decrypted with the corresponding private key obtained by the payment token decoding module 113 (FIG. 1).

[0085] In some exemplary embodiments, the method can continue by approving a transaction with a financial entity 130 (FIG. 1) (text box 206). For example, the transaction information and the consumer's identity can be digitally transferred to the customer platform 131 (FIG. 1) of the financial entity 130 (FIG. 1). In some exemplary embodiments, the consumer holds a credit card issued by the financial entity 130, has a bank account, and / or is a member of a consumer loyalty program managed by the financial entity 130 (FIG. 1).

[0086] For example, after verifying whether the transaction conforms to pre-defined rules, such as whether the consumer has sufficient credit or assets to cover the transaction, the financial entity 130 (FIG. 1) can confirm the transaction by returning a pre-determined code message.

[0087] In some exemplary embodiments, the transaction information message can be compared against various rules, such as whether the purchased product can be listed on a list of eligible products and / or whether the merchant can be listed on a specific list of eligible businesses.

[0088] In some exemplary embodiments, the method can continue by generating a transaction verification message by the back-end platform 110 (FIG. 1) and providing it to the consumer associated with the corresponding settlement token 109 (FIG. 1) (text box 207).

[0089] For example, the transaction verification message can include information related to the settlement that can include the merchant ID and the payment due date. The transaction verification message can be generated by the message generation module 112 (FIG. 1) and can be sent to an address associated with the consumer, such as a mobile application 107 (FIG. 1) that can be installed on the consumer's wireless device 100 (FIG. 1), a phone number, and / or an email address.

[0090] In some exemplary embodiments, the method may proceed by signing the transaction verification message and sending it to the backend platform 110 (FIG. 1) for decryption (text box 208). For example, before signing the message, the details of the transaction can be presented to the consumer using the user interface of the mobile application 107 (FIG. 1) for the consumer's confirmation (e.g., pressing a confirmation button).

[0091] In another example, the digital wallet SDK can proceed by signing the message upon fulfillment of at least one condition or rule. For example, the rule can be a rule for the hash value of a second message that is identical to the hash value of a first message previously received from the payment terminal regarding this transaction, a rule when the consumer wireless device is unlocked, a rule whether the geographical location information of the wireless device is within a predetermined range of the known geographical location information of the payment terminal, and a rule whether the transaction to be signed exceeds a regular allowance set by the consumer or on their behalf, etc.

[0092] In some embodiments, the predetermined range of the known geographical location information is between 0 and 5 meters from the center of the known geographical location information.

[0093] In some exemplary embodiments, the transaction verification message can be signed with the private key of a public-private key pair and sent back to the backend platform 110 (FIG. 1).

[0094] In some exemplary embodiments, the message decryption module 114 (FIG. 1) can decrypt the transaction verification message signed with the public key associated with the consumer.

[0095] In other embodiments, the message decoding module 114 (FIG. 1) can apply an appropriate algorithm to derive the public key corresponding to the private key that can be used to sign the message without revealing all of the content of the signed transaction verification message and the same private key. The process of decrypting the message signed by the private key can, for example, comply with the EIP712 Ethereum standard. Of course, other appropriate algorithms can be contemplated to achieve similar results.

[0096] In some exemplary embodiments, the method can proceed by verifying the identity of the signer of the transaction verification message and the validity of the transaction (text box 209). For example, the transaction verification module 115 (FIG. 1) can compare the decrypted verification message with the transaction information message previously received from the settlement terminal. Since the received signed message is signed using the consumer's private key and can be decrypted with the consumer's public key from the transaction database 111 (FIG. 1), if a match is found, then the identity of the person who signed the message with the transaction information is verified.

[0097] In another example, the transaction verification module 115 (FIG. 1) can compare the public key parameters and the verification message from the decrypted signed message with the same ones from the transaction database 111 (FIG. 1).

[0098] In some exemplary embodiments, the method can proceed by notifying the transaction result (text box 210). For example, the backend platform 110 (FIG. 1) can notify the consumer, the trading partner, and the financial entity 130 (FIG. 1) of the result of the settlement validity verification by sending a transaction confirmation message, thus enabling the exchange of goods, services, and money or preventing unverified transactions.

[0099] It should be understood that the order of implementation of the methods described above is not important since the methods can be executed in different orders or simultaneously.

[0100] Referring to FIG. 3, FIG. 3 is an example of a flowchart of a method for generating a payment token, as in some exemplary embodiments. In some exemplary embodiments, this method can be executed by a digital wallet SDK 105 (FIG. 1) included in a mobile application 107 (FIG. 1) installed on a consumer wireless device 100 (FIG. 1). In some other embodiments, the following method can be executed by a payment terminal 120 (FIG. 1).

[0101] In some embodiments, the cryptocurrency wallet module 104 of the consumer wireless device 100 can generate and store a random public-private key pair 108.

[0102] In some exemplary embodiments, the method can begin by generating a secret key by generating a random number that can be appropriate as an input to the algorithm used to generate the public key (text box 301).

[0103] In some exemplary embodiments, the method can continue by generating a public key based on the secret key by hashing the secret key with an algorithm such as, for example, the elliptic curve digital signature algorithm (text box 302).

[0104] In some exemplary embodiments, the method can continue by generating a wallet address for the public key by formatting the public key in a predetermined format used to identify a set of characters as a cryptocurrency wallet address (text box 303). For example, extract the last 20 bytes of the public key and add "Ox" at the beginning.

[0105] In some exemplary embodiments, the method can proceed by obtaining and hashing unique consumer identification information (text box 304). In some embodiments, the identification information can include at least one of consumer contact information (e.g., name, phone number, email), wireless device ID (e.g., IMEI number), payment information (e.g., bank account, credit card), geographical location information, and consumer ID number.

[0106] In some exemplary embodiments, the backend platform 110 (FIG. 1) can generate a unique random number, store the unique random number in the user database, and securely transmit it to be included as a nonce when a payment token is constructed. This feature prevents the generation of the same payment token if the identification information has not changed.

[0107] The method can proceed by constructing a payment token that includes a public key and a hash value of unique user information (text box 305). In some embodiments, the public key or cryptocurrency wallet address can be structured with the hash value of the consumer identification information in a common suitable data structure, such as a more readable JSON file of the backend platform 110, for example.

[0108] Referring to FIG. 4, FIG. 4 is an example of a flowchart of a method for initial user registration of a service, as in some exemplary embodiments. In some exemplary embodiments, this method can be executed by a digital wallet SDK 105 (FIG. 1) included within a mobile application 107 (FIG. 1) installed on a consumer wireless device 100 (FIG. 1).

[0109] In some exemplary embodiments, the method can start by generating and storing a random public-private key pair 108 (FIG. 1) in the digital wallet SDK 105 (FIG. 1), and continue by receiving input from the user's personal information (text box 401). For example, the personal information can include at least one of a name, a phone number, an address, an email address, a birthday, and / or a face photo.

[0110] In some exemplary embodiments, the method can continue by extracting the unique identifier and metadata of the wireless device (text box 403). This information can include at least one of the IMEI number, device model, operating system version, and SDK version of the wireless device on which the digital wallet SDK is executed.

[0111] In some exemplary embodiments, the method can continue by receiving input of payment information (text box 404). This information can include at least one of credit card information, bank account number, and loyalty program information.

[0112] In some embodiments, the payment information can be received via an interface to an application of a financial entity installed on the wireless device, such as a bank mobile application, a loyalty program mobile application, etc.

[0113] In some embodiments, the payment information can be received via an interface to a browser installed on the wireless device when recorded on the website of the financial entity.

[0114] In any way, request and receive a nonce from the backend platform (text box 405).

[0115] For example, encrypt information including personal information, device information, payment information, and nonce with the public key of the backend platform 110 (text box 406).

[0116] In some exemplary embodiments, the method may continue by sending the information encrypted with the public key to the backend platform 110 (FIG. 1) and the public key generated by the digital wallet SDK 105 (FIG. 1), decrypting the information encrypted with the requested private key, and storing all the information in the consumer database 116 (FIG. 1) within the backend platform 110 (FIG. 1) (text box 407).

[0117] In some embodiments, the method further includes authorizing the user for credit with a financial entity 130 (FIG. 1) associated with the payment information. For example, if bank account information is entered, the backend platform 110 (FIG. 1) can query the associated customer platform 131 (FIG. 1) of the bank to confirm that the bank can cover the transaction requested by the user and under what rules (e.g., only accept domestic transactions).

[0118] In some exemplary embodiments, the method can include generating a user ID for an approved and / or registered user, encrypting it with the public key of the public-private key pair 108 (FIG. 1) provided by the user, sending the encrypted user ID to the user's wireless device 100 (FIG. 1) for decryption with the appropriate private key of the public-private key pair 108 (FIG. 1), and storing the public key in the payment token storage 106 (FIG. 1) for use as a payment token 109 (FIG. 1) in future transactions.

[0119] In some embodiments, the user ID can include at least one of a random number, a unique serial number, and a hash value of user information arranged in a specific order.

[0120] Referring now to FIG. 5, FIG. 5 is an example of an overview of a manufactured product 500 as in some exemplary embodiments. The product 500 can include one or more tangible computer-readable non-transitory storage media 510 that are implemented by a processing device 520 and are operable and can include computer-executable instructions 530, and when executed by at least one computer processor, can enable at least one processing circuit 121 (FIG. 1) to implement one or more program instructions for verifying payment validity, and / or can execute, derive, and / or implement one or more operations, communications, and / or functionality as described above with reference to FIGS. 1-4. The phrase "non-transitory machine-readable medium" is meant to include all computer-readable media with the sole exception being a transitory propagated signal.

[0121] In some exemplary embodiments, product 500 and / or machine-readable storage medium 510 can include one or more types of computer-readable storage media capable of storing data, including, for example, memory, non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or non-rewritable memory, and the like. For example, machine-readable storage medium 510 can include any type of memory such as, for example, RAM, DRAM, ROM, programmable ROM (PROM), erasable and programmable ROM (EPROM), electronically erasable and programmable ROM (EEPROM), flash memory, hard disk drive (HDD), solid state drive (SDD), fuse drive, and the like. A computer-readable storage medium can include any suitable medium related to downloading and transferring a computer program from a remote computer carried by a carrier wave or other propagation medium in an integrated data signal via a communication link, such as, for example, a modem, radio, or network connection, to a computer that requests it.

[0122] In some exemplary embodiments, processing device 520 can include logic. The logic can include instructions, data, and / or code that, if executed by a machine, can cause the machine to execute the methods, processes, and / or operations described herein. The machine can include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and can be implemented using any suitable combination of hardware, software, firmware, and the like.

[0123] In some exemplary embodiments, the processing device 520 can include software, firmware, software modules, applications, programs, subroutines, instructions, instruction sets, computing code, words, values, symbols, etc., and can be implemented as such. The instructions 540 can include any suitable type of code such as source code, compiled code, interpreter code, executable code, static code, dynamic code, etc. The instructions can be implemented by a pre-defined computer language, method, or syntax for instructing a processor to perform a specific function. The instructions can be implemented using any suitable high-level, low-level, object-oriented, visual, compiled, and / or interpreted programming language such as C, C++, C#, Java, Python, BASIC, Matlab, assembly language, machine code, etc.

[0124] Referring to FIG. 6, FIG. 6 depicts an exemplary embodiment of the present invention. The typical process described herein can first begin at a registration stage 600 that can include an SDK 601 that collects consumer information 600 such as a public-private key pair from a crypto wallet, payment means such as credit card information, and an SDK-ID that can be a unique identifier and transmits it to a server platform 606.

[0125] When the consumer approaches the POS 603 to purchase the scanned product 604, as a result, the consumer can display a device equipped with the SDK 601 that can send the public key in the payment token to the payment terminal of the POS 603.

[0126] This process can continue by the POS sending a payment request that can include the public key and a transaction information message (e.g., total payment amount) 605 to the server platform 606.

[0127] This process can continue by the server platform 606 sending a transaction verification message 607 that can include the SDK 601 identified by a settlement token or public key and such details as may have been previously provided by a transaction information message.

[0128] This process can continue by the SDK 601 signing the transaction verification message after consumer approval and transmitting it 608 to the server platform 606.

[0129] This process can continue by the server platform 606 validating the settlement based on a comparison of information between the transaction verification message signed by the SDK 601 and the transaction information message provided by the POS 603.

[0130] This process can continue by the server platform 606 notifying the POS 609 of approval or rejection of the settlement. The subject matter described above is provided by way of example only and should not be construed as limiting. Also, as will be apparent in the following claims, various modifications and changes can be made to the subject matter described herein without departing from the true spirit and scope of the invention, without following the illustrated and described exemplary embodiments and applications.

Claims

1. A method for verifying the validity of a payment executed by a wireless device, comprising: generating a public-private key pair by a cryptocurrency wallet; generating a payment token including the public key of the public-private key pair; transmitting the payment token to a payment terminal configured to generate a payment request including a payment transaction information message and the payment token in a point-of-sale information management system and then transmit the payment request to at least one backend platform; generating a transaction verification message by the at least one backend platform based on the transaction information message; providing the transaction verification message to a device associated with the public key of the payment token; signing the transaction verification message with the private key of the public-private key pair and sending the signed transaction verification message to the at least one backend platform; verifying the ownership of the first public key by comparing, by the at least one backend platform, the public key of the transaction verification message signed by the wireless device with the public key included in the payment request message generated by the payment terminal; approving the payment on a customer platform of at least one financial entity; notifying any one of the payment terminal, the wireless device, and the customer platform of the payment verification result by the at least one backend platform by sending a transaction confirmation message from the at least one backend platform.

2. The method according to claim 1, wherein the consumer identification information of the payment token is at least one of a random number stored in the at least one backend platform, a hash value of information associated with the consumer, and a unique serial number.

3. The method according to claim 1, wherein the transaction information message includes at least one of a payment due date, a product list, and a franchise store ID. The method according to claim 1.

4. The generating of the payment token comprises: generating the private key which is a random number; generating the public key by hashing the private key. Hashing consumer identification information including at least one of consumer contact information, wireless device ID, payment information, geographical location information, and consumer ID number, Constructing the payment token with the public key and the hash value of the consumer identification information, The method according to claim 1, comprising:

5. A payment terminal including one or more physical computer-readable non-transitory storage media containing program instructions for verifying payment validity, By executing the program instructions by one or more processors, the payment terminal is caused to Receive a payment token issued by a software development kit (SDK) disposed on a wireless device and including a public key of a set of public-private keys created by a cryptocurrency wallet, Generate a payment request including a transaction information message and the payment token, and transmit the payment request to at least one backend platform, Receive a payment and transaction confirmation message from the at least one backend platform based on a payment approval generated by the at least one backend platform, Verifying the ownership of the public key based on a comparison between the public key of a transaction verification message signed by the private key of the public-private key pair in the wireless device and the public key included in the payment request generated by the payment terminal, which is executed by at least one backend platform, Payment terminal.

6. By executing the program instructions by one or more processors, receiving the payment token via at least one of radio frequency identification (RFID) communication, short-range wireless communication, and near-field communication (NFC), The payment terminal according to claim 5.

7. The payment token comprises consumer identification information including at least one of a random number stored in a backend platform, a hash value of information associated with a user, and a unique serial number, The payment terminal according to claim 5.

8. The transaction information message includes at least one of a payment due date, a product list, and a franchise ID, The payment terminal according to claim 5.

9. A wireless device including one or more physical computer-readable non-transitory storage media having application program instructions for verifying payment validity, wherein execution of the program instructions by one or more processors results in generating a public-private key pair by a cryptocurrency wallet, generating a payment token including the public key of the public-private key pair, transmitting the payment token to a payment terminal of a point-of-sale information management system, receiving a transaction information message from the payment terminal, receiving a transaction verification message from at least one backend platform, based on a comparison between the transaction information message received from the payment terminal and the transaction verification message generated by at least one backend platform, signing the transaction verification message with the private key of the public-private key pair, sending the signed transaction verification message to the at least one backend platform, and after the at least one backend platform verifies the ownership of the public key based on a comparison between the public key of the signed transaction verification message and the payment token, receiving a transaction confirmation. A wireless device.

10. The payment token includes consumer identification information composed of at least one of a random number stored in at least one backend platform and a hash value of information associated with the consumer. The wireless device according to claim 9.

11. When executed by one or more processors according to the program instructions of the storage medium, as a result, the payment token is generated before each payment to be verified. The wireless device according to claim 9.

12. When executed by one or more processors according to the program instructions of the storage medium, as a result, the public-private key pair is generated in a first registration of the consumer on the at least one backend platform. The wireless device according to claim 9.

13. When executed by one or more processors according to the program instructions of the storage medium, as a result, an existing public-private key pair will be imported for use in the settlement token. The wireless device according to claim 9.

14. When executed by one or more processors according to the program instructions of the storage medium, whether or not a transaction to be signed attempts to exceed a preset allowable amount, when the geographical location information of the wireless device is within a predetermined range of the known geographical location information of the settlement terminal, as a result, the transaction verification message will be signed in at least one of the events for unlocking the wireless device. The wireless device according to claim 9.

15. The predetermined range of the known geographical location information is between zero and five meters from the center of the known geographical location information. The wireless device according to claim 14.

16. When executed by one or more processors, as a result of the program instructions of the storage medium, generating the private key which is a random number; generating the public key by hashing the private key; hashing the consumer identification information; resulting in constructing the settlement token with the hash value of the public key and the consumer identification information. The wireless device according to claim 9.

17. The consumer identification information includes at least one of consumer contact information, wireless device ID, payment information, geographical location information, and consumer ID number. The wireless device according to claim 10.

Images