Method and system for facilitating trustless payment transactions using smart contracts

Abstract

A method for processing trustless blockchain transfers over a card payment network includes: storing a smart contract within the blockchain configured to control the amount of blockchain currency within the blockchain; receiving an acknowledgment request message from a first computing system, the blockchain node submitting the acknowledgment request message as input to the smart contract; receiving an acknowledgment response message from a second computing system, the blockchain node submitting the acknowledgment response message as input to the smart contract; and executing the smart contract within the blockchain to cause the smart contract to verify the acknowledgment request message and the acknowledgment response message, and to transfer at least a portion of the amount of blockchain currency to a predetermined blockchain address.

Description

Technical Field

[0001] The present disclosure relates to the processing of trustless payment transactions via the use of card networks and blockchains, and in particular, to providing a trustless blockchain transfer from a consumer while enabling a seller to receive fiat or other currency using smart contracts of the blockchain.

[0002] Cross - Reference to Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 451,394, filed Mar. 10, 2023, the entire content of which is incorporated by reference for all purposes.

Background Art

[0003] Blockchain transactions began to be used as an alternative to fiat currencies for the technically savvy, employing a decentralized and decentralized network for transaction tracking. Blockchain currencies (also known as cryptocurrencies) started with a relatively small market capitalization, but their market capitalization later exploded due to wider use and substantial investment and trading. Regarding the use of blockchain currencies, users are generally given two options: a self-custodial wallet, where the user controls the private key of their own blockchain wallet and conducts transactions themselves; or a custodied wallet, where a third party controls the user's private key and handles transactions on their behalf. In either case, a transaction is carried out between two blockchain wallets, and blockchain currencies are exchanged. Some blockchain networks offer the ability to convert or swap currencies, where a first currency is transferred from one party and a second currency is received by the other party. However, these processes are too difficult for the average consumer to utilize, and often expose them to excessively volatile exchange rates and fees.

[0004] At the same time, consumers are very familiar with and comfortable using payment cards for payment transactions. However, there is no system in place to enable consumers to use blockchain currency in transactions that are carried out with payment cards. Also, many sellers are still cautious about receiving blockchain currency as payment, or are indifferent to it. Therefore, consumers who wish to use blockchain currency in payment transactions with sellers must not only overcome the technical difficulties of using blockchain wallets, but also only deal with sellers who are willing to accept that blockchain currency as payment.

[0005] Therefore, there is a need for technical solutions to facilitate payment transactions on card networks that provide convenience and familiarity to consumers while enabling merchants to receive fiat currency for transactions. [Overview of the project]

[0006] This disclosure provides a description of a system and method for processing trustless blockchain transfers via a card payment network. Consumers register with a card issuer, who provides a payment card linked to a smart contract added to the blockchain for the blockchain currency the consumer wishes to use for the transaction, and the smart contract is funded through the consumer's blockchain wallet. Consumers can present the payment card to a merchant for a payment transaction, and the merchant can read the payment details from it and initiate processing of the transaction using traditional methods. In processing, the payment transaction is routed to a processor that identifies the use of a blockchain-linked payment card. The processor provides an approval request for the transaction to the smart contract and also to the card issuer. The card issuer approves the transaction (e.g., whether an equivalent amount of blockchain currency is funded) and sends an approval response message to the smart contract. The smart contract verifies that the approval request and response match and that the transaction is approved, and executes to transfer the appropriate amount of blockchain currency to the card issuer on the blockchain. When a card issuer receives payment from a consumer in blockchain currency, it forwards the payment of fiat currency (or other currency requested by the seller) to the seller using traditional processing. As a result, consumers can use payment cards and make payments via blockchain currency regardless of the seller's acceptance of blockchain currency, and sellers can accept fiat currency payments for card transactions without any changes to their existing processes. Furthermore, since funds are governed by smart contracts and can only be transferred with legitimate and approved transactions initiated by the consumer via the payment card, the transaction is trustless from the consumer's perspective.

[0007] A method for processing trustless blockchain transfers over a card payment network includes: storing a smart contract in a blockchain associated with a blockchain network, configured to govern a quantity of blockchain currency in the blockchain; receiving an acknowledgment request message from a first computing system by a receiver in one of a plurality of blockchain nodes in the blockchain network, the one of the plurality of blockchain nodes submitting the acknowledgment request message as input to the smart contract; receiving an acknowledgment response message from a second computing system by the receiver in one of the plurality of blockchain nodes, the one of the plurality of blockchain nodes submitting the acknowledgment response message as input to the smart contract; and executing the smart contract in the blockchain by one of the plurality of blockchain nodes, the execution of the smart contract causing the smart contract to (i) verify both the acknowledgment request message and the acknowledgment response message, and (ii) transfer at least a portion of the quantity of blockchain currency to a predetermined blockchain address.

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

[0009] The scope of this disclosure, when interpreted in conjunction with the accompanying drawings, will be best understood from the following detailed description of exemplary embodiments. The drawings include the following figures:

[0010] [Figure 1] This block diagram shows a high-level system architecture for processing trustless payment transactions via a card network and a blockchain network, according to an exemplary embodiment. [Figure 2]This block diagram shows a computing system in the system of Figure 1 for processing trustless payment transactions via a card network and a blockchain network, according to an exemplary embodiment. [Figure 3A] This flowchart illustrates the process for executing trustless payment transactions via a card network and a blockchain network within the system shown in Figure 1, according to an exemplary embodiment. [Figure 3B] This flowchart illustrates the process for executing trustless payment transactions via a card network and a blockchain network within the system shown in Figure 1, according to an exemplary embodiment. [Figure 4] This flowchart illustrates an exemplary method for processing trustless payment transactions via a card network and a blockchain network, according to an exemplary embodiment. [Figure 5] This block shows a computer system architecture according to an exemplary embodiment.

[0011] Further application areas of this disclosure will be obvious from the detailed description below. The detailed description of exemplary embodiments is for illustrative purposes only and is not intended to necessarily limit the scope of this disclosure. [Modes for carrying out the invention]

[0012] A system for processing trustless payment transactions Figure 1 illustrates a system 100 for processing trustless payment transactions via the use of payment cards, where a payment network and a blockchain network are utilized via smart contracts.

[0013] System 100 may include a processing server 102. The processing server 102, described later, may be configured to facilitate trustless payment transactions carried out through the use of a payment card 112, a payment network 118, and a blockchain network 104.

[0014] The blockchain network 104 may consist of multiple blockchain nodes 106. Each blockchain node 106 may be a computing system, as detailed below and shown in Figure 5, configured to perform functions related to the processing and management of the blockchain, and may include, for example, the following: generating blockchain data values, verifying proposed blockchain transactions, verifying digital signatures, generating new blocks, validating new blocks, and maintaining copies of the blockchain.

