Method and system for facilitating detrusted payment transactions using smart contracts

Abstract

A method for handling a detrusted blockchain transfer via a card payment network, comprising: storing a smart contract in a blockchain associated with a blockchain network, the smart contract configured to control an amount of blockchain currency in the blockchain; receiving, by a blockchain node in the blockchain network, an authorization request message from the first computing system, wherein the blockchain node submits the authorization request message as an input to the smart contract; receiving, by the blockchain node, an authorization response message from the second computing system, wherein the blockchain node submits the authorization response message as an input to the smart contract; and executing, by the blockchain node, the smart contract in the blockchain such that the smart contract (i) verifies the authorization request message and the authorization response message, and (ii) transfers at least a portion of the amount of blockchain currency to a predetermined blockchain address.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 451,394, filed on March 10, 2023, which is incorporated herein by reference in its entirety for all purposes. Technical Field

[0003] The present disclosure relates to processing trustless payment transactions through the use of card networks and blockchain, and more specifically, to providing trustless blockchain transfers from consumers using blockchain smart contracts while enabling merchants to receive fiat or other currencies. Background Art

[0004] Blockchain transactions were initially developed as an alternative to fiat currency for tech-savvy individuals, using a distributed and decentralized network to track transactions. Blockchain currencies (also known as cryptocurrencies) initially had relatively small values, but their value has exploded due to widespread adoption, investment, and trading. Users generally have two options for using blockchain currencies: self-custodial wallets (where users control their blockchain wallet's private keys and execute transactions themselves) or custodial wallets (where a third party controls the user's private keys and handles transactions on their behalf). In both cases, transactions are conducted between two blockchain wallets, exchanging blockchain currencies. Some blockchain networks offer the ability to convert currencies, or utilize exchanges, where one party transfers a first currency and another receives a second. However, these processes can be difficult for the average consumer to navigate and are often subject to widely fluctuating exchange rates and fees.

[0005] Consumers are familiar and comfortable using payment cards for payment transactions. However, there is a lack of systems that enable consumers to use blockchain currencies in payment card transactions. Furthermore, many merchants remain cautious or uninterested in accepting blockchain currencies as payment. Therefore, consumers who wish to use blockchain currencies in payment transactions with merchants must overcome the technical difficulties of using blockchain wallets and only transact with merchants who are willing to accept the same blockchain currencies as payment.

[0006] Therefore, there is a need for a technological solution to facilitate payment transactions on card networks that provides convenience and familiarity to consumers while still enabling merchants to receive fiat currency for transactions. Summary of the Invention

[0007] The present disclosure provides a description of systems and methods for processing trustless blockchain transfers via a card payment network. A consumer registers with a card issuer, the card issuer provides a payment card linked to a smart contract added to a blockchain for a blockchain currency that the consumer wishes to use for transactions, where the smart contract is funded via the consumer's blockchain wallet. The consumer can present the payment card to a merchant for a payment transaction, where the merchant reads payment details therefrom and initiates processing of the transaction using traditional methods. During processing, the payment transaction is routed to a processor, which identifies the use of the payment card linked to the blockchain. The processor provides an authorization request for the transaction to the smart contract as well as the card issuer. The card issuer approves the transaction (e.g., if the funds cover an equivalent amount of the blockchain currency) and sends an authorization response message to the smart contract. The smart contract verifies that the authorization request matches the response and that the transaction has been approved, and then executes a transfer of the appropriate amount of the blockchain currency to the card issuer on the blockchain. The card issuer, having received a payment in the blockchain currency from the consumer, uses traditional processing to pay the merchant the amount in fiat currency (or other currency, e.g., as requested by the merchant). The result is that the consumer can use the payment card and make payments via the blockchain currency without regard for whether the merchant accepts the blockchain currency, and the merchant receives a fiat payment for the card transaction without any changes to existing processing. Moreover, since the funds are controlled by the smart contract and can only be transferred for a legitimate and authorized transaction initiated by the consumer via the payment card, the transaction is trustless to the consumer.

[0008] A method for processing trustless blockchain transfers via a card payment network includes storing, in a blockchain associated with a blockchain network, a smart contract configured to control an amount of a blockchain currency in the blockchain; receiving, by a receiver of one of a plurality of blockchain nodes in the blockchain network, an authorization request message from a first computing system, wherein the one of the plurality of blockchain nodes submits the authorization request message as input to the smart contract; receiving, by the receiver of the one of the plurality of blockchain nodes, an authorization response message from a second computing system, wherein the one of the plurality of blockchain nodes submits the authorization response message as input to the smart contract; and executing, by the one of the plurality of blockchain nodes, the smart contract in the blockchain, wherein execution of the smart contract causes the smart contract to (i) verify both the authorization request message and the authorization response message, and (ii) transfer at least a portion of the amount of the blockchain currency to a predetermined blockchain address.

[0009] A system for processing trustless blockchain transfers via a card payment network includes a blockchain network associated with a blockchain, the blockchain network including a plurality of blockchain nodes, and the blockchain storing a smart contract configured to control an amount of a blockchain currency in the blockchain; a first computing system; and a second computing system, wherein one of the plurality of blockchain nodes receives an authorization request message from the first computing system, wherein the one of the plurality of blockchain nodes submits the authorization request message as input to the smart contract, wherein the one of the plurality of blockchain nodes receives an authorization response message from the second computing system, wherein the one of the plurality of blockchain nodes submits the authorization response message as input to the smart contract, and wherein the one of the plurality of blockchain nodes executes the smart contract in the blockchain, wherein execution of the smart contract causes the smart contract to (i) verify the authorization request message and the authorization response message, and (ii) transfer at least a portion of the amount of the blockchain currency to a predetermined blockchain address. BRIEF DESCRIPTION OF DRAWINGS

[0010] The scope of the disclosure can best be understood from the following detailed description of exemplary embodiments when read in conjunction with the accompanying drawings. Included in the drawings are the following figures:

[0011] Figure 1 is a block diagram illustrating a high-level system architecture for processing trustless payment transactions via a card network and a blockchain network, according to an exemplary embodiment.

[0012] Figure 2 is a block diagram illustrating a high-level system architecture for processing trustless payment transactions via a card network and a blockchain network, according to an exemplary embodiment. Figure 1 is a block diagram of a computing system for processing trustless payment transactions via a card network and a blockchain network in the system of

[0013] Figure 3A and Figure 3B is a flow diagram illustrating processing of a trustless payment transaction via a card network and a blockchain network in the system of Figure 1

[0014] Figure 4 is a flow diagram illustrating an exemplary method for processing trustless payment transactions via a card network and a blockchain network, according to an exemplary embodiment.

[0015] Figure 5 is a block diagram illustrating a computer system architecture, according to an exemplary embodiment.

[0016] ​Other applications of the disclosure will become apparent to one skilled in the art after consideration of the following detailed description. It is understood that the specific embodiments are only examples and are not intended to necessarily limit the scope of the disclosure. DETAILED DESCRIPTION

[0017] System for processing trustless payment transactions

[0018] Figure 1 A system 100 for processing trustless payment transactions via the use of payment cards is illustrated, which utilizes a payment network and a blockchain network through a smart contract.

[0019] The system 100 can include a processing server 102. The processing server 102, discussed in more detail below, can be configured to facilitate trustless payment transactions via the use of payment cards 112, a payment network 118, and a blockchain network 104.

[0020] The blockchain network 104 can be comprised of a plurality of blockchain nodes 106. Each blockchain node 106 can be a computing system, such as illustrated in FIG. 1, configured to perform functions related to the processing and management of a blockchain, including the generation of blockchain data values, the validation of proposed blockchain transactions, the validation of digital signatures, the generation of new blocks, the verification of new blocks, and the maintenance of a copy of the blockchain, discussed in more detail below. Figure 5

[0021] The blockchain can be a distributed ledger comprised of at least a plurality of blocks. Each block can include at least a block header and one or more data values. Each block header can include at least a timestamp, a block reference value, and a data reference value. The timestamp can be the time at which the block header was generated and can be represented using any suitable method (e.g., UNIX timestamp, DateTime, etc.). The block reference value can be a value that references an earlier block in the blockchain (e.g., based on the timestamp). In some embodiments, the block reference value in the block header can be a reference to the block header of the most recently added block prior to the corresponding block. In example embodiments, the block reference value can be a hash value generated via a hash of the block header of the most recently added block. The data reference value can similarly be a reference to one or more data values stored in the block that includes the block header. In example embodiments, the data reference value can be a hash value generated via a hash of the one or more data values. For example, the block reference value can be the root of a Merkle tree generated using the one or more data values.

[0022] ​The use of block reference values and data reference values in each block header can result in the blockchain being immutable. Any attempted modification to a data value would require a new data reference value to be generated for that block, which would in turn require a newly generated block reference value for a subsequent block, and a new block reference value to be generated in each subsequent block. This would have to be performed and updated in each individual blockchain node 106 in the blockchain network 104 before a new block is generated and added to the blockchain in order for the change to be made permanent. The computational and communication limitations can make such modifications extremely difficult, if not impossible, rendering the blockchain immutable.

[0023] In some embodiments, a blockchain can be used to store information about blockchain transactions made between two different blockchain wallets. A blockchain wallet can include a private key in a cryptographic key pair that is used to generate a digital signature that serves as authorization of a blockchain transaction by a payer, where the digital signature can be verified by the blockchain network 104 using a public key in the cryptographic key pair. In some cases, the term "blockchain wallet" can refer specifically to the private key. In other cases, the term "blockchain wallet" can refer to a computing device (e.g., computing device 110, etc.) that stores the private key for use in blockchain transactions. For example, each computing device can each have its own private key for a respective cryptographic key pair, and can each be a blockchain wallet for transacting with a blockchain associated with the blockchain network. The computing devices can be any type of device suitable for storing and utilizing a blockchain wallet, such as a desktop computer, a laptop computer, a notebook computer, a tablet computer, a cellular phone, a smartphone, a smartwatch, a smart television, a wearable computing device, an implantable computing device, etc.

[0024] Each blockchain data value stored in the blockchain can correspond to other storage of blockchain transactions or data, as applicable. A blockchain transaction can include at least a digital signature of a sender (e.g., computing device 110) of currency generated using a private key of the sender, a blockchain address of a recipient (e.g., issuer system 114) of currency generated using a public key of the recipient, and an amount of blockchain currency being transferred or other data being stored. In some blockchain transactions, the transaction can also include one or more blockchain addresses of the sender that currently store blockchain currency (e.g., where the digital signature attests that they have access to such currency), and an address generated using a public key of the sender for any changes to be retained by the sender. Addresses to which cryptographic currency has been sent that can be used in future transactions are referred to as “output” addresses because each address was previously used to capture an output of a prior blockchain transaction, also referred to as an “unspent transaction” because the currency was sent to the address in the prior transaction but has not yet been spent. In some cases, a blockchain transaction can also include a public key of the sender for use by entities in verifying the transaction. For traditional processing of blockchain transactions, such data can be provided to a blockchain node 106 in the blockchain network 104 by the sender or the recipient. The node can verify the digital signature using the public key of the cryptographic key pair of the sender’s wallet, and also verify the sender’s access to the funds (e.g., that the unspent transaction has not been spent and was sent to an address associated with the sender’s wallet), a process referred to as “confirmation” of the transaction, and then include the blockchain transaction in a new block. In traditional blockchain implementations, the new block can be validated by other blockchain nodes 106 in the blockchain network 104 before being added to the blockchain and distributed to all blockchain nodes 106 in the blockchain network 104. In cases where the blockchain data value can not be related to a blockchain transaction, but to storage of other types of data, the blockchain data value can still include or otherwise involve verification of a digital signature.

[0025] As discussed herein, a blockchain currency can refer to any asset that can be stored on a blockchain and transferred through use of a blockchain transaction. A blockchain currency can include any cryptocurrency, stable coin (e.g., a blockchain currency pegged to a fiat currency or other asset), non-fungible token, digital token, fiat currency stored on a blockchain, etc. In some cases, the blockchain currency utilized in system 100 can depend on what the issuer system 114 accepts, the capabilities of the blockchain network 104, the desires of the consumer 108, and / or the criteria of the processing server 102.

[0026] The system 100 can also include a payment network 118. The payment network 118 can be a system or network for the transfer of money via the use of cash surrogates for thousands, millions, or even billions of transactions during a given period of time. To handle the transfer of money for various types of transactions, the payment network can use various different protocols and processes. Transactions that can be performed via the payment network can include product or service purchases, credit card purchases, debit transactions, money transfers, account withdrawals, etc. The payment network can be configured to perform transactions via cash surrogates, where the cash surrogates can include payment cards, credit slips, checks, transaction accounts, etc. Examples of networks or systems configured to perform as a payment network include the networks or systems operated by American Express®, etc. Use of the term “payment network” herein can refer to both a payment network as an entity, as well as the entity payment network, such as the equipment, hardware, and software that make up the payment network, also referred to as the “payment rail.”

[0027] As used herein, a “payment card” can refer to a card, which can be a physical card or a virtual card, that can be presented to a merchant in order to fund a payment transaction using an associated account. In some cases, the term “payment card” can refer to a digital token supplied to the computing device 110 for use in a payment transaction. In example embodiments, the payment card 112 can be supplied to the consumer 108 via the issuer system 114.

[0028] The issuer system 114 can be associated with an issuer, which can be an entity that establishes (e.g., opens) a credit slip or line of credit for a beneficiary as a payee, and honors drafts drawn by the beneficiary against the amount specified in the credit slip or line of credit. In many cases, the issuer can be a bank or other financial institution that is authorized to open lines of credit. In some instances, any entity that can provide a line of credit to a beneficiary can be considered an issuer. The line of credit opened by the issuer can be represented in the form of a payment account, and the beneficiary can draw against the line of credit via the use of the payment card 112.

[0029] Traditionally, a consumer 108 can use a payment card 112 issued to them to fund a payment transaction with a merchant system 116 in a fiat currency via an associated transaction account (e.g., via a point-of-sale or other interface of the merchant system 116). As used herein, a “payment transaction” can refer to a transaction between two entities in which money or other financial interest is exchanged from one entity to another. A payment transaction can be a transfer of funds for the purchase of goods or services, for the repayment of a debt, or for any other exchange of financial interest as will be apparent to those of skill in the relevant art. In some instances, a payment transaction can refer to a transaction in which funds are provided via a payment card 112 and / or payment account, such as a credit card transaction. Such payment transactions can be processed via the issuer system 114, a payment network 118, and an acquirer. Processing for such payment transactions can include at least one of authorization, batching, clearing, settlement, and provision of funds. Authorization can include the consumer 108 providing payment details to the merchant system 116, the merchant system 116 submitting transaction details (e.g., including the payment details) to its acquirer, and the issuer system 114 verifying payment details of a payment account of the consumer used to fund the transaction. Batching can refer to the storage of authorized transactions in bulk with other authorized transactions for distribution to an acquirer. Clearing can include the sending of bulk transactions from an acquirer to a payment network 118 for processing. Settlement can include the payment network 118 deducting funds from an issuer for transactions involving beneficiaries of the issuer. In some instances, the issuer can pay the acquirer via the payment network 118. In other instances, the issuer can pay the acquirer directly. Provision of funds can include the payment of cleared and settled payment transactions from the acquirer to the merchant. It will be apparent to those of skill in the relevant art that the order and / or classification of the steps discussed above are performed as part of payment transaction processing.