[0015] A blockchain can be a distributed ledger comprising at least several blocks. Each block may contain at least a block header and one or more data values. Each block header may contain at least a timestamp, a block reference value, and a data reference value. The timestamp may be the time the block header was generated and can be represented using any suitable method (e.g., UNIX timestamp, DateTime notation). The block reference value may be a value that references a preceding block in the blockchain (e.g., based on the timestamp). In some embodiments, the block reference value in the block header may be a reference to the block header of the most recently added block preceding each block. In an exemplary embodiment, the block reference value may be a hash value generated by hashing the block header of the most recently added block. Similarly, the data reference value may be a reference to one or more data values ​​stored within the block containing the block header. In an exemplary embodiment, the data reference value may be a hash value generated by hashing one or more data values. For example, the block reference value may be the root of a Merkle tree generated using one or more data values.

[0016] The use of block reference values ​​and data reference values ​​within each block header can give the blockchain immutability. Attempting to change a data value requires the generation of a new data reference value for that block, which in turn requires the generation of a new block reference value for the subsequent block, and further requires the generation of a new block reference value for each subsequent block. To make the change permanent, the above steps must be performed and updated for each blockchain node 106 within the blockchain network 104 before the generation of a new block and its addition to the blockchain. Due to the limitations of computing and communication capabilities, such changes can be extremely difficult or impossible, and therefore the blockchain acquires immutability.

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

[0018] Each blockchain data value stored within the blockchain may appropriately correspond to the storage of a blockchain transaction or other data. A blockchain transaction may comprise at least the following: a digital signature of a currency sender (e.g., computing device 110) generated using the sender's private key, a blockchain address of a currency recipient (e.g., issuer system 114) generated using the recipient's public key, and the amount of blockchain currency to be transferred or other data to be stored. In some blockchain transactions, the transaction may also include: one or more sender blockchain addresses where the blockchain currency is currently stored (e.g., where access to such currency is verified by a digital signature); and an address generated using the sender's public key for any changes to be held by the sender. The address to which cryptocurrency usable in a future transaction has been sent is called an "output" address because each address was previously used to supplement the output of a preceding blockchain transaction, and this is also called an "unspent transaction" because there is currency to the address that was sent in a preceding transaction in which the currency has not yet been consumed. In some cases, a blockchain transaction may also include a sender's public key for an entity to use to validate the transaction. For the traditional processing of a blockchain transaction, such data may be provided by either the sender or the recipient to a blockchain node 106 within the blockchain network 104. The node can verify the digital signature using the public key in the sender's wallet's cryptographic key pair and can also verify access to the sender's funds (for example, if an unspent transaction has not yet been consumed and has been sent to an address associated with the sender's wallet), which is known as the transaction "confirmation" process, and the node can then include the blockchain transaction in a new block.In traditional blockchain implementations, a new block may be validated by other blockchain nodes 106 within the blockchain network 108 before being added to the blockchain and distributed to all blockchain nodes 106 within the blockchain network 104. If the blockchain data value is not related to a blockchain transaction but instead to the storage of other types of data, the blockchain data value may still include or involve digital signature validation.

[0019] As described herein, blockchain currency can refer to any asset that can be stored on a blockchain and transferred through the use of blockchain transactions. Blockchain currency can include any cryptocurrency, stablecoins (e.g., blockchain currency pegged to fiat currency or other assets), non-fungible tokens, digital tokens, fiat currency stored on a blockchain, etc. In some cases, the blockchain currency utilized in system 100 may depend on what is accepted by the issuer system 114, the performance of the blockchain network 104, the preferences of the consumer 108, and / or the standards of the processing server.

[0020] System 100 may also include a payment network 118. A payment network 118 may refer to a system or network used for transferring funds using cash substitutes for thousands, millions, or billions of transactions over a given period. The payment network may use various different protocols and procedures to handle fund transfers for various types of transactions. Transactions performed through the payment network may include purchases of goods or services, credit purchases, debit transactions, fund transfers, account withdrawals, etc. The payment network may be configured to perform transactions using cash substitutes, which may include payment cards, letters of credit, checks, transaction accounts, etc. Examples of networks or systems configured to function as payment networks include those operated by Mastercard®, VISA®, Discover®, American Express®, PayPal®, etc. In this document, the term “payment network” may refer to both a payment network as an entity and a physical payment network (e.g., equipment, hardware, and software including the payment network), which are also referred to as payment rails.

[0021] Here, “payment card” can refer to a card, which can be a physical or virtual card, which can be presented to use the associated account when funding a payment transaction. In some cases, the term payment card can refer to a digital token provisioned on the computing device 110 that is used for payment transactions. In an exemplary embodiment, a payment card 112 can be provisioned to a consumer 108 via an issuer system 114.

[0022] The issuer system 114 can be associated with an issuer, which can refer to an entity that establishes (e.g., opens) a letter of credit or a credit limit for a beneficiary and receives drafts drawn by the beneficiary against the amount specified in the letter of credit or credit limit. In many embodiments, the issuer may be a bank or other financial institution authorized to open a line of credit. In some embodiments, any entity capable of extending a line of credit to a beneficiary may be considered an issuer. The line of credit opened by the issuer may be presented in the form of a payment account and may be drawn by the beneficiary by using the payment card 112.