[0030] In the system 100, a consumer 108 can be interested in making payments in payment transactions with a merchant system 116 using a blockchain wallet stored on a computing device 110. However, the merchant system 116 can be interested in receiving payments via traditional processing and in fiat currency. To facilitate such transactions, the consumer 108 can apply for a payment card 112 from an issuer system 114 that is willing to accept payments from the consumer via a blockchain currency. The consumer 108 can request a payment card 112 for a specific amount of blockchain currency from the issuer system 114 and can provide authorization for such a transfer from their blockchain wallet via suitable means, such as providing a digital signature, their public key, one or more unspent transaction outputs, etc. The issuer system 114 can receive the request and, if acceptable, issue the payment card 112 to the consumer 108 (e.g., as a physical card, a virtual card, or a digital token to the computing device 110, etc.) and generate a smart contract associated with the payment card 112. The smart contract can be provisioned to a blockchain node 106 in the blockchain network 104 and configured to transfer blockchain currency from the consumer 108 to the issuer system 114 only after an authorized payment transaction is made with the payment card 112. In some cases, the smart contract can transfer funds controlled by the blockchain wallet of the computing device 110. In other cases, the smart contract itself can obtain funds. In such cases, the smart contract can operate a blockchain wallet, where the consumer 108 transfers a specified amount of blockchain currency to the smart contract. In these cases, the consumer 108 can perform additional transactions to increase the funding provision of the smart contract. In such instances, the payment card 112 can be used for multiple payment transactions using the methods discussed herein, so long as the consumer 108 provides sufficient funds to cover additional payment transactions.

[0031] In some embodiments, the smart contract can be generated by another component in the system 100, such as the processing server 102, a blockchain node 106, or a third-party system. In some cases, the functionality of the smart contract can be predetermined such that the configuration of the smart contract is the same regardless of which component generates the smart contract, which can also enable any component in the system 100 to generate the smart contract. In some instances, the smart contract can be verified by another component in the system 100 after generation before being added to the blockchain. For example, the issuer system 114 can generate the smart contract, which can be provided to the consumer 108 via the computing device 110 for verification and approval before being added to the blockchain. In another example, the issuer system 114 can provision the relevant information of the smart contract (e.g., the destination address, the funding provision information from the consumer 108, etc.) to the blockchain node 106, which can use traditional methods and systems to generate and add the smart contract to the blockchain.

[0032] In some cases, the smart contract can include an identifier that can be provided by the issuer system 114 or by the blockchain node 106, such as a smart contract identifier can be a transaction identifier that includes a blockchain data value for the smart contract. In such cases, the smart contract identifier can be included in communications related to the smart contract, such as transaction messages, as discussed below. In some instances, the issuer system 114 can provide the smart contract identifier to the computing device 110 so that the consumer 108 can verify that the smart contract is correct and added to the blockchain.

[0033] The blockchain node 106 can add the smart contract to the blockchain network 104 using conventional methods and systems. Once the smart contract is added to the blockchain and the consumer 108 has received the payment card 112, the consumer 108 can use the payment card 112 to pay for a payment transaction at the merchant system 116. The merchant system 116 (e.g., via a point-of-sale device, a webpage, an application, etc.) can read payment details from the payment card 112. The payment card 112 can include payment details similar to conventional payment cards used for credit card transactions in fiat currency, such as an account number, a security code, an expiration date, a name, a billing address, etc. The merchant system 116 can read or otherwise receive the appropriate payment details from the payment card 112 and include the payment details in an authorization request generated for the new payment transaction.

[0034] The authorization request can be a transaction message submitted from the merchant and routed to the payment network 118 for processing. In some cases, the transaction messages discussed herein can be specially formatted according to one or more standards governing the exchange of financial transaction messages, such as the International Organization for Standardization’s ISO 8583 or ISO 20022 standards. In these cases, the payment details and other transaction data can be stored in particular data elements included in the transaction message. The transaction message can also include a message type indicator, one or more bitmaps, or other data specified in the applicable standard(s). In such cases, the authorization request can be a transaction message with a message type indicator indicating the authorization request.

[0035] The authorization request can include at least payment details including at least an account number from the payment card 112, a merchant identification number, a transaction amount, and any other data suitable for processing a payment transaction such as a transaction time and / or date, a currency identifier, a point-of-sale identifier, an acquirer identification value, an issuer identification value, etc. The merchant system 116 can submit the authorization request to the payment network 118 via a payment rail associated therewith, e.g., directly or via one or more intermediary systems such as an acquirer. The payment network 118 can receive the authorization request and route the authorization request based at least on the account number included in the payment details. A portion of the account number can be used as a bank identification number or other value associated with an entity authorized to process transactions using the payment card 112 in question. Accordingly, the payment network 118 can parse the account number from the authorization request and forward the authorization request to the processing server 102 using a payment rail of the payment network 118.

[0036] The processing server 102 can receive the authorization request and initiate processing thereof. In the system 100, the processing server 102 can be a separate system and / or entity from other components in the system 100. In some cases, the processing server 102 can be a part of another system and / or entity in the system 100, such as a part of the payment network 118, also serving as a blockchain node 106 in the blockchain network 104, etc. In some cases, the processing server 102 can be a part of the issuer system 114. In other cases, the processing server 102 can be separate from any issuer system 114 to maintain trustlessness in using a blockchain currency for funding a smart contract.

[0037] Once the processing server 102 receives the authorization request, the processing server 102 can determine that the authorization request is for a payment transaction funded via a blockchain-linked payment card 112. The processing server 102 can identify that the payment card 112 used in the payment transaction is issued by the issuer system 114, such as based on the account number, a portion of the account number, or other data included in the authorization request. The processing server 102 can identify a smart contract associated with the payment card 112, such as by using the account number, a portion of the account number, or other value included in the transaction message (e.g., a smart contract identifier), and electronically transmit the authorization request to a blockchain node 106 in the blockchain network 104 for submission as input to the smart contract. The processing server 102 can also forward the authorization request to the issuer system 114 using a suitable communication network and method.

[0038] The issuer system 114 can receive the authorization request and perform processing to determine whether the payment transaction should be approved or declined. The issuer system 114 can use data included in the authorization request to identify the payment card 112 used in the payment transaction and determine whether the smart contract has sufficient funds to cover the transaction amount of the payment transaction. If the smart contract does not have sufficient funds to cover the payment transaction, the issuer system 114 can decline the payment transaction using traditional methods. If the smart contract has sufficient funds to provide funding to cover the new payment transaction, the issuer system 114 can approve the transaction. The issuer system 114 can generate an authorization response message for the payment transaction, which can be a transaction message including a message type indicator indicating the authorization response message. In some cases, the authorization response message can be a new transaction message. In other cases, the issuer system 114 can modify the message type indicator in the authorization request to convert the authorization request into an authorization response.