[0023] Traditionally, a consumer 108 can use their issued payment card 112 to fund fiat currency payment transactions with the merchant system 116 (e.g., via the merchant system 116's PoS terminal or other interface) through an associated transaction account. As used herein, “payment transaction” may mean a transaction between two entities in which an amount of money or other monetary benefit is exchanged from one entity to the other. As will be obvious to those skilled in the art, a payment transaction may be the transfer of funds for the purchase of goods or services, the repayment of a debt, or any other exchange for a monetary benefit. In some embodiments, a payment transaction may refer to a transaction funded through the payment card 112 and / or payment account, such as a credit card transaction. Such payment transactions may be processed through the issuer system 114, the payment network 118, and the acquirer. Processing for such payment transactions may include at least one of the following: authorization, batching, clearing, settlement, and funding. Approval may include: consumer 108 providing payment details to seller system 116; seller system 116 submitting transaction details (e.g., payment details) to its acquirer; and verification of payment details with issuer system 114 of the consumer's payment account used to fund the transaction. Batching may refer to storing approved transactions in a batch process with other approved transactions for distribution to the acquirer. Clearing may include sending the batched transactions from the acquirer to the payment network 118 for processing. Settlement may include the payment network 118 debiting the issuer for transactions involving the issuer's beneficiaries. In some embodiments, the issuer may make payments to the acquirer via the payment network 118. In other embodiments, the issuer may make payments directly to the acquirer.Funding may include payments from the acquirer to the seller for cleared and settled payment transactions. It will be obvious to those skilled in the art that the order and / or classification of the above steps performed as part of the payment transaction processing can be appropriately chosen.

[0024] In system 100, consumer 108 may wish to use a blockchain wallet stored on computing device 110 for payments in payment transactions performed with seller system 116. However, seller system 116 may wish to receive payments through conventional processing involving fiat currency. To facilitate such transactions, consumer 108 can request a payment card 112 from issuer system 114, which authorizes accepting payments from consumers via blockchain currency. Consumer 108 can request a payment card 112 from issuer system 114 for a specific amount of blockchain currency, and can also provide authorization for such transfer from their blockchain wallet through appropriate means such as providing a digital signature, their public key, one or more unspent transaction outputs, etc. Issuer system 114 can receive the request and, if acceptable, issue a payment card 112 to consumer 108 (e.g., a physical card, virtual card, or digital token to computing device 110) and generate a smart contract associated with the payment card 112. A smart contract can be supplied to a blockchain node 106 within the blockchain network 104 and can be configured to transfer blockchain currency from the consumer 108 to the issuer system 114 only when an approved payment transaction is executed with a payment card 112. In some cases, the smart contract can transfer funds controlled by a blockchain wallet on a computing device 110. In other cases, the smart contract itself can be funded. In such cases, the smart contract can operate the blockchain wallet, and 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 of the smart contract.In such a scenario, the payment card 112 can be used for multiple payment transactions using the methods described above, as long as the consumer 108 provides sufficient funds to cover the additional payment transactions.

[0025] In some embodiments, the smart contract can be generated by another component within the system 100, such as the processing server 102, the blockchain node 106, or a third-party system. In some cases, the functionality of the smart contract can be predefined such that its configuration remains the same regardless of which component generates the smart contract, and it can be further enabled such that any component within the system 100 can generate the smart contract. In some examples, the smart contract can be verified by another component within the system 100, which can be done after its generation but before it is added to the blockchain. For example, the issuer system 114 can generate a 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. As another example, the issuer system 114 can supply information related to the smart contract (e.g., destination address, funds provision information from the consumer 108, etc.) to the blockchain node 106, which can generate the smart contract and add it to the blockchain using traditional methods and systems.

[0026] In some cases, a smart contract may include an identifier, which may be provided by the issuer system 114 or by the blockchain node 106. For example, the smart contract identifier may be a transaction identifier for a blockchain data value containing the smart contract. In such cases, the smart contract identifier may be included in communications relating to the smart contract, such as a transaction message, as described below. In some examples, the issuer system 114 may provide the smart contract identifier to the computing device 110 so that the consumer 108 can verify that the smart contract is correct and has been added to the blockchain.

[0027] Blockchain node 106 can add smart contracts to the blockchain network 104 using traditional methods and systems. Once a smart contract is added to the blockchain and consumer 108 has received a payment card 112, consumer 108 can use the payment card 112 in the seller system 116 to pay for the payment transaction. The seller system 116 can read payment details from the payment card 112 (e.g., via a PoS terminal, web page, application program, etc.). The payment card 112 may contain payment details similar to those of a traditional payment card used in credit card transactions involving fiat currency, such as account number, security code, expiration date, name, billing address, etc. The seller system 116 can read or receive the appropriate payment details from the payment card 112 and may also include payment details in an approval request generated for a new payment transaction.

[0028] An approval request may be a transaction message submitted by a seller and routed to the payment network 118 for processing. In some cases, the transaction messages described herein may be specially formatted in accordance with 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, payment details and other transaction data may be stored within specific data elements included in the transaction message. The transaction message may also include a message type identifier, one or more bitmaps, or other data specified in the applicable standards. In such cases, an approval request may be a transaction message accompanied by a message type marking indicating that it is an approval request.

[0029] An authorization request may include at least payment details, which include at least the account number from payment card 112, seller identification number, transaction amount, and any other data suitable for processing the payment transaction (e.g., transaction time and / or date, currency identifier, PoS identifier, acquirer identification value, issuer identification value, etc.). The seller system 116 may submit authorization requests to the payment network 118 via the payment rail associated with them (e.g., directly or through one or more intermediary systems such as acquirers). The payment network 118 may receive authorization requests and route them based at least on the account number contained in the payment details. Part of the account number may serve as a bank identification number or other value associated with an entity authorized to process transactions using the associated payment card 112. As a result, the payment network 118 may parse the account number from the authorization request and forward the authorization request to the processing server 102 using the payment rail of the payment network 118.

[0030] The processing server 102 can receive an approval request and initiate processing. In system 100, the processing server 102 can be a separate system and / or entity from other components within system 100. In some cases, the processing server 102 can be part of another system and / or entity within system 100, for example, part of a payment network 118, or it can act as a blockchain node 106 in a blockchain network 104. In some cases, the processing server 102 can be part of an issuer system 114. In other cases, the processing server 102 can be separate from any issuer system 114 to maintain trustlessness with respect to the use of blockchain currency used to fund smart contracts.

[0031] When the processing server 102 receives an approval request, it can determine that the approval request pertains to 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 was issued by the issuer system 114, for example, based on the account number, part of the account number, or other data included in the approval request. The processing server 102 can identify the smart contract associated with the payment card 112, for example, based on the account number, part of the account number, or other values ​​included in the transaction message (e.g., a smart contract identifier). The processing server 102 can also electronically transmit the approval 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 approval request to the issuer system 114 using an appropriate communication network and method.

[0032] The issuer system 114 can receive an approval request and process it to determine whether the payment transaction should be approved or rejected. Using the data contained in the approval request, the issuer system 114 can identify the payment card 112 used in the payment transaction and determine whether the transaction volume is covered by the smart contract's funding. If the smart contract does not have access to sufficient funds to cover the payment transaction, the issuer system 114 can reject the payment transaction using traditional methods. If the smart contract is funded to a sufficient amount to cover the new payment transaction, the issuer system 114 can approve the transaction. The issuer system 114 can generate an approval response message for the payment transaction, which may be a transaction message containing a message type indication that it is an approval response message. In some cases, the approval response message may be a new transaction message. In other cases, the issuer system 114 can modify the message type indication in the approval request to convert it into an approval response.

[0033] The acknowledgment response may include data values ​​indicating that the transaction has been approved. The issuer system 114 can electronically transmit the acknowledgment response to a blockchain node 106 in the blockchain network 104, which can then submit the acknowledgment response as input to a smart contract. The issuer system 114 can also forward the acknowledgment response to the payment network 118 directly via its payment rail or via the processing server 102. The payment network 118 can forward and return the acknowledgment response to the seller system 116 via its payment rail (for example, directly or via one or more intermediary systems such as acquirers). The seller system 116 can then identify that the payment transaction has been approved and can provide the traded goods or services to the consumer 108.

[0034] In a blockchain, once a smart contract receives both an approval request and an approval response as input, the smart contract can verify that the messages match, ensuring that the transaction was processed by an approved processing server 102 and an 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 match (e.g., seller identifier, transaction amount, transaction time and / or date), and can verify any other data contained within the transaction messages as appropriate. For example, in some cases, the issuer system 114 can be configured to add additional data known only to the issuer system 114 to the approval response to ensure successful verification. For example, a smart contract can be generated with a public key, and the issuer system 114 can digitally sign the approval response using the corresponding private key, and the smart contract can verify the digital signature using the public key to ensure that the approval response originates from the genuine issuer system 114. To give another example, a transaction identifier or other identification value can be shared between the processing server 102 and the issuer system 114 with respect to a transaction involving the payment card 112, the processing server 102 can include the value in an approval request submitted to the smart contract, the issuer system 114 can include the value in an approval response submitted to the smart contract, and the smart contract can verify the existence and equivalence of both values. In some cases, the smart contract may be configured to receive a transaction message formatted for transmission via the payment rail of the payment network 118. In other cases, the transaction message may be transformed before being supplied as input to the smart contract. Such transformation can be performed by a blockchain node 106 or another suitable system. In some cases, such another suitable system (often also referred to as an "oracle") may be used.) can be used to facilitate communication between components within System 100, for example, by converting transaction messages for input into smart contracts, converting data when transmitted between the processing server 102 and the issuer system 114, or standardizing data for use when performing the functions discussed herein. In some cases, Oracle may be responsible for supplying approval requests and approval responses (or data therefrom, for example, if reformatted) as input to smart contracts.

[0035] Once the approval request and response messages are successfully verified by the smart contract, the smart contract can self-execute and transfer an appropriate amount of blockchain currency to a blockchain wallet associated with the issuer system 114 or to another blockchain wallet indicated in the smart contract (for example, supplied by the issuer system 114 at the time of smart contract generation). This transfer can be achieved by 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 send a notification message regarding the success of verification and / or transfer, which can be sent to the issuer system 114, the processing server 102, and / or the computing device 110.

[0036] Once a blockchain transaction is completed and the blockchain currency has been transferred from the smart contract to the issuer system 114, the issuer system 114 can begin paying the seller system 116 in fiat currency using traditional methods. In some cases, the issuer system 114 can utilize a payment processing network operated by MasterCard® or similar companies, where the issuer system 114 makes a payment to the payment processing network, and the payment processing network makes a payment to the seller system 116. If the seller system 116 wishes to receive payment in another currency, the issuer system 114 can facilitate such payment using an appropriate payment method. In such cases, the approval request submitted by the seller system 116 can specify the currency requested for payment, and the transaction amount within the approval request can be the amount in the desired currency. As a result, the consumer 108 can make a payment using the desired blockchain currency via the payment card 112, while the seller system 116 can receive payment in its desired currency without requiring any changes to existing systems and processes.

[0037] If consumer 108 uses a stablecoin pegged to the same fiat currency accepted by seller system 116, the above processing can be performed without any currency exchange or conversion. If the blockchain currency used by consumer 108 has a different value from the fiat currency accepted by seller, the equivalent amounts of each currency can be identified during the above processing. For example, processing server 102 can receive an approval request from payment network 118, which may include the transaction amount in fiat currency requested by seller system 116. Processing server 102 can calculate the equivalent amount in blockchain currency, which may be a predetermined value specified in the smart contract based on known exchange rate data, etc. Processing server 102 can provide this amount to issuer system 114 (for example, within a data element reserved for private use) as part of the approval request or separately from the approval request, in the same transmission frame or a separate transmission frame. In another example, issuer system 114 can perform a calculation. In an exemplary embodiment, the exchange rate between fiat currency and blockchain currency is stored within a smart contract, further maintaining the trustlessness of the transaction for consumer 108.

[0038] In some embodiments, the processing server 102 may be configured to generate account numbers used in payment cards 112 within the system 100. In such embodiments, if the issuer system 114 intends to generate a new payment card 112 for a consumer 108, the issuer system 114 may use the account number provided by the processing server 102 (for example, before generating the payment card 112 or at the request of the issuer system 114 when generating the payment card 112). In some cases, the processing server 102 may associate it with a bank identification number, which is provided to the issuer system 114 for inclusion in the account number. In such embodiments, the provision of the account number or bank identification number by the processing server 102 ensures that the payment network 118 routes the authorization request to the processing server 102. The processing server 102 may also be configured to perform the described functions in multiple different issuer systems 114, which allows multiple entities to issue payment cards 112 to consumers 108 for use in the described process.

[0039] In some embodiments, blockchain transactions can be provided to the smart contract by the processing server 102 and the issuer system 114 in place of transaction messages relating to card payment transactions. In such embodiments, upon receiving an approval request, the processing server 102 can generate a blockchain transaction to transfer blockchain currency from the smart contract to a destination address and electronically transmit the blockchain transaction to the blockchain node 106 for input into the smart contract. Similarly, upon receiving an approval request from the processing server 102, the issuer system 114 can generate a blockchain transaction to transfer blockchain currency from the smart contract to a destination address 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 received blockchain transactions are accurate (e.g., correct destination address and other transaction data) and identical.

[0040] In other embodiments, the verification of the approval request and approval response described above can be performed by a component other than the smart contract, such as a processing server 102, an issuer system 114, or a third-party system. In such embodiments, the component can perform the verification as described above, and if successful, can generate a new blockchain transaction to transfer an 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, thereby verifying the accuracy of the new blockchain transaction and allowing the new blockchain transaction to be added to the blockchain when the smart contract is executed.

[0041] In some cases, smart contracts can perform fewer transfers to the issuer system 114 using aggregation, for example, when a payment card 112 is used for multiple transactions. In such cases, the smart contract can perform the verification process as described above, and if successful, it will send a notification message to the processing server 102 and / or the issuer system 114, but will refrain from starting a new blockchain transaction. The smart contract can perform the same action for additional payment transactions and can aggregate the transaction volume for each payment transaction. When triggered, the smart contract can start a single new blockchain transaction to pay the aggregated amount to the issuer system 114 or another destination address. Triggers for smart contracts can be made using any appropriate method, for example, periodically (e.g., daily, weekly), when the transaction volume exceeds a predetermined value, or upon request from the issuer system 114, etc.