[0039] The authorization response can include a data value indicating that the transaction has been approved. The issuer system 114 can electronically transmit the authorization response to a blockchain node 106 in the blockchain network 104, where the blockchain node 106 can submit the authorization response as input to the smart contract. The issuer system 114 can also forward the authorization response to the payment network 118 via its payment rails (either directly or via the processing server 102). The payment network 118 can forward the authorization response back to the merchant system 116 via its payment rails (e.g., either directly or via one or more intermediate systems such as an acquirer). The merchant system 116 can identify that the payment transaction has been approved and provide the goods or services for the transaction to the consumer 108.

[0040] In the blockchain, once the smart contract has received both the authorization request and the authorization response as inputs, the smart contract can verify that the messages match to ensure that the transaction has been processed by the authorized processing server 102 and issuer system 114. The smart contract can verify that the payment details in both messages match the payment card 112, that other transaction data in both messages (e.g., merchant identifier, transaction amount, transaction time and / or date, etc.) match, and can verify any other data included in the transaction messages as necessary. For example, in some cases, the issuer system 114 can be configured to add additional data to the authorization response that only the issuer system 114 knows to ensure that the verification is successful. For example, the smart contract can be generated with a public key and the issuer system 114 can digitally sign the authorization response with a corresponding private key, where the smart contract can verify the digital signature with the public key to ensure that the authorization response came from the true issuer system 114. In another example, for transactions involving the payment card 112, a transaction identifier or other identifying value can be shared between the processing server 102 and the issuer system 114, where the processing server 102 can include the value in the authorization request submitted to the smart contract and the issuer system 114 can include the value in the authorization response submitted to the smart contract, where the smart contract can verify the presence and equivalence of the two values. In some cases, the smart contract can be configured to receive formatted transaction messages for transmission via payment rails of the payment network 118. In other cases, the transaction messages can be converted prior to being supplied as inputs to the smart contract. Such conversion can be performed by the blockchain node 106 or other suitable system. In some cases, such other suitable systems (often referred to as “Oracles”) can be used to facilitate communication between components in the system 100, such as converting transaction messages for input into the smart contract, converting data for transmission between the processing server 102 and the issuer system 104, standardizing data for performing functions discussed herein, etc. In some embodiments, the Oracle can be responsible for supplying the authorization request and response messages (or data included therein if, for example, reformatted) as inputs into the smart contract.

[0041] Once the authorization request and response messages have been successfully verified by the smart contract, the smart contract can execute itself to transfer the appropriate amount of blockchain currency to the blockchain wallet associated with the issuer system 114 or another blockchain wallet specified in the smart contract (e.g., a smart contract provisioned by the issuer system 114 when the smart contract is generated). The transfer can be completed in a new blockchain transaction generated by the smart contract and confirmed and added to the blockchain using traditional methods. In some cases, the smart contract can be configured to transmit notification messages regarding successful verification and / or transfers, which can be transmitted to the issuer system 114, the processing server 102, and / or the computing device 110.

[0042] Once the blockchain transaction has been completed and the blockchain currency has been transferred from the smart contract to the issuer system 114, the issuer system 114 can initiate a payment in fiat currency using traditional methods to the merchant system 116. In some instances, the payment in fiat currency from the issuer system 114 can utilize a payment processing network such as a payment processor (e.g., a payment processor such as a payment processor). 114 can pay the payment processing network and the payment processing network can pay the merchant system 116. In the event that the merchant system 116 is interested in receiving payment via another currency, the issuer system 114 can facilitate such payment using a suitable payment method. In such a case, the authorization request submitted by the merchant system 116 can specify the currency in which payment is requested, and the transaction amount in the authorization request can be the amount in the desired currency. As a result, consumers 108 can pay via payment cards 112 using their desired blockchain currency, and merchant systems 116 can receive payment in their desired currency without requiring any modifications to existing systems and processes.

[0043] In cases where the consumer 108 uses a stable coin pegged to the same fiat currency received by the merchant system 116, the processing discussed above can be performed without any currency exchange or conversion. In cases where the blockchain currency used by the consumer 108 differs in value from the fiat currency received by the merchant, the equivalent amount of each currency can be identified during the processing discussed above. In an example, the processing server 102 can receive an authorization request from the payment network 118 that includes a transaction amount in the fiat currency requested by the merchant system 116. The processing server 102 can calculate an equivalent amount in the blockchain currency, which can be a set value, specified in a smart contract, based on known exchange rate data, etc. The processing server 102 can provide this amount as part of the authorization request to the issuer system 114 (e.g., in a data element reserved for private use) or separate from the authorization request in the same transmission or a separate transmission. In another example, the issuer system 114 can perform the calculation. In an example embodiment, the exchange rate between the fiat currency and the blockchain currency can be stored in a smart contract to further maintain the trustlessness of the transaction for the consumer 108.

[0044] In some embodiments, the processing server 102 can be configured to generate account numbers used in payment cards 112 in the system 100. In such embodiments, when the issuer system 114 wants to generate a new payment card 112 for the consumer 108, the issuer system 114 can use an account number provided by the processing server 102 (e.g., before or upon request by the issuer system 114 upon generation of the payment card 112). In some cases, the processing server 102 can have a bank identification number associated therewith that is provided to the issuer system 114 for inclusion in the account number. In such embodiments, the provisioning of the account number or bank identification number by the processing server 102 can ensure that authorization requests are routed to the processing server 102 by the payment network 118. Further, the processing server 102 can be configured to perform the functions discussed herein for multiple different issuer systems 114, which can enable multiple entities to issue payment cards 112 to the consumer 108 for the processing discussed herein.

[0045] In some embodiments, the blockchain transaction can be provided to the smart contract by the processing server 102 and the issuer system 114 in place of the transaction message for the card payment transaction. In such embodiments, once the processing server 102 receives the authorization request, the processing server 102 can generate a blockchain transaction for transferring the blockchain currency from the smart contract to the destination address, and can electronically transmit the blockchain transaction to the blockchain node 106 for input into the smart contract. Likewise, the issuer system 114 can generate a blockchain transaction for transferring the blockchain currency from the smart contract to the destination address upon receiving the authorization request from the processing server 102, and provide the new blockchain transaction to the blockchain node 106 for input into the smart contract. The smart contract can perform its verification by verifying that the two blockchain transactions received are accurate (e.g., correct destination address and other transaction data) and are identical.

[0046] In other embodiments, the verification of the authorization request and authorization response discussed above can be performed by a different component than the smart contract, such as the processing server 102, the issuer system 114, or a third party system. In such embodiments, the component can perform the verification as discussed above, and in the case of success, generate a new blockchain transaction for transferring the appropriate amount of blockchain currency from the smart contract to the issuer system 114. The new blockchain transaction can be submitted as input to the smart contract via the blockchain node 106, which can verify the accuracy of the new blockchain transaction and add the new blockchain transaction to the blockchain upon execution by the smart contract.

[0047] In some instances, the smart contract can be configured to perform fewer transfers to the issuer system 114 using aggregation, such as in the case where the payment card 112 can be used for multiple transactions. In such instances, the smart contract can perform the verification process discussed above, and in the case of success, provide a notification message to the processing server 102 and / or the issuer system 114, but not initiate a new blockchain transaction. The smart contract can perform the same actions for additional payment transactions and can aggregate the transaction amounts of each payment transaction. When triggered, the smart contract can initiate a single new blockchain transaction for paying the aggregated amount to the issuer system 114 or other destination address. The smart contract can be triggered using any suitable method, such as periodically (e.g., daily, weekly, etc.), when the transaction amount exceeds a predetermined value, upon request from the issuer system 114, etc.