[0042] The described method and system provide trustless payment transactions that can be carried out using payment cards and traditional card processing, but the consumer 108 funds the payment transaction via blockchain currency, and the seller system 116 accepts the payment in fiat currency or other currencies as desired. By using smart contracts, the trustlessness of the transaction is guaranteed, and the consumer 108 can be assured that only transactions initiated by themselves and processed by the appropriate system will be successfully processed. Furthermore, the consumer 108 can use any currency of their choice at any seller without regard to the seller's acceptance rules, and can do so using a familiar and trusted payment card system. In addition, the seller system 116 can accept payments in its desired currency, and can do so without any modifications to existing systems and processes, and when a payment card 112 is used, it is possible for the consumer to pay in any currency of their choice. As a result, a technologically advanced system is provided that brings significant benefits to both the consumer 108 and the seller system 116.

[0043] Computing systems Figure 2 shows an embodiment of the computing system 200 within the system 100 of Figure 1. It will be obvious to those skilled in the art that the embodiment of the computing system 200 shown in Figure 2 is provided for illustrative purposes only and does not thoroughly represent all possible configurations of the computing system 200 suitable for performing the functions of the disclosure. For example, the computer system 500 shown in Figure 5 and described in more detail below may be a suitable configuration of the computing system 200. In some cases, the components of system 100, such as the processing server 102, blockchain node 106, issuer system 114, seller system 116, and computing device 110, may include components shown in Figure 2 and described later.

[0044] The computing system 200 may include a receiving device 202. The receiving device 202 may be configured to receive data over one or more networks via one or more network protocols. In some examples, the receiving device 202 may be configured to receive data from the processing server 102, the blockchain node 106, the computing device 110, the issuer system 114, the seller system 116, the payment network 118, and other systems and entities via one or more communication methods such as radio frequency, local area network, wireless area network, cellular communication network, Bluetooth, and the internet. In some embodiments, the receiving device 202 may include multiple devices (for example, different receiving devices that receive data over different networks (e.g., a first receiving device that receives data over a local area network and a second receiving device that receives data over the internet)). The receiving device 202 may receive transmitted electronic data signals. Upon receipt of the data signals by the receiving device 202, the data may be superimposed on the data signals and then decoded, parsed, read, or retrieved. In some embodiments, the receiving device 202 may include an analysis module for analyzing the received data signal and obtaining superimposed data thereon. For example, the receiving device 202 may include an analysis program configured to receive the received data signal and convert it into available inputs for a function to be performed by the processing unit to execute the methods and systems of this disclosure.

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

[0046] The computing system 200 may also include a communication module 204. The communication module 204 may be configured to transfer data between modules, engines, databases, memory, and other components of the computing system 200 for use when performing the functions of the disclosure. The communication module 204 may include one or more communication types and may use various communication methods for communication within the computing device. For example, the communication module 204 may include buses, connection pin connectors, wires, etc. In some embodiments, the communication module 204 may also be configured to communicate between internal components of the computing system 200 and external components of the computing system 200 (e.g., externally connected databases, display devices, input devices, etc.). The computing system 200 may also include a processing unit. The processing unit may be configured to perform the functions of the computing system 200 of the disclosure. This will be obvious to those skilled in the art. In some embodiments, the processing unit may include a plurality of engines and / or modules (e.g., query module 216, generation module 218, validation module 220, etc.) specifically configured to perform one or more functions of the processing unit. As in this disclosure, the term “module” may mean software or hardware specifically programmed to receive an input, use that input to perform one or more processes, and provide an output. The inputs, outputs, and processes performed by various modules are obvious to those skilled in the art based on this disclosure.

[0047] The computing system 200 may also include an account database 206. The account database 206 may be configured to store one or more account profiles 208 using an appropriate data storage format and schema. The account database 206 may be a relational database using a structured query language, and may be a database for storing, identifying, modifying, updating, accessing, etc., stored structured datasets. Each account profile 208 may be a structured dataset configured to store data about a computing device 110, a consumer 108, a payment card 112, an issuer system 114, etc. The account profile 208 may store account numbers, bank identification numbers, identification information of the issuer system 114, smart contract data, etc. For example, the processing server 102 may store an account profile 208 for each issuer system 114, and the account profile 208 may include all account numbers to which approval requests should be routed to that issuer system 114.

[0048] The computing system 200 may also include blockchain data 210, which may be stored in the memory 214 of the computing system 200 or in a separate area within the computing system 200, or thereby made accessible. The blockchain data 210 may include a blockchain, which may comprise multiple blocks and may be associated with the blockchain network 104 and the core blockchain. In some cases, the blockchain data 210 may further include any other data associated with the blockchain and its management and performance, such as block generation algorithms, digital signature generation and confirmation algorithms, communication data about blockchain nodes 106, smart contracts, cryptographic keys, etc. The blockchain data 210 may also include data used by the computing system 200 for operations associated with the blockchain, such as cryptographic key pairs for blockchain wallets, public keys for generating destination addresses or validating digital signatures, transaction history, cryptocurrency amounts, etc.

[0049] The computing system 200 may also include a memory 214. The memory 214 may be configured to store data (e.g., public keys, private keys, symmetric keys, etc.) for use by the computing system 200 when performing the functions of the disclosure. The memory 214 may be configured to store data using appropriate data formatting methods and schemas, and may be any appropriate type of memory (e.g., read-only memory, random access memory, etc.). The memory 214 may include, for example, cryptographic keys and algorithms, communication protocols and standards, data formatting standards and protocols, module program code and processing unit application programs, and other appropriate data used by the computing system 200 when performing the functions of the disclosure. This will be obvious to those skilled in the art who read this disclosure. In some embodiments, the memory 214 may include or may include a relational database using a structured query language (SQL), and may be a database for storing, identifying, modifying, updating, accessing, etc., stored structured datasets. Memory 214 may 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 volume data, smart contract data, etc.

[0050] The computing system 200 may also include a query module 216. The query module 216 may be configured to query a database to identify information. The query module 216 may receive one or more data values ​​or query columns and, based on these, execute the query columns on the indicated database (e.g., the memory 214 of the computing device 200) to identify the information stored therein. The query module 216 may then output the identified information to the appropriate engine or module of the computing system 200 as needed. For example, the query module 216 may query an account database 206 to identify an account profile 208 associated with an account number contained in a received authorization request, in order to forward the authorization request to the appropriate processing server 102 or issuer system 114.

[0051] The computing system 200 may include a generation module 218. The generation module 218 may be configured to generate data used by the computing system 200 when performing the functions of the disclosure. The generation module 218 may receive instructions as input values, generate data based on instructions, and output the generated data to one or more modules of the computing system 200. For example, the generation module 218 may be configured to generate data messages, notification messages, response messages, cryptographic keys, blockchain transactions, blockchain data values, digital signatures, smart contracts, transaction messages, acknowledgment responses, converted currency amounts, acknowledgment requests, etc.