[0048] The methods and systems discussed herein provide trustless payment transactions that can be conducted using payment card and traditional card processing, but with consumers 108 funding payment transactions via a blockchain currency, and merchant systems 116 receiving payments via fiat or other currencies when desired. The use of smart contracts ensures that transactions are trustless, where consumers 108 can be confident that only transactions they themselves initiate and that are processed by the appropriate systems will be successfully processed. Further, consumers 108 can use whatever currency they want at any merchant, without needing to consider the merchant’s acceptance rules, and can do so using familiar and trusted payment card systems. Further, merchant systems 116 can receive payments in whatever currency they desire, without needing to make any modifications to existing systems and processing, while enabling their consumers 108 to make payments in whatever currency they want (so long as a payment card 112 is used). The result is a technologically advanced system that greatly benefits both consumers 108 and merchant systems 116.

[0049] Computing system

[0050] Figure 2 An embodiment of a computing system 200 in the system 100 of Figure 1 will be apparent to those of ordinary skill in the relevant art, Figure 2 the embodiment of the computing system 200 shown in Figure 5 For example, the computer system 500, shown in FIG. 5 and discussed in more detail below, can be a suitable configuration of the computing system 200. In some cases, components of the system 100, such as the processing server 102, the blockchain nodes 106, the issuer systems 114, the merchant systems 116, and the computing devices 110, can include Figure 2 the components shown in FIG. 5 and discussed below.

[0051] The computing system 200 can include a receiving device 202. The receiving device 202 can be configured to receive data over one or more networks via one or more network protocols. In some instances, the receiving device 202 can be configured to receive data from the processing server 102, the blockchain node 106, the computing device 110, the issuer system 114, the merchant system 116, the payment network 118, and other systems and entities via one or more communication methods, such as radio frequency, a local area network, a wireless area network, a cellular communication network, Bluetooth, the Internet, and the like. In some embodiments, the receiving device 202 can be comprised of multiple devices, such as different receiving devices for receiving data over different networks, such as a first receiving device for receiving data over a local area network and a second receiving device for receiving data via the Internet. The receiving device 202 can receive data signals transmitted electronically, where data can be superimposed or otherwise encoded on the data signals, and the data signals received via the receiving device 202 are decoded, parsed, read, or otherwise obtained. In some cases, the receiving device 202 can include a parsing module for parsing received data signals to obtain data superimposed thereon. For example, the receiving device 202 can include a parser program configured to receive data signals and transform the received data signals into usable inputs for functions performed by processing devices to perform the methods and systems described herein.

[0052] The receiving device 202 can be configured to receive data signals electronically transmitted by the processing server 102, which can be superimposed or otherwise encoded with transaction messages, authorization requests, bank identification numbers, account numbers, transaction amounts, notification messages, and the like. The receiving device 202 can also be configured to receive data signals electronically transmitted by the blockchain node 106, which can be superimposed or otherwise encoded with blockchain data, transaction identifiers, smart contract data, cryptographic keys, notification messages, and the like. The receiving device 202 can also be configured to receive data signals electronically transmitted by the computing device 110, which can be superimposed or otherwise encoded with registration data, payment details, cryptographic keys, digital signatures, account balances, and the like. The receiving device 202 can also be configured to receive data signals electronically transmitted by the issuer system 114, which can be superimposed or otherwise encoded with payment card data, digital tokens, notification messages, smart contract data, blockchain data, cryptographic keys, and the like. The receiving device 202 can also be configured to receive data signals electronically transmitted by the merchant system 114 and the payment network 118, which can be superimposed or otherwise encoded with transaction messages, authentication data, destination addresses, cryptographic keys, payment details, and the like.

[0053] The computing system 200 can also include a communication module 204. The communication module 204 can be configured to transmit data between the modules, engines, databases, memories, and other components of the computing system 200 for performing the functions discussed herein. The communication module 204 can include one or more communication types and utilize various communication methods for communication within the computing device. For example, the communication module 204 can include a bus, a pin connector, a wire, etc. In some embodiments, the communication module 204 can also be configured to communicate between internal components of the computing system 200 and external components of the computing system 200, such as an externally connected database, display device, input device, etc. The computing system 200 can also include a processing device. The processing device can be configured to perform the functions of the computing system 200 discussed herein as will be apparent to those of skill in the relevant art. In some embodiments, the processing device can include and / or be comprised of a plurality of engines and / or modules specifically configured to perform one or more functions of the processing device, such as a query module 216, a generation module 218, a verification module 220, etc. As used herein, the term “module” can be software or hardware specifically programmed to receive input, perform one or more processes using the input, and provide output. Based on the present disclosure, the input, output, and processes performed by the various modules will be apparent to those of skill in the art.

[0054] The computing system 200 can also include an account database 206. The account database 206 can be configured to store one or more account profiles 208 using a suitable data storage format and schema. The account database 206 can be a relational database that utilizes a structured query language to store, identify, modify, update, access, etc. structured data sets stored therein. Each account profile 208 can be a structured data set configured to store data related to the computing device 110, the consumer 108, the payment card 112, the issuer system 114, etc. The account profile 208 can store account numbers, bank identification numbers, issuer system 114 identification information, smart contract data, etc. For example, the processing server 102 can store an account profile 208 for each issuer system 114, where the account profile 208 includes all account numbers for which authorization requests should be routed to that issuer system 114.

[0055] The computing system 200 can also include blockchain data 210, which can be stored in the memory 214 of the computing system 200 or in a separate area within the computing system 200 or accessible thereby. The blockchain data 210 can include a blockchain, which can be comprised of a plurality of blocks and associated with the blockchain network 104 and the core blockchain. In some cases, the blockchain data 210 can also include any other data associated with the blockchain and its management and execution, such as block generation algorithms, digital signature generation and validation algorithms, communication data for blockchain nodes 106, smart contracts, cryptographic keys, and the like. The blockchain data 210 can also include data used by the computing system 200 for actions associated with the blockchain, such as cryptographic key pairs for blockchain wallets, public keys for generating destination addresses or validating digital signatures, transaction histories, cryptographic currency amounts, and the like.

[0056] The computing system 200 can also include a memory 214. The memory 214 can be configured to store data for use by the computing system 200 in performing the functions discussed herein, such as public and private keys, symmetric keys, and the like. The memory 214 can be configured to store data using suitable data formatting methods and patterns, and can be any suitable type of memory, such as read-only memory, random access memory, and the like. The memory 214 can include, for example, cryptographic keys and algorithms, communication protocols and standards, data formatting standards and protocols, program code for modules and applications for processing devices, and other data that can be suitable for use by the computing system 200 in performing the functions disclosed herein, as will be apparent to those of skill in the relevant art. In some embodiments, the memory 214 can be comprised of or can otherwise include a relational database that utilizes a structured query language to store, identify, modify, update, access, and the like, structured data sets stored therein. The memory 214 can be configured to store, for example, cryptographic keys, cryptographic key pairs, cryptographic algorithms, encryption algorithms, communication information, data formatting rules, network identifiers, payment details, blockchain wallet data, transaction messaging data, exchange rate information, transaction amount data, smart contract data, and the like.

[0057] The computing system 200 can include a query module 216. The query module 216 can be configured to perform queries on databases to identify information. The query module 216 can receive one or more data values or query strings and can execute the query string based on an indicated database, such as the memory 214 of the computing device 200, to identify information stored therein. The query module 216 can then output the identified information to an appropriate engine or module of the computing device 200 as needed. For example, the query module 216 can perform a query on the account database 206 to identify an account profile 208 associated with an account number included in a received authorization request for forwarding the authorization request to an appropriate processing server 102 or issuer system 114.

[0058] The computing system 200 can also include a generation module 218. The generation module 218 can be configured to generate data for use by the computing system 200 in performing the functions discussed herein. The generation module 218 can receive instructions as input, can generate data based on the instructions, and can output the generated data to one or more modules of the computing system 200. For example, the generation module 218 can be configured to generate data messages, notification messages, response messages, cryptographic keys, blockchain transactions, blockchain data values, digital signatures, smart contracts, transaction messages, authorization responses, converted currency amounts, authentication requests, and the like.

[0059] The computing system 200 can also include a verification module 220. The verification module 220 can be configured to perform verifications of the computing system 200 as part of the functions discussed herein. The verification module 220 can receive instructions as input, which input can also include data used to perform the verifications, can perform the verifications as requested, and can output results of the verifications to another module or engine of the computing system 200. For example, the verification module 220 can be configured to verify digital signatures, authenticate registration data, verify that transaction messages comply with established criteria, verify transaction messages, verify transaction amounts, verify smart contract data, and the like.

[0060] The computing system 200 can also include a transmission device 222. The transmission device 222 can be configured to transmit data over one or more networks via one or more network protocols. In some instances, the transmission device 222 can be configured to transmit data to the processing server 102, the blockchain node 106, the computing device 110, the issuer system 114, the merchant system 116, the payment network 118, and other entities via one or more communication methods (local area network, wireless local area network, cellular communication, Bluetooth, radio frequency, the Internet, etc.). In some embodiments, the transmission device 222 can be comprised of multiple devices, such as different transmission devices for transmitting data over different networks, such as a first transmission device for transmitting data over a local area network and a second transmission device for transmitting data via the Internet. The transmission device 222 can electronically transmit a data signal with data superimposed that can be parsed by a receiving computing device. In some cases, the transmission device 222 can include one or more modules for superimposing, encoding, or otherwise formatting data into a data signal suitable for transmission.

[0061] The transmission device 222 can be configured to electronically transmit data signals to the processing server 102 that are superimposed or otherwise encoded with account numbers, payment details, transaction messages, notification messages, account requests, bank identification number requests, and the like. The transmission device 222 can also be configured to electronically transmit data signals to the blockchain node 106 that can be superimposed or otherwise encoded with requests for blockchain data, requests for smart contract data, authentication requests, new blockchain transactions, smart contracts, smart contract input data, cryptographic keys, authorization requests, authorization responses, and the like. The transmission device 222 can also be configured to electronically transmit data signals to the computing device 110 that can be superimposed or otherwise encoded with confirmation messages, transaction identifiers, cryptographic keys, data requests, notification messages, destination addresses, transaction amounts, and the like. The transmission device 222 can also be configured to electronically transmit data signals to the issuer system 114 that can be superimposed or otherwise encoded with payment card requests, authorization requests, transaction messages, account numbers, bank identification numbers, notification messages, and the like. The transmission device 222 can also be configured to electronically transmit data signals to the merchant system 114 and the payment network 118 that can be superimposed or otherwise encoded with payment details, transaction amounts, authorization requests, authorization responses, transaction messages, notification messages, account requests, transaction data, and the like.

[0062] Processing for trustless payment transactions

[0063] Figure 3A and Figure 3B FIG. 1 illustrates a system 100 for performing a payment transaction using a card network and a blockchain. Figure 1

[0064] ​In step 302, the consumer 108 can request a payment card 112 from the issuer system 114 by submission using a suitable communication network and method (e.g., via the computing device 110). In step 304, the receiving device 202 of the issuer system 114 can receive the payment card request. The payment card request can specify a blockchain currency, a requested amount of funds to be provided, and provide any other necessary details. In step 306, the receiving device 202 of the issuer system 114 can receive a new smart contract for the requested payment card 112, which can be received upon request from a third party system after the issuer system 114 submits relevant data (e.g., a destination address, payment details for the requested payment card 112, etc.) to the third party system. The new smart contract can include a destination address for a blockchain wallet of the issuer system 114, payment details for the requested payment card 112, and any other data suitable for performing the functions discussed herein. In step 308, the transmitting device 222 of the issuer system 114 can transmit the smart contract to a blockchain node 106 in the blockchain network 104 electronically using a suitable communication network and method. In some cases, the payment card request can include a blockchain transaction to fund the smart contract. In other cases, the consumer 108 can submit one or more new blockchain transactions to fund the smart contract via the computing device 110 to a blockchain node 106 in the blockchain network 104.

[0065] In step 310, the receiving device 202 of the blockchain node 106 can receive the smart contract from the issuer system 114. In step 312, the blockchain node 106 can add the smart contract to the blockchain associated with the blockchain network 104 using conventional methods. In step 314, the generation module 218 of the issuer system 114 can generate a new payment card 112, which can include the payment details included in the generated smart contract. In some cases, the payment details can include a bank identification number previously provided to the issuer system 114 by the processing server 102. In step 316, the issuer system 114 can issue the payment card 112 to the consumer 108, which can be a physical card delivered to the consumer 108, or a virtual card or digital token transmitted electronically to the consumer 108 (e.g., from the transmitting device 222 of the issuer system 114 via the computing device 110). In step 318, the consumer 108 can receive the payment card 112 from the issuer system 114 that is linked to the smart contract that has been added to the blockchain.

[0066] At step 320, the consumer 108 can use the payment card 112 at the merchant. The consumer 108 can use the payment card 112 in any manner to communicate payment details to the merchant system 116, such as via a magnetic stripe, near field communication, integrated circuit chip, form input on a webpage, or application, etc. The merchant can receive the payment details and generate an authorization request for the payment transaction including the payment details and the transaction amount. The merchant can then submit the authorization request to the payment network 118 via a payment rail associated therewith. The payment network 118 can then route the authorization request to the processing server 102 using the account number or data included in the authorization request. At step 322, the receiving device 202 of the processing server 102 can receive the authorization request. At step 324, the processing server 102 can electronically transmit the authorization request via the transmission device 222 to the blockchain node 106 in the blockchain network 104 for submission to the smart contract as an input thereto. At step 326, the transmission device 222 of the processing server 102 can also electronically transmit the authorization request to the issuer system 114, which the processing server 102 can identify using the account number or other transaction data included in the authorization request (e.g., via the query module 214 and the account profile 208). Where currency conversion is necessary, the processing server 102 can identify the appropriate amount of blockchain currency, which it can transmit to the issuer system 114 as part of or in addition to the authorization request.

[0067] At step 328, the receiving device 202 of the issuer system 114 can receive the authorization request. At step 330, the issuer system 114 can process the payment transaction, such as by ensuring that the appropriate amount of blockchain currency for the payment transaction is covered by the funding provided amount of the smart contract associated with the payment card 112 used in the payment transaction. The issuer system 114 can approve the payment transaction and generate a payment transaction authorization response via its generation module 218 indicating the approval of the transaction. At step 332, the transmission device 222 of the issuer system 114 can electronically transmit the authorization response to the blockchain node 106 in the blockchain network 104. At step 334, the receiving device 202 of the blockchain node 106 can receive the authorization response.