[0052] The computing system 200 may include a validation module 220. The validation module 220 may be configured to perform validation on the computing system 200 as part of the functionality of this disclosure. The validation module 220 may receive as input instructions that may contain data used in performing validation, may perform validation on request, and may output the validation results to another module or engine of the computing system 200. The validation module 220 may be configured to, for example, validate digital signatures, authenticate registered data, validate compliance of transaction messages using established conditions, verify transaction messages, verify transaction volumes, verify smart contract data, etc.

[0053] The computing system 200 may also include a transmitter 222. The transmitter 222 may be configured to transmit data over one or more networks via one or more network protocols. In some examples, the transmitter 222 may be configured to transmit data to the processing server 102, the blockchain node 106, the computing device 110, the issuer system 114, the seller system 116, the payment network 118, and other entities via one or more communication methods such as a local area network, a wireless area network, a cellular communication network, Bluetooth, radio frequency, or the internet. In some embodiments, the transmitter 222 may include multiple devices (e.g., different transmitters for transmitting data over different networks, e.g., a first transmitter for transmitting data over a local area network and a second transmitter for transmitting data over the internet). The transmitter 222 may electronically transmit a data signal having superimposed data that is parsed by a receiving computing device. In some embodiments, the transmitter 222 may include one or more modules for superimposing, encoding, or formatting data into a data signal suitable for transmission.

[0054] The transmitting device 222 may be configured to electronically transmit a data signal to the processing server 102, and this data signal may be superimposed or encoded with account numbers, payment details, transaction messages, notification messages, account number requests, bank identification number requests, etc. The transmitting device 222 may also be configured to electronically transmit a data signal to the blockchain node 106, and this data signal may be superimposed or encoded with requests for blockchain data, requests for smart contract data, validation requests, new blockchain transactions, smart contracts, smart contract input data, cryptographic keys, approval requests, approval responses, etc. The transmitting device 222 may also be configured to electronically transmit a data signal to the computing device 110, and this data signal may be superimposed or encoded with confirmation messages, transaction identifiers, cryptographic keys, data requests, notification messages, destination addresses, transaction amounts, etc. The transmitting device 222 may also be configured to electronically transmit data signals to the issuer system 114, which may be superimposed or encoded with payment card requests, authorization requests, transaction messages, account numbers, bank identification numbers, notification messages, etc. The transmitting device 222 may also be configured to electronically transmit data signals to the seller system 114 and the payment network 118, which may be superimposed or encoded with payment details, transaction amounts, authorization requests, authorization responses, transaction messages, notification messages, account number requests, transaction data, etc.

[0055] Processing for trustless payment transactions Figures 3A and 3B illustrate the processing for trustless payment transactions performed using the card network and blockchain within System 100 of Figure 1.

[0056] In S302, consumer 108 can request a payment card 112 from issuer system 114 (for example, via their own computing device 110), which can be done by submission using an appropriate communication network and method, which can be sent, for example, by a transmitter 222 of computing device 110. In S304, issuer system 114's receiver 202 can receive a payment card request. A payment card request can specify the blockchain currency, the requested amount of funds, and provide any other necessary details. In S306, issuer system 114's receiver 202 can receive a new smart contract for the requested payment card 112, which can be received upon request from a third-party system after issuer system 114 has submitted relevant data thereto (for example, destination address, payment details of the requested payment card 112, etc.). A new smart contract may include the destination address of the blockchain wallet of the issuer system 114, payment details for the requested payment card 112, and any other data suitable for performing the functions described above. In S308, the transmitting device 222 of the issuer system 114 may electronically transmit the smart contract to the blockchain node 106 in the blockchain network 104 using an appropriate communication network and method. In some cases, the payment card request may include a blockchain transaction to fund the smart contract. In other cases, the consumer 108 may fund the smart contract by submitting one or more new blockchain transactions to the blockchain node 106 in the blockchain network 104 via their computing device 110.

[0057] In S310, the receiving device 202 of the blockchain node 106 can receive the smart contract from the issuer system 114. In S312, the blockchain node 106 can add the smart contract to the blockchain associated with the blockchain network 104 using traditional methods. In S314, the generating module 218 of the issuer system 114 can generate a new payment card 112, which may include payment details contained within the generated smart contract. In some cases, the payment details may include a bank identification number previously provided to the issuer system 114 by the processing server 102. In S316, the issuer system 114 can issue the payment card 112 to the consumer 108, which may be a physical card delivered to the consumer 108 or a virtual card or digital token electronically transmitted to the consumer 108 (for example, from the transmitting device 222 of the issuer system 114 via its own computing device 110). In S318, the consumer 108 can receive the payment card 112 from the issuer system 114, which is linked to the smart contract added to the blockchain.

[0058] In S320, the consumer 108 can use the payment card 112 at the seller. The consumer 108 can use the payment card 112 in any manner to convey payment details to the seller system 116, for example, via a magnetic strip, near-field communication, an integrated circuit chip, a web page, or form input on an application program. The seller can receive the payment details and generate an approval request for the payment transaction, which includes the payment details and the transaction amount. The seller can then submit the approval request to the payment network 118 via its associated payment rail. The payment network 118 can then route the approval request to the processing server 102 using the account number or the data contained therein. In S322, the receiving device 202 of the processing server 102 can receive the approval request. In S324, the processing server 102 can electronically transmit the approval request via the transmitting device 222 to the blockchain node 106 in the blockchain network 104 for submission into the smart contract as its input. In S326, the transmitting device 222 of the processing server 102 can also electronically transmit the approval request to the issuer system 114, which can be identified by the processing server 102 using the account number or other transaction data included in the approval request (for example, via the query module 214 and account profile 208). If currency conversion is required, the processing server 102 can identify the appropriate amount of blockchain currency, which can be transmitted to the issuer system 114 as part of or in addition to the approval request.

[0059] In S328, the receiving device 202 of the issuer system 114 can receive the approval request. In S330, the issuer system 114 can process the payment transaction, which is done, for example, by ensuring that the appropriate amount of blockchain currency for the payment transaction is covered by the funding 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, via its generating module 218, can generate an approval response for the payment transaction indicating the approval of the transaction. In S332, the transmitting device 222 of the issuer system 114 can electronically transmit the approval response to the blockchain node 106 in the blockchain network 104. In S334, the receiving device 202 of the blockchain node 106 can receive the approval response.