[0068] In step 336, the blockchain node 106 can submit the received authorization request and authorization response transaction messages as inputs into the smart contract, which can initiate self-execution of the smart contract. Upon execution, the smart contract can verify the authorization request and authorization response messages to ensure that the transaction has been authorized, that each involved entity is authenticated, and that the blockchain currency amount can be fully transferred via the smart contract’s funding provision. Upon successful verification, the smart contract can generate a new blockchain transaction for paying the appropriate amount of blockchain currency to the destination address indicated in the smart contract. The new blockchain transaction can be provided to the blockchain node 106, which can add the new blockchain transaction to the blockchain using suitable methods in step 338.

[0069] In step 340, the issuer system 114 can receive the transferred blockchain currency in its blockchain wallet. In some cases, the blockchain node 106 can electronically transmit a notification message to the issuer system 114 to notify the issuer system 114 of the transfer. In other cases, the issuer system 114 can identify the new blockchain transaction on the blockchain to determine that the transfer was successful and that the currency was received. In step 342, the issuer system 114 can initiate payment of the transaction amount included in the authorization request to the merchant system 116 using conventional methods. In step 344, the consumer 108 can receive the transaction product from the merchant system 116, which can occur as a result of the payment of the blockchain currency from the consumer 108 to the issuer system 114 and the payment of the fiat currency from the issuer system 114 to the merchant system 116 in the trustless blockchain transaction.

[0070] Exemplary method for processing blockchain transactions

[0071] Figure 4 FIG. 4 illustrates a method 400 for processing a blockchain transaction using a payment card and a linked blockchain wallet.

[0072] In step 402, a smart contract configured to control an amount of blockchain currency in a blockchain can be stored in the blockchain associated with a blockchain network (e.g., the blockchain network 104). In step 404, an authorization request message can be received from a first computing system (e.g., the processing server 102) by a receiver (e.g., the receiving device 202) of one of a plurality of blockchain nodes (e.g., the blockchain node 106) in the blockchain network, wherein the one of the plurality of blockchain nodes submits the authorization request message as an input to the smart contract.

[0073] In step 406, an authorization response message can be received by a receiver of one of the plurality of blockchain nodes from a second computing system (e.g., the issuer system 114), where the one of the plurality of blockchain nodes submits the authorization response message as input to the smart contract. In step 408, the smart contract in the blockchain can be executed by one of the plurality of blockchain nodes, where execution of the smart contract causes the smart contract to (i) verify the authorization request message and the authorization response message, and (ii) transfer at least a portion of the amount of the blockchain currency to the predetermined blockchain address.

[0074] In one embodiment, the predetermined blockchain address can be stored in the smart contract. In some embodiments, the method 400 can further include receiving, by a receiver of one of the plurality of blockchain nodes, the smart contract from the second computing system prior to storing the smart contract in the blockchain. In one embodiment, verifying the authorization request message and the authorization response message can include comparing one or more data values included in each of the authorization request message and the authorization response message. In further embodiments, the authorization request message and the authorization response message can be specially formatted according to one or more standards, the one or more data values can be stored in one or more predetermined data elements, and the one or more data values can include a transaction identifier.

[0075] In some embodiments, the authorization response message can include at least a transaction amount, and execution of the smart contract can further cause the smart contract to (iii) verify that the amount of the blockchain currency is greater than or equal to the transaction amount. In one embodiment, the method 400 can further include receiving, by a receiver of one of the plurality of blockchain nodes, a new blockchain transaction that transfers additional blockchain currency to the smart contract, and storing the new blockchain transaction in the blockchain, where the amount of the blockchain currency can be increased by the additional blockchain currency. In some embodiments, the smart contract can be further configured to transfer the amount of the blockchain currency only after verifying the authorization request message and the authorization response message.

[0076] Computer system architecture

[0077] Figure 5 FIG. 13 illustrates a computer system 500 in which embodiments of the disclosure, or portions thereof, can be implemented as computer-readable code. For example, the computing device 102, the blockchain nodes 105, the merchant system 108, and the provider system 110 can be implemented in the computer system 500 using hardware, non-transitory computer-readable media having instructions stored thereon, or a combination thereof, and can be implemented within one or more computer systems or other processing systems. Figure 3A 、 Figure 3B andFigure 4 Modules and components of the method.

[0078] If programmable logic is used, such logic can be executed on a commercially available processing platform configured by executable software code to become a special-purpose computer or special-purpose device (e.g., a programmable logic array, an application-specific integrated circuit, etc.). It will be appreciated by those skilled in the art that the embodiments of the disclosed subject matter can be practiced with a variety of computer system configurations, including multi-core multi-processor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functionality, and pervasive or microcomputers that can be embedded in almost any device. For example, the above-described embodiments can be implemented using at least one processor device and memory.

[0079] The processor units or devices discussed herein may be a single processor, a plurality of processors, or a combination thereof. A processor device may have one or more processor "cores." As discussed herein, the terms "computer program medium," "non-transitory computer-readable medium," and "computer-usable medium" are generally used to refer to tangible media, such as removable storage unit 518, removable storage unit 522, and a hard disk installed in hard disk drive 512.

[0080] Various embodiments of the present disclosure are described with respect to this example computer system 500. After reading this description, it will be apparent to those skilled in the relevant art how to implement the present disclosure using other computer systems and / or computer architectures. Although operations may be described as being processed sequentially, some operations may actually be performed in parallel, concurrently, and / or in a distributed environment, and program code may be stored locally or remotely for access by a single processor or multiple processor machines. Furthermore, in some embodiments, the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.

[0081] The processor device 504 can be a special-purpose or general-purpose processor device specifically configured to perform the functions discussed herein. The processor device 504 can be connected to a communication infrastructure 506, such as a bus, message queue, network, multi-core message-passing scheme, etc. The network can be any network suitable for performing the functions as disclosed herein, and can include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., WiFi), a mobile communications network, a satellite network, the Internet, fiber optic, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to those of ordinary skill in the art. The computer system 500 can also include a main memory 508 (e.g., random access memory, read-only memory, etc.) and can also include a secondary memory 510. The secondary memory 510 can include a hard disk drive 512 and a removable storage drive 514, such as a floppy disk drive, a magnetic tape drive, an optical disk drive, flash memory, etc.

[0082] The removable storage drive 514 can read from and / or write to a removable storage unit 518 in a well-known manner. The removable storage unit 518 can include a removable storage media that can be read by and written to by the removable storage drive 514. For example, if the removable storage drive 514 is a floppy disk drive or a universal serial bus port, the removable storage unit 518 can be a floppy disk or portable flash drive, respectively. In one embodiment, the removable storage unit 518 can be a non-transitory computer-readable recording medium.

[0083] In some embodiments, the secondary memory 510 can include alternative means for allowing computer programs or other instructions to be loaded into the computer system 500. Such means can include, for example, a removable storage unit 522 and an interface 520. Examples of such means can include a program cartridge and cartridge interface (such as that found in video game systems), a removable memory chip (e.g., an EPROM, a PROM, etc.) and associated socket, and other removable storage units 522 and interfaces 520, as will be apparent to those of ordinary skill in the art.

[0084] Data stored in the computer system 500 (e.g., in the main memory 508 and / or the secondary memory 510) can be stored on any type of suitable computer-readable media, such as optical storage (e.g., optical disks, Blu-ray disks, etc.) or magnetic tape storage (e.g., hard disk drives). The data can be configured in any type of suitable database configuration, such as a relational database, a structured query language (SQL) database, a distributed database, an object database, etc. Suitable configurations and storage types will be apparent to persons of ordinary skill in the art.