[0060] In S336, blockchain node 106 can submit the received confirmation request and confirmation response transaction messages as input to the smart contract, which can initiate self-execution by the smart contract. During execution, the smart contract can verify the confirmation request and confirmation response messages to ensure that the transaction is approved, that each involved entity is authenticated, and that the amount of blockchain currency can be sufficiently transferred through the smart contract's funding. If verification is successful, the smart contract can generate a new blockchain transaction to pay the appropriate amount of blockchain currency to the destination address indicated in the smart contract. The new blockchain transaction can be provided to blockchain node 106, which in S338 can then add the new blockchain transaction to the blockchain in an appropriate manner.

[0061] In S340, the issuer system 114 can receive the transferred blockchain currency in its own blockchain wallet. In some cases, the blockchain node 106 can notify the issuer system 114 of the transfer by electronically sending a notification message to the issuer system 114. In other cases, the issuer system 114 can identify the new blockchain transaction on the blockchain and determine that the transfer was successful and the currency has been received. In S342, the issuer system 114 can initiate payment to the seller system 116 of the transaction amount included in the approval request using traditional methods. In S344, the consumer 108 can receive the traded product from the seller system 116, which may occur as a result of the issuer system 114 being paid by the consumer 108 for blockchain currency in a trustless blockchain transaction, and the seller system 116 being paid for fiat currency by the issuer system 114.

[0062] Exemplary methods for processing blockchain transactions Figure 4 illustrates a method 400 for processing blockchain transactions using a payment card and a linked blockchain wallet.

[0063] In S402, a smart contract configured to control the amount of blockchain currency within the blockchain can be stored within the blockchain associated with the blockchain network (e.g., blockchain network 104). In S404, an approval request message can be received from a first computing system (e.g., processing server 102) by a receiver (e.g., receiving device 202) on one of several blockchain nodes (e.g., blockchain node 106) within the blockchain network, and one of the several blockchain nodes submits the approval request message as input to the smart contract.

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

[0065] In one embodiment, a predetermined blockchain address may be stored within the smart contract. In some embodiments, method 400 may further include the step of receiving the smart contract from a second computing system by a receiver on one of a plurality of blockchain nodes before storing the smart contract in the blockchain. In one embodiment, the step of validating the acknowledgment request message and the acknowledgment response message may include comparing one or more data values ​​contained in each of the acknowledgment request message and the acknowledgment response message. In further embodiments, the acknowledgment request message and the acknowledgment response message may be specially formatted in accordance with one or more standards, one or more data values ​​may be stored within one or more predetermined data elements, and one or more data values ​​may include transaction identifiers.

[0066] In some embodiments, the acknowledgment response message may include at least the transaction amount, and the execution of the smart contract may further cause the smart contract to verify that (iii) the amount of blockchain currency is greater than or equal to the transaction amount. In one embodiment, method 400 may also include the following steps: receiving a new blockchain transaction by a receiver on one of a plurality of blockchain nodes, which transfers additional blockchain currency to the smart contract; and storing the new blockchain transaction in the blockchain, the amount of blockchain currency may be increased by the additional blockchain currency. In some embodiments, the smart contract may be further configured to transfer the amount of blockchain currency only after the acknowledgment request message and the acknowledgment response message have been verified.

[0067] Computer System Architecture Figure 5 shows a computer system 500, in which embodiments or parts thereof of the present disclosure may be implemented as computer-readable code. For example, the computing device 102, the blockchain node 105, the seller system 108, and the provider system 110 may be implemented in computer system 500 using hardware, a non-temporary computer-readable medium having stored instructions, or a combination thereof, and may be implemented in one or more computer systems or other processing systems. The hardware can embody modules and components used to implement the methods of Figures 3A, 3B, and 4.

[0068] Where programmable logic is used, such logic runs on a commercially available processing platform consisting of executable software code and may be an application-specific or special-purpose device (e.g., a programmable logic array, an application-specific integrated circuit (ASIC), etc.). Those skilled in the art will understand that embodiments of the disclosed subject matter are executable in a variety of computer system configurations. Such configurations include multi-core multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functions, and general-purpose or miniature computers that can be implemented in substantially any device. For example, at least one processor device and memory may be used to implement the above embodiments.

[0069] The processor units or devices of this disclosure may be a single processor, multiple processors, or a combination thereof. The processor device may have one or more processor “cores.” The terms “computer program medium,” “non-temporary computer-readable medium,” and “computer-usable medium” in this disclosure are generally used to refer to tangible media (e.g., hard disks installed in removable storage unit 518, removable storage unit 522, and hard disk drive 512).

[0070] Various embodiments of this disclosure are described in relation to this exemplary computer system 500. After reading this disclosure, it will be obvious to those skilled in the art how to implement this disclosure using other computer systems and / or computer architectures. While operations are disclosed as sequential processes, some operations may actually be executed concurrently, simultaneously, and / or in a distributed environment. In this case, the program code is stored locally or remotely for access by single-processor or multi-processor machines. Furthermore, in some embodiments, the order of operations can be rearranged without departing from the spirit of the disclosure.

[0071] The processor device 504 may be a purpose-specific or general-purpose processor device specifically configured to perform the functions of the Disclosure. The processor device 504 may be connected to a communication infrastructure 506 (e.g., a bus, message queue, network, multicore message path scheme, etc.). The network may be any network suitable for performing the functions of the Disclosure and may include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., Wi-Fi), a mobile communication network, a satellite network, the Internet, optical fiber, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be obvious to those skilled in the art. The computer system 500 may also include main memory 508 (e.g., random access memory, read-only memory, etc.) and auxiliary memory 510. The auxiliary memory 510 may include a hard disk drive 512 and a removable storage drive 514 (e.g., a floppy disk drive, magnetic tape drive, optical disk drive, flash memory, etc.).

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

[0073] In some embodiments, the auxiliary memory 510 may include alternative means that enable computer programs or other instructions to be loaded into the computer system 500 (e.g., a removable storage unit 522 and interface 520). Examples of such means may include program cartridges and cartridge interfaces (e.g., found in video game systems), removable memory chips (e.g., EEPROM, PROM, etc.) and associated sockets, and other removable storage units 522 and interface 520. This will be obvious to those skilled in the art.

[0074] Data stored in the computer system 500 (for example, in main memory 508 and / or auxiliary memory 510) may be stored on any type of suitable computer-readable medium (e.g., optical storage (compact discs, digital multipurpose discs, Blu-ray discs, etc.) or magnetic tape storage (e.g., hard disk drives)). The data may be configured in any type of suitable database configuration (e.g., relational databases, structured query language (SQL) databases, distributed databases, object databases, etc.). Suitable configurations and storage types are obvious to those skilled in the art.