[0085] The computer system 500 may also include a communication interface 524. The communication interface 524 can be configured to allow software and data to be transferred between the computer system 500 and external devices. Exemplary communication interfaces 524 may include a modem, a network interface (e.g., an Ethernet card), a communication port, a PCMCIA slot and card, etc. The software and data transmitted via the communication interface 524 may be in the form of a signal, which may be electronic, electromagnetic, optical or other signal, as will be apparent to those skilled in the relevant art. The signal may travel via a communication path 526, which may be configured to carry the signal and may be implemented using wires, cables, optical fibers, telephone lines, cellular phone links, radio frequency links, etc.

[0086] The computer system 500 may also include a display interface 502. The display interface 502 may be configured to allow data to be transferred between the computer system 500 and an external display 530. Exemplary display interfaces 502 may include a high-definition multimedia interface (HDMI), a digital video interface (DVI), a video graphics array (VGA), and the like. The display 530 may be any suitable type of display for displaying data transmitted via the display interface 502 of the computer system 500, including cathode ray tube (CRT) displays, liquid crystal displays (LCDs), light emitting diode (LED) displays, capacitive touch displays, thin film transistor (TFT) displays, and the like.

[0087] Computer program media and computer usable media may refer to memories, such as main memory 508 and secondary memory 510, which may be memory semiconductors (e.g., DRAM, etc.). These computer program products may be components for providing software to the computer system 500. Computer programs (e.g., computer control logic) may be stored in the main memory 508 and / or the secondary memory 510. The computer programs may also be received via the communication interface 524. Such computer programs, when executed, may enable the computer system 500 to implement the present methods discussed herein. In particular, the computer programs, when executed, may enable the processor device 504 to implement the methods described herein. Figure 3A 、 Figure 3B and Figure 4 514, interface 520, and hard drive 512 or communications interface 524.

[0088] The processor device 504 can include one or more modules or engines configured to perform the functions of the computer system 500. Each module or engine can be implemented using hardware and, in some cases, can also utilize software, such as corresponding to program code and / or programs stored in the main memory 508 or the secondary memory 510. In such cases, the program code can be compiled by the processor device 504 (e.g., by a compilation module or engine) prior to execution by the hardware of the computer system 500. For example, the program code can be source code written in a programming language that is translated into a lower level language, such as assembly language or machine code, for execution by the processor device 504 and / or any additional hardware components of the computer system 500. The process of compilation can include the use of lexical analysis, preprocessing, parsing, semantic analysis, syntax-directed translation, code generation, code optimization, and any other techniques that can be suitable to translate program code into a lower level language suitable to control the computer system 500 to perform the functions disclosed herein. It will be apparent to those skilled in the relevant art that such processing results in the computer system 500 being a specially configured computer system 500 that is specifically programmed to perform the functions discussed above.

[0089] The technology consistent with the present disclosure provides, among other features, systems and methods for processing trustless blockchain transactions via a card payment network. While various exemplary embodiments of the disclosed systems and methods have been described above, it should be understood that they have been presented by way of example only, and not limitation. It is not exhaustive, and does not limit the disclosure to the precise form disclosed. Modifications and variations are possible in light of the above teachings or can be acquired from the practice of the disclosure.

Claims

1. A method for processing a trustless blockchain transfer via a card payment network, comprising: storing, in a blockchain associated with a blockchain network, a smart contract, the smart contract configured to control an amount of a blockchain currency in the blockchain; receiving, by a receiver of one of a plurality of blockchain nodes in the blockchain network, an authorization request message from a first computing system, wherein the one of the plurality of blockchain nodes submits the authorization request message as input to the smart contract; receiving, by the receiver of the one of the plurality of blockchain nodes, an authorization response message from a second computing system, wherein the one of the plurality of blockchain nodes submits the authorization response message as input to the smart contract; and executing, by the one of the plurality of blockchain nodes, the smart contract in the blockchain, wherein execution of the smart contract causes the smart contract to (i) verify the authorization request message and the authorization response message, and (ii) transfer at least a portion of the amount of the blockchain currency to a predetermined blockchain address.

2. The method of claim 1, wherein the predetermined blockchain address is stored in the smart contract.

3. The method of claim 1, further comprising: receiving, by the receiver of the one of the plurality of blockchain nodes, the smart contract from the second computing system prior to storing the smart contract in the blockchain.

4. The method of claim 1, wherein verifying the authorization request message and the authorization response message comprises comparing one or more data values included in each of the authorization request message and the authorization response message.

5. The method of claim 4, wherein the authorization request message and the authorization response message are specially formatted according to one or more standards, the one or more data values are stored in one or more predetermined data elements, and the one or more data values comprise a transaction identifier.

6. The method of claim 1, wherein the authorization response message includes at least a transaction amount, and execution of the smart contract further causes the smart contract to (iii) verify that the amount of the blockchain currency is greater than or equal to the transaction amount.

7. The method of claim 1, further comprising: receiving, by the receiver of the one of the plurality of blockchain nodes, a new blockchain transaction that transfers additional blockchain currency to the smart contract; and storing, in the blockchain, the new blockchain transaction, wherein the amount of the blockchain currency is increased by the additional blockchain currency.

8. The method of claim 1, wherein the smart contract is further configured to transfer the amount of the blockchain currency only after verifying the authorization request message and the authorization response message.

9. A system for processing a trustless blockchain transfer via a card payment network, comprising: a blockchain network associated with a blockchain, the blockchain network comprising a plurality of blockchain nodes, and the blockchain storing a smart contract configured to control an amount of a blockchain currency in the blockchain; a first computing system; and a second computing system, wherein ​ ​ ​ one of the plurality of blockchain nodes receives an authorization request message from a first computing system, wherein the one of the plurality of blockchain nodes submits the authorization request message as input to the smart contract, the one of the plurality of blockchain nodes receives an authorization response message from a second computing system, wherein the one of the plurality of blockchain nodes submits the authorization response message as input to the smart contract, and the one of the plurality of blockchain nodes executes the smart contract in the blockchain, wherein execution of the smart contract causes the smart contract to (i) verify the authorization request message and the authorization response message, and (ii) transfer at least a portion of an amount of blockchain currency to a predetermined blockchain address.

10. The system of claim 9, wherein the predetermined blockchain address is stored in the smart contract.

11. The system of claim 9, wherein the one of the plurality of blockchain nodes receives the smart contract from the second computing system prior to storing the smart contract in the blockchain.

12. The system of claim 9, wherein verifying the authorization request message and the authorization response message comprises comparing one or more data values included in each of the authorization request message and the authorization response message.

13. The system of claim 12, wherein the authorization request message and the authorization response message are specially formatted according to one or more standards, the one or more data values are stored in one or more predetermined data elements, and the one or more data values comprise a transaction identifier.

14. The system of claim 9, wherein the authorization response message includes at least a transaction amount, and execution of the smart contract further causes the smart contract to (iii) verify that the amount of blockchain currency is greater than or equal to the transaction amount.

15. The system of claim 9, wherein the one of the plurality of blockchain nodes receives a new blockchain transaction that transfers additional blockchain currency to the smart contract, the blockchain stores the new blockchain transaction, and the amount of blockchain currency is increased by the additional blockchain currency.

16. The system of claim 9, wherein the smart contract is further configured to transfer the amount of blockchain currency only after verifying the authorization request message and the authorization response message.

Images