[0075] The computer system 500 may also include a communication interface 524. The communication interface 524 may enable software and data to be sent and received between the computer system 500 and external devices. An exemplary communication interface 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 transferred via the communication interface 524 may be in signal form. The signal form may be electronic, electromagnetic, optical, or other signals obvious to those skilled in the art. The signals propagate through a communication path 526. The path is configured to carry signals and may be implemented using wires, cables, optical fibers, telephone lines, mobile phone links, radio frequency links, etc.

[0076] The computer system 500 may further 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. An exemplary display interface 502 may include a high-definition multimedia interface (HDMI), a digital visual interface (DVI), a video graphics array (VGA), etc. The display 530 may be any suitable type of display that displays the data transferred via the display interface 502 of the computer system 500, and includes cathode ray tube (CRT) displays, liquid crystal displays (LCDs), light-emitting diode (LED) displays, capacitive touch displays, thin-film transistor (TFT) displays, etc.

[0077] The computer program medium and computer-usable medium may refer to memory (e.g., main memory 508 and auxiliary memory 510) and may be semiconductor memory (DRAM, etc.). These computer program products may be means for providing software to the computer system 500. The computer program (e.g., computer control logic) may be stored in the main memory 508 and / or auxiliary memory 510. The computer program may also be received via the communication interface 524. When executed, such a computer program may enable the computer system 500 to perform the methods of the present disclosure. In particular, when executed, the computer program may enable the processor unit 504 to perform the methods shown in Figures 3A, 3B, and 4 as described herein. Thus, such a computer program represents a controller of the computer system 500. The present disclosure is implemented using software. The software may be stored in the computer program product and loaded into the computer system 500 using a removable storage drive 514, interface 520, and hard disk drive 512 or communication interface 524.

[0078] The processor device 504 may include one or more modules or engines configured to perform the functions of the computer system 500. Each module or engine may be implemented using hardware, and in some embodiments, it may use software (for example, this corresponds to program code or programs stored in main memory 508 or auxiliary memory 510). In such embodiments, the program code may be compiled by the processor device 504 (for example, by a compilation module or engine) before execution by the hardware of the computer system 500. For example, the program code may be source code (e.g., assembly language or machine code) written in a programming language that is translated into a low-level language. This is for execution by the processor device 504 and / or any additional hardware components of the computer system 500. The compilation process may include lexical analysis, preprocessing, syntactic analysis, semantic analysis, syntactic-driven translation, code generation, code optimization, and the use of any other techniques that may be suitable for translating the program code into a low-level language suitable for controlling the computer system 500 to perform the functions of the Disclosure. It will be obvious to those skilled in the art that such processing will result in a specially configured computer system 500 that is uniquely programmed to perform the above-mentioned functions.

[0079] The technology consistent with this disclosure provides a system and method for processing trustless blockchain transfers over a card payment network, although it also has other features. Various exemplary embodiments of the system and method of this disclosure are described above, but it should be understood that they are provided for illustrative purposes only and not limiting purposes. They are not exhaustive and do not limit this disclosure to the disclosed form itself. Modifications and variations are possible in light of the above teachings. Modifications and variations may be obtained from implementations of this disclosure without departing from the scope or extent.

Claims

1. A method for processing trustless blockchain transfers via a card payment network, The steps include storing a smart contract within a blockchain associated with a blockchain network, which is configured to control the amount of blockchain currency within the blockchain, A step of receiving an approval request message from a first computing system by a receiver on one of a plurality of blockchain nodes in the blockchain network, wherein the one of the plurality of blockchain nodes submits the approval request message as input to the smart contract. A step of receiving an acknowledgment response message from a second computing system by the receiver of one of the plurality of blockchain nodes, wherein the one of the plurality of blockchain nodes submits the acknowledgment response message as input to the smart contract. A step of executing the smart contract within the blockchain by one of the plurality of blockchain nodes, wherein the execution of the smart contract causes the smart contract to (i) verify the approval request message and the approval response message, and (ii) transfer at least a portion of the amount of blockchain currency to a predetermined blockchain address. Methods that include...

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

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

4. A method according to claim 1, wherein the step of verifying the approval request message and the approval response message includes comparing one or more data values ​​contained in each of the approval request message and the approval response message.

5. In the method according to claim 4, The aforementioned approval request message and the aforementioned approval response message are specially formatted in accordance with one or more standards. The one or more data values ​​mentioned above are stored in one or more predetermined data elements. The method wherein the one or more data values ​​include a transaction identifier.

6. In the method according to claim 1, The aforementioned acknowledgment response message includes at least the transaction amount, A method by which the execution of the smart contract further causes the smart contract to verify that the amount of the blockchain currency is equal to or greater than the transaction amount.

7. The method according to claim 1, further, The steps include: receiving a new blockchain transaction that transfers additional blockchain currency to the smart contract by the receiver of one of the plurality of blockchain nodes; The step includes storing the new blockchain transaction within the blockchain, A method by which the amount of the aforementioned blockchain currency is increased by the aforementioned additional blockchain currency.

8. The method according to claim 1, wherein the smart contract is further configured to transfer the amount of blockchain currency only after the approval request message and the approval response message have been verified.

9. A system that processes trustless blockchain transfers via a card payment network, A blockchain network associated with a blockchain, wherein the blockchain network includes multiple blockchain nodes, and the blockchain stores smart contracts configured to control the amount of blockchain currency within the blockchain, The first computing system; Equipped with a second computing system, One of the plurality of blockchain nodes receives an approval request message from the first computing system, and the one of the plurality of blockchain nodes submits the approval request message as input to the smart contract. One of the plurality of blockchain nodes receives an acknowledgment response message from the second computing system, and the one of the plurality of blockchain nodes submits the acknowledgment response message as input to the smart contract. A system in which one of the plurality of blockchain nodes executes the smart contract within the blockchain, and by executing the smart contract, causes the smart contract to (i) verify the approval request message and the approval response message, and (ii) transfer at least a portion of the amount of blockchain currency to a predetermined blockchain address.

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

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

12. The system according to claim 9, wherein verifying the approval request message and the approval response message includes comparing one or more data values ​​contained in each of the approval request message and the approval response message.

13. In the system according to claim 12, The aforementioned approval request message and the aforementioned approval response message are specially formatted in accordance with one or more standards. The one or more data values ​​mentioned above are stored in one or more predetermined data elements. The system includes one or more data values, including a transaction identifier.

14. In the system described in claim 9, The aforementioned acknowledgment response message includes at least the transaction amount, A system that, upon execution of the smart contract, further causes the smart contract to verify that (iii) the amount of the blockchain currency is equal to or greater than the transaction amount.

15. In the system described in claim 9, 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, A system in which the amount of the aforementioned blockchain currency is increased by the aforementioned additional blockchain currency.

16. The system according to claim 9, wherein the smart contract is further configured to transfer the amount of blockchain currency only after the approval request message and the approval response message have been verified.

Images