Method and system for payment processing using a decentralized digital surrogate

Abstract

A method for pre-authorization of a payment transaction using a tokenized credential includes: receiving a first data set signed with a first digital signature and including an acquirer identification value and a second data set; verifying the first digital signature using a first public key of a first cryptographic key pair associated with the acquirer identification value; extracting from the first data set a second data set including a merchant identification value and a third data set in response to verifying the first digital signature; extracting from the second data set a third data set including an issuer identification value and transaction data; identifying an issuing computing system based on the issuer identification value; and sending a fourth data set including the first data set and the steward identification value to the issuing computing system.

Description

[Technical Field]

[0001] The present disclosure relates to payment processing using decentralized digitized surrogates, and in particular to preauthorization of payment transactions using tokenized credentials.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of and priority to U.S. Patent Application No. 17 / 876,140, ​​filed July 28, 2022, the entire disclosure of which is incorporated herein by reference. [Background technology]

[0003] Nowadays, consumers are increasingly digitizing their payment cards for both security and convenience. Digitization involves the creation of a digital token that replaces the standard payment credentials for a payment account, and the consumer presents the digital token instead of a traditional payment card when completing a payment transaction. The payment token is added to transaction messages sent over payment rails, and is swapped for the standard payment credentials by a token service provider as part of payment processing. In many cases, the token service provider is the payment network of the rail on which the transaction is being processed, or can be a third-party provider that partners with it.

[0004] In many cases, payment tokens are stored within mobile devices such as smartphones or smartwatches to provide convenience to consumers. Many consumers are interested in the additional security that payment tokens can provide, where true payment credentials are not stored on the consumer's device, providing additional security in the event that the device is stolen or communications from it are intercepted. However, in current systems, payment tokens are distributed by token service providers, which require participating in a payment transaction to detokenize them, which can introduce opportunities for theft or interception of real payment credentials. As a result, there is a need to improve payment processing systems to provide complete and perfect privacy regarding actual payment credentials when using digitized payment instruments. Summary of the Invention

[0005] This disclosure provides a description of a system and method for pre-authorization of payment transactions using tokenized credentials. The system includes multiple entities, each with its own unique identifier for validation by every other entity in the system. A consumer uses their computing device to submit their credential and a payment token issued directly to them by the issuer of their associated payment account to a merchant in a first data set. The merchant appends their credential to the first data set to create a second data set, which is forwarded to the merchant's acquirer. The acquirer appends their credential to the second data set to create a third data set, which is forwarded to a steward, such as a payment processor. The steward appends their credential to the third data set to create a fourth data set, which is forwarded to the issuer. The issuer identifies the transaction account corresponding to the token and performs standard processing to authorize the transaction. The issuer appends its credentials to a fifth dataset, which contains the fourth dataset and authorization for the transaction, and sends it back to the steward. The steward generates a sixth dataset, which contains the fifth dataset and any complementary information, such as state and the steward's credentials. The sixth dataset is written to a distributed ledger, such as a blockchain, along with other datasets generated during the process. As a result, the transaction is fully verifiable at every step of the process, each entity involved can be independently verified by all others, and the true payment credentials are not available at any time to any entity except the transaction account issuer, providing significantly increased security for consumers without sacrificing convenience.In some cases, the credentials of all entities may also be stored on a distributed ledger, such as a blockchain, which may provide even greater security with respect to the verification of entities involved in a transaction, resulting in a more holistically secure and trustworthy system than has traditionally been available.

[0006] A method for pre-authorizing a payment transaction using a tokenized credential includes: receiving, by a receiver of a processing server, a first data set, the first data set being signed with a first digital signature and including at least an acquirer identification value and a second data set; verifying, by a verification module of the processing server, the first digital signature using a first public key of a first cryptographic key pair associated with the acquirer identification value; and extracting, from the first data set, the second data set in response to verifying the first digital signature, the second data set comprising: extracting, by a processor of the processing server, a fourth data set to the issuing computing system, the fourth data set including at least the first data set and a steward identification value; extracting, by a processor of the processing server, a third data set from the second data set, the third data set including at least an issuer identification value and transaction data; identifying, by a processor of the processing server, an issuing computing system based on at least the issuer identification value; and transmitting, by a transmitter of the processing server, a fourth data set to the issuing computing system, the fourth data set including at least the first data set and a steward identification value.

[0007] A system for pre-authorization of payment transactions using tokenized credentials includes: an issuer computing system; a processing server; a receiver that receives a first data set, the first data set being signed with a first digital signature and including at least an acquirer identification value and a second data set; a verification module that verifies the first digital signature using a first public key of a first cryptographic key pair associated with the acquirer identification value; and a processor that extracts the second data set from the first data set in response to verifying the first digital signature. wherein the second data set includes at least a merchant identification value and a third data set; extracting the third data set from the second data set, the third data set including at least an issuer identification value and transaction data; and identifying an issuing computing system based on at least the issuer identification value; and a transmitter that transmits a fourth data set to the issuing computing system, the fourth data set including at least the first data set and a steward identification value. [Brief explanation of the drawings]

[0008] The scope of the present disclosure is best understood from the following detailed description of illustrative embodiments when taken in conjunction with the accompanying drawings, in which:

[0009] [Figure 1] FIG. 1 is a block diagram illustrating a high-level system architecture for payment processing using a decentralized, digitized surrogate, according to an example embodiment. [Figure 2] FIG. 2 is a block diagram illustrating a computing system within the system of FIG. 1 for payment processing using a decentralized, digitized surrogate, according to an exemplary embodiment. [Figure 3]2 is a flow diagram illustrating a process for payment processing using a decentralized digitized surrogate within the system of FIG. 1 according to an exemplary embodiment. [Figure 4] 1 is a flow diagram illustrating an example method for pre-authorization of payment transactions using tokenized credentials, according to an example embodiment. [Figure 5] FIG. 1 is a block diagram illustrating a computer system architecture, according to an exemplary embodiment.

[0010] Further areas of applicability of the present disclosure will become apparent from the following detailed description. The detailed description of exemplary embodiments is intended for purposes of illustration only and is not intended to necessarily limit the scope of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0011] System for payment processing using a decentralized digital surrogate FIG. 1 illustrates a system 100 for payment transaction processing that leverages decentralized, digital surrogates, such as payment tokens, where transaction data and identity data can be stored on a distributed ledger, such as a blockchain.

[0012] System 100 may include a user device 102. User device 102 may be any type of device suitable for performing the functions referred to herein, as shown in FIG. 2 or FIG. 5 and described further below, including, for example, a desktop computer, a notebook computer, a laptop computer, a tablet computer, a mobile phone, a smartphone, a smart watch, a smart television, a wearable computing device, an embedded computing device, etc. User device 102 may be owned by or associated with a consumer. In this disclosure, user device 102 may refer to the user device 102 itself or the associated consumer. The consumer may have a transaction account issued to them by an issuing financial institution, which is represented in system 100 as issuer system 104, which may refer to the issuing financial institution itself or one or more of its computing systems, which may be the same computing systems shown in FIGS. 2 and 5 and described further below.

[0013] To utilize the system 100, a consumer can use a user device 102 to request that the issuer system 104 issue a payment token for a particular transaction account. The token can be requested using any suitable method or interface, such as through an application program or web page associated with the issuer system 104 that is made available to the user device 102 as a customer of the issuing financial institution. The issuer system 104 can authenticate the user device 102, such as using the methods described below or a traditional authentication process, and generate a payment token for the selected transaction account. The payment token can be a digital value that represents and is uniquely associated with the transaction account. In an exemplary embodiment, the payment token can be generated in a manner that prevents the transaction account from being identified using the payment token without prior knowledge of the transaction account.

[0014] In one embodiment, the payment token (also referred to in this disclosure as a payment credential) may be in the following format:

number

[0015] In this disclosure, a "URN" is a unique value that can be generated by any suitable entity using any suitable format. In the example above, the issuer system 104 can generate the URN, where the first portion before the ":" can be a surrogate value for the transaction account number, and the second portion after the ":" can be an identification value associated with the issuer system 104, such as a bank identification number or other value that can be used for routing transaction messages that include the payment credentials described above. The value for "exp" can be the expiration date of the credential. The signature can be a digital signature generated on the credential (e.g., on the combination of the URN and the expiration date) and can be generated using the private key of the issuer system's 104 cryptographic key pair (referred to in this disclosure as the "issuer private key" and the "issuer public key").

[0016] The issuer system 104 may generate a payment token and transmit it electronically to the user device 102. The user device 102 may then store the payment credentials in suitable memory on the device. After the user device 102 receives the payment token, the user device 102 may be ready to participate in payment transactions funded using the transaction account associated with the payment token.

[0017] Each participating entity in the system 100 may have associated therewith a credential, also referred to in this disclosure as an identity or identification value. A credential may be a digital value uniquely associated with an entity and / or device, similar to how a payment token is a credential for a transaction account. In an exemplary embodiment, an identity may include at least a URN for the entity. In some cases, an identity may further include or be accompanied by a public key of a cryptographic key pair associated with the entity. An identity may also be digitally signed by the entity using the private key of the entity's associated cryptographic key pair. In some cases, an identity may be digitally signed by a different entity, such as an entity that may vouch for the entity's identity. For example, the issuer system 104 may digitally sign the identity of the user device 102 using its issuer private key.

[0018] In one example, the identity may be in the following format:

number

[0019] In the above example, "publicKey" represents an RSA public key, and the signature is generated using the corresponding RSA private key. In system 100, a first entity can provide its identity to a second entity, which can verify (305) that the first entity is who it claims to be by validating the digital signature and comparing the URN to the expected URN. For example, a user device 102 can provide its identity to the issuer system 104 when requesting a payment token to ensure that the user device 102 is legitimate and authorized to receive a payment token for a specified token account. Similarly, the issuer system 104 can provide its identity to the user device 102 when providing a payment token or before receiving a request, allowing the user device 102 to verify that it is communicating with the legitimate issuer system 104 and not a fraudulent entity. In some embodiments, entity identities can be stored on a distributed ledger, such as a blockchain, as described in more detail below. If identity verification fails, the user device 102 or issuer system 104 may refuse further participation in the described process, as appropriate.

[0020] In the system 100, when a user device 102 is interested in using its payment token in a payment transaction, the user device 102 can communicate with a merchant system 106 using an appropriate communications network and method. The merchant system 106 can be a computing system, such as those shown in Figures 2 and 5 and described in more detail below, that can be configured to perform the functions described in this disclosure on behalf of the merchant. As described in this disclosure, the merchant system 106 can refer to the associated merchant or the merchant's own system.

[0021] The user device 102 and the merchant system 106 can communicate to reach an agreement on terms for the payment transaction, such as the amount of the transaction. The user device 102 can generate a first data set for the payment transaction, referred to in this disclosure as TX1. The first data set can include at least transaction data for the payment transaction, payment credentials, and a digital signature generated on the payload of the first data set (e.g., transaction data and payment credentials) using the private key of the user device 102's cryptographic key pair (also referred to in this disclosure as the user private key and user public key). In one example, TX1 can be in the following format:

number

[0022] In the above example, the transaction data may include a "tx-id," which is a unique identifier for the transaction, which may be generated by the merchant system 106 and communicated to the user device 102 using an appropriate communications network and method. The "amount" value may refer to the transaction amount being credited from the user device's transaction account to a transaction account associated with the merchant for a payment transaction. The "datetime" value may be the date and time when the transaction is performed, which may be a timestamp relative to when TX1 is generated or a future time when the transaction is processed. The "tx-receiver-urn" value may be the URN of the recipient of the transaction, such as the merchant system 106. In some embodiments, the merchant system 106 may provide its URN and any other transaction data, such as the value and transaction identifier, to the user device 102 via a quick response code or other machine-readable code that can be read by the user device 102, from which the URN and other transaction data are extracted.

[0023] In some embodiments, the merchant system 106 may provide its identity along with its URN to the user device 102. In such embodiments, the user device 102 may authenticate the merchant system 106 by verifying the provided identity before generating the first data set, e.g., to ensure that a payment is being made to the appropriate entity. If the merchant system 106's verification fails, the user device 102 may be denied further participation in the payment transaction. Once the first data set is generated and the user device 102 has authenticated the merchant system 106, if applicable, the user device 102 may transmit the generated first data set to the merchant system 106 electronically using a suitable communications network and method, e.g., via an application program or a web page of the merchant system 106, e.g., using NFC (Near Field Communication), Bluetooth, or other transmission protocols, using quick response codes, etc.

[0024] The merchant system 106 can receive the first data set and verify the data contained therein, such as verifying that the transaction amount, transaction identifier, and merchant URN are correct. The merchant system 106 can also validate the digital signature on the payment credential using the issuer's public key (e.g., made available by the issuer system 104 in a distributed ledger, as described below), and can also validate the digital signature on the payload using the user device's public key. If the user device 102 provides its identity, the merchant system 106 can also validate the user's identity using the methods disclosed herein. If any verification fails, the merchant system 106 can reject the payment transaction and stop processing. If the first data set is successfully verified, the merchant system 106 can generate a second data set for the payment transaction, referred to in this disclosure as TX2. The second data set can include at least the first data set and the URN for the merchant's acquirer. In some cases, the second data set may also include payment credentials for the merchant, which may be associated with a transaction account selected by the merchant system 106 to be used to receive funds deposited from the user device 102 for the payment transaction, for example. In one example, TX2 may be in the following format:

number

[0025] In the above example, "TX1" refers to the above example of TX1, and TX2 may contain it in its entirety but is not shown for readability. The value of "accepted-mdr" may be a merchant discount rate (mdr), which is applicable to payment transactions as will be apparent to those skilled in the art. In the above example, the payload may be digitally signed, which may be done using the private key of the merchant system's cryptographic key pair (referred to in this disclosure as the merchant private key and merchant public key).

[0026] Once the second data set has been generated and signed by the merchant system 106, the merchant system 106 may electronically transmit the second data set to the acquirer system 108. The acquirer system 108 may be a computing system, such as those shown in Figures 2 and 5 and described in more detail below, that is associated with an acquiring financial institution that issues a transaction account to the merchant system 106 specified in the second data set for receipt of payment in the payment transaction being processed. As used herein, the acquirer system 108 may refer to a computing system associated with the acquiring financial institution or the acquiring financial institution itself.

[0027] The acquirer system 108 may receive the second data set and may perform validation of the second data set. Validation may include validating the payment credentials provided by the merchant system 106 in the payload of the second data set, validating the user device's payment credentials included in the TX1 portion of the second data set, validating one or more digital signatures in the second data set using appropriate public keys, and, optionally, validating the merchant identity and / or user identity, if included in the second data set. If validation fails, the acquirer system 108 may reject the payment transaction and, optionally, return a message to the merchant system 106, which may inform the consumer that the transaction was rejected. If validation is successful, the acquirer system 108 may generate a third data set for the payment transaction, also referred to in this disclosure as TX3. The third data set may include the second data set, the acquirer's URN (and, e.g., identity, if desired), any additional transaction data, and in some cases the URN of the next entity involved in processing the payment transaction (which in the example shown in FIG. 1 may be the steward system 110). In one example, TX3 may be in the following format:

number

[0028] In the above example, "TX2" refers to the above example of TX2, and may be included in its entirety in TX3 but is not shown for readability. "urn" is the URN of the acquirer system 108 and matches the "acquirer-urn" in TX2. "steward-urn" is the URN of the steward system 110 as the next recipient for processing the payment transaction. The values ​​of "steward-fee" and "issuer-interchange-fee" are fees for processing the payment transaction and may or may not be included in the transaction as appropriate. The payload of TX3 may be digitally signed using the private key of the acquirer system's 108 cryptographic key pair (referred to in this disclosure as the acquirer private key and acquirer public key).

[0029] Once the third data set has been generated and signed by the acquirer system 108, the acquirer system 108 can electronically transmit the third data set to the steward system 110. The steward system 110 can be a computing system, such as shown in Figures 2 and 5 and described in more detail below, that performs pre-approval processing for payment transactions on behalf of other entities, such as the issuer system 104. In some embodiments, the steward system 110 can be part of the issuer system 104 or the acquirer system 108, each of which performs the functions of the steward system 110 described in this disclosure. In some cases, the steward system 110 can be part of a payment network associated with the payment rail over which the data sets are transmitted in the system 100.

[0030] The steward system 110 can receive the third data set from the acquirer system 108 and can verify the data included in the third data set. For example, the steward system 110 can verify that the included "steward-urn" value matches the URN, verify the value for the fee included in the payload for the third data set, verify the data included in the TX2 or TX1 portion of the third data set as described above, and verify the digital signature of the third data set using the acquirer public key. If the acquirer system 108 includes its identity in the third data set, the steward system 110 can also verify the identity of the acquirer system 108. If any verification fails, the steward system 110 can reject the payment transaction and, appropriately, send a message to the acquirer system 108 to stop processing the payment transaction.

[0031] If the verification is successful, the steward system 110 can generate a fourth data set for the payment transaction, also referred to in this disclosure as TX4. The fourth data set can include the third data set and the URN of the steward system. The fourth data set can also include the URN for the issuer system 104 as the next recipient of the data set as part of processing the payment transaction. In one example, TX4 can be in the following format:

number

[0032] In the above example, "TX3" refers to the above example of TX3, and is not shown for readability, even though it may be included in its entirety in TX4. "urn" is the URN of the steward system 110, matching the "steward-urn" in TX3. "issuer-urn" is the URN of the issuer system 104 as the next recipient for processing the payment transaction. The payload of TX4 can be digitally signed, and this can be done using the private key of the steward system 110's cryptographic key pair (referred to in this disclosure as the steward private key and steward public key).

[0033] Once the fourth data set is generated, the steward system 110 can electronically transmit the signed fourth data set to the issuer system 104 using an appropriate communications network and method. If the steward system 110 can perform pre-approval processing for multiple issuing financial institutions, the steward system 110 can identify the issuer system 104 using the payment credential contained in TX1 in the fourth data set, where in the example above, the second part of the URN in the credential is uniquely associated with the issuer system 104.

[0034] The issuer system 104 can receive the fourth data set from the steward system 110 and validate the fourth data set and the data contained therein. Validating the fourth data set can include verifying that the "issuer-urn" in the fourth data set matches its own URN, verifying the payment credentials and their signatures included in TX1, verifying the fees included in the data set, and verifying any other signatures in the fourth data set using the appropriate public key, including verifying the digital signature on the payload of the fourth data set using the steward public key. If the steward system 110 includes its own identity in the fourth data set, the issuer system 104 can also verify the identity of the steward system 110 using the process described above. If any validation fails, the issuer system 104 can reject the payment transaction and return a message to the steward system 110 as appropriate for forwarding to the acquirer system 108 and ultimately to the merchant system 106. In some cases, the issuer system 104 may electronically send a notification message to the user device 102 indicating the rejection of the payment transaction, for example, notifying the user device 102 that a malicious entity has attempted to use a transaction account associated with the user device 102.

[0035] If the fourth data set is successfully verified, the issuer system 104 can use the first portion of the URN in the token to identify the transaction account associated with the payment token included in TX1. Once the transaction account is identified, the issuer system 104 can determine whether the payment transaction should be approved or rejected using traditional techniques, such as ensuring that the transaction account balance can cover the payment transaction amount and ensuring that the transaction complies with any controls imposed on the transaction account. If the transaction is rejected as a result of processing, the issuer system 104 can electronically send a notification to the steward system 110 and / or the user device 102, as described above.

[0036] If the payment transaction is approved, the issuer system 104 may debit the user's transaction account as appropriate and may generate a fifth data set for the payment transaction, also referred to in this disclosure as TX5. The fifth data set may include the fourth data set as well as the issuer URN, the steward system 110 URN, and an indication of the result of the approval process by the issuer system 104. In one example, TX5 may be in the following format:

number

[0037] In the above example, "TX4" refers to the above example of TX4, and TX5 may contain the entire data, but is not shown for readability. "urn" is the URN of the issuer system 104, which matches the "issuer-urn" in TX4. "steward-urn" is the URN of the steward 110 as the next recipient for processing the payment transaction, which matches the URN in TX4 and the "steward-urn" in TX3. The payload of TX5 can be digitally signed using the issuer private key. The value of "authorization" indicates the result of the issuer system's authorization process, which in this example is approval for the payment transaction. In some cases, the fifth data set need not include a signature on the payload by the issuer system 104.

[0038] Once the fifth data set has been generated and signed, the issuer system 104 can electronically transmit the signed fifth data set to the steward system 110 using an appropriate communications network and method. The steward system 110 can verify the fifth data set, which may be done, for example, by verifying the included URN, authorizations, other data and signatures contained therein, as described above, including verifying the signature of the payload of the fifth data set using the issuer public key. Upon successful verification of the fifth data set, the steward system 110 can generate a sixth data set, also referred to in this disclosure as TX6. The sixth data set can include the fifth data set as well as the steward system URN, the issuer system 104 URN, the acquirer system 108 URN, and an indication that the payment transaction is complete. In one example, TX6 can be in the following format:

number

[0039] In the above example, "TX5" refers to the above example of TX5, and TX6 may contain it in its entirety but is not shown for readability. "urn" is the URN of the steward system 110. "issuer-urn" is the URN of the issuer system 104, matching the URN of TX5 and the "issuer-urn" of TX4. "acquirer-urn" is the URN of the acquirer system 108, matching the URN of TX3 and the "acquirer-urn" of TX2. The payload of TX6 can be digitally signed using the steward private key. The value of "status" indicates the status of the payment transaction at that point in processing, which in this example is complete. In some cases, the sixth data set need not include a signature on the payload by the steward system 110.

[0040] The steward system 110 may electronically transmit the sixth data set to the acquirer system 108. The acquirer system 108 may identify a status value in the sixth data set and may send a notification to the merchant system 106 that the transaction has been successfully processed. The acquirer system 108 may credit a transaction account used by the merchant to receive funds for the payment transaction with the amount included in the transaction data in TX1 and may receive settlement from the issuer system 104 using traditional methods. The merchant system 106 may finalize the payment transaction, for example, by providing the transacted goods or services to the consumer. In some embodiments, the acquirer system 108 may verify one or more data values ​​or signatures included in the sixth data set before notifying the merchant system 106 and crediting the associated transaction account.

[0041] The disclosed method and system allows payment transactions to be processed using payment tokens instead of actual account credentials, which are known only to the issuer system 104 that issued the transaction account, thereby providing significantly enhanced security for consumers and issuing financial institutions without sacrificing convenience. The described solution is not limited to four-party credit transactions, but is also applicable to person-to-person transactions between any two users (including their banks). Incorporating identity and signatures as part of the process as described above provides an additional level of security, ensuring that each entity is trustworthy, and can be used in payment transactions performed at a physical location or in fully electronic payment transactions (e.g., e-commerce).

[0042] In some embodiments, data sets in system 100 can be transmitted from one entity to another using payment rails associated with a payment network. A payment rail may refer to a network infrastructure associated with a payment network that is specially configured for the transmission of transaction messages. A transaction message may be a specially formatted data message 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. As discussed in this disclosure, a "payment network" may refer to a system or network used to transfer funds using cash substitutes for thousands, millions, or billions of transactions during a given period of time. A payment network may process fund transfers for various types of transactions using a variety of different protocols and procedures. Transactions performed through a payment network may include purchases of goods or services, credit purchases, debit transactions, fund transfers, direct debits, etc. Examples of networks or systems configured to perform as payment networks include those operated by Mastercard®, VISA®, Discover®, American Express®, PayPal®, etc. The term "payment network" as used herein can refer to both the payment network as an entity and the physical payment network (e.g., the equipment, hardware, and software that make up the payment network), which is also referred to in this disclosure as payment rails.

[0043] In embodiments where the data set is transmitted via a payment rail, the data set can be included in the transaction message. In some cases, values ​​in the payload of the data set can be stored in appropriate data elements of the transaction message, and the previous data set (e.g., TX1 in the second data set) can be stored in a data element reserved for private use. In some cases, the complete data set can be stored in a data element reserved for private use, and other data elements can contain null values ​​or other predetermined data to indicate to entities in system 100 that the payment transaction includes a digitized surrogate for processing using the methods described above.

[0044] In some embodiments, the acquirer, steward, and issuing bank may be embodied as the same entity. In other embodiments, any two of the acquirer, steward, and issuing bank may be embodied as the same entity.

[0045] In some embodiments, the system 100 may include a blockchain network 112. The blockchain network 112 may include a plurality of blockchain nodes 114. Each blockchain node 114 may be a computing system, such as shown in FIG. 2 or FIG. 5, configured to perform functions related to blockchain processing and management, such as those described in detail below, which may include, for example, generating blockchain data values, verifying proposed blockchain transactions, verifying digital signatures, generating new blocks, validating new blocks, and maintaining copies of the blockchain.

[0046] A blockchain may be a distributed ledger comprising at least a plurality of blocks. Each block may include at least a block header and one or more data values. Each block header may include at least a timestamp, a block reference value, and a data reference value. The timestamp may be the time when the block header was created and may be represented using any suitable method (e.g., a UNIX timestamp, DateTime notation, etc.). 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 the respective 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 in 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 created using one or more data values.

[0047] The use of a block reference value and a data reference value in each block header results in immutability for the blockchain. Any attempted change to the 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, which in turn requires the generation of a new block reference value for each subsequent block. For the change to be permanent, this must be performed and updated for every single blockchain node 114 in the blockchain network 112 before a new block is created and added to the blockchain. Computational and communication limitations can make such changes extremely difficult or impossible, thus achieving the blockchain's immutability.

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

[0049] Each blockchain data value stored in the blockchain may correspond to a blockchain transaction or other data storage, as appropriate. A blockchain transaction may include at least the following: a digital signature of the currency sender (e.g., user device 102) generated using the sender's private key, a blockchain address of the currency recipient (e.g., merchant system 106) 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., if a digital signature validates access to such currency); and an address for any changes to be maintained by the sender, generated using the sender public key. Addresses to which cryptocurrency that can be used in future transactions is sent are referred to as "output" addresses because they were previously used to capture the output of a previous blockchain transaction, and are also referred to as "unspent transactions" because there is currency sent to the address in a previous transaction where that currency has not yet been spent. In some cases, a blockchain transaction may also include a sender public key for use by an entity in validating the transaction. For traditional processing of blockchain transactions, such data may be provided by either the sender or the recipient to a blockchain node 114 in the blockchain network 112. The node can verify the digital signature using the public key in the sender's wallet's cryptographic key pair and verify access to the sender's funds (e.g., if the unspent transaction has not yet been spent and was sent to an address associated with the sender's wallet), a process known as "confirming" the transaction, and the blockchain transaction is then included in a new block.In traditional blockchain implementations, new blocks may be validated by other nodes in the blockchain network 112 before being added to the blockchain and distributed to all blockchain nodes 114 in the blockchain network 112. If the blockchain data value does not relate to a blockchain transaction but instead relates to the storage of other types of data, the blockchain data value may still include or involve digital signature validation.

[0050] The system 100 may use a blockchain or other distributed ledger to store the data sets generated as part of processing the payment transaction described above. For example, the acquirer system 108 may electronically transmit a third data set to the blockchain node 114 for inclusion in the blockchain data values ​​that are confirmed and included in a new block added to the blockchain. The issuer system 104 may electronically transmit a fifth data set to the blockchain node 114 for inclusion in the blockchain, and the steward system 110 may electronically transmit the fourth and sixth data sets to the blockchain node 114 for inclusion in the blockchain. In such an example, multiple data sets for a payment transaction may be stored on the blockchain, which may be publicly accessible. This allows any entity involved in the payment transaction to verify the data sets at each point in the transaction to ensure values ​​and fees are correct and to validate digital signatures. Because payment tokens are used in place of actual payment credentials, the data set can be stored in a publicly accessible ledger without exposing the associated transaction account to harm, and only authorized user devices 102 with the appropriate private key will be able to use the payment token in any future transactions.

[0051] In some embodiments, system 100 may include a distributed ledger, such as a blockchain, for storing identities of entities within system 100. In such embodiments, the blockchain may be the same blockchain used to store the data sets described above, or may be a separate blockchain that can be associated and manipulated via blockchain network 112, or may be associated and manipulated via a separate and different blockchain network 112. In such embodiments, blockchain data values ​​stored in the blockchain may include identities of entities as described above, such as a URN, a public key, and a signature generated using the private key of a cryptographic key pair that includes the public key. In some cases, the identities of entities may be signed by a separate entity, such as the identity of user device 102 being signed by issuer system 104. In such cases, the identities of issuer system 104 stored in the blockchain may include the same signature because the same issuer public key is included in both identities, and each identity will include a different URN corresponding to the associated entity.

[0052] When a distributed ledger is used to store identities, each entity in the system 100 can use the distributed ledger when verifying the identity of another entity as part of the process described above. For example, when processing a payment transaction, the merchant system 104 can provide its URN, the transaction amount, and the merchant system's identity to the user device 102. The user device 102 can access the distributed ledger that stores identities, identify a blockchain data value that stores the identity associated with the merchant system 104, and match the stored identity with the identity provided by the merchant system 104. For another example, the merchant system 104 can provide the user device 102 with a digital signature of its URN and the transaction amount, generated using its merchant private key. The user device 102 can access the merchant system's identity on the distributed ledger, identify the merchant public key therefrom, and use the merchant public key to validate the digital signature on the URN and transaction amount; the digital signature will only be successfully validated using the merchant public key if the merchant system 104 uses the corresponding merchant private key, thus authenticating the merchant system 104. In such an example, each entity in the system 100 can verify the identity of any other entity in the system 100 using the distributed ledger. If the identities are contained in a dataset stored on the blockchain, each entity can verify the identity of every other entity at any point in a payment transaction by extracting the identities from the dataset and verifying them as described above.

[0053] In some cases, one or more entities may perform identity verification on behalf of another entity in the system 100. For example, the issuer system 104 may be configured to perform identity verification on behalf of the user device 102, and the user device 102 may forward a digital signature and / or identity from the merchant system 106 to the issuer system 104. The issuer system 104 may validate the identity of the merchant system and provide the results of the validation to the user device 102, which may use the validation as part of validating the data provided by the merchant system 104 before generating the first data set.

[0054] The use of a distributed ledger to store the identities of the entities involved in the system 100 provides yet another level of security, ensuring the authenticity of each participant in a payment transaction and significantly reducing the likelihood of fraud in any payment transaction due to the decentralized and immutable nature of the distributed ledger.

[0055] In some embodiments, communications transmitted electronically between entities in the system 100 may be encrypted. In such embodiments, an entity may encrypt data (e.g., a generated data set) before sending it, and the receiving entity may decrypt the data upon receipt and before verifying it. If the data set is digitally signed by the sending entity, a digital signature may be generated on the decrypted payload, or in some cases, on the encrypted payload, such that the data set may include the encrypted payload and the digital signature. By way of example, the acquirer system 106 may be configured to encrypt communications issued to the steward system 110, including the third data set. The acquirer system 106 may generate a random, temporary symmetric key, referred to in this disclosure as a session key. The acquirer system 106 may encrypt the payload of the third data set using the session key, and the acquirer system 106 may then encrypt the session key using the steward public key (e.g., derived from the steward system's identity on the distributed ledger). The acquirer system 106 can digitally sign the encrypted payload and the encrypted session key using the acquirer private key and send the entire package as a third data set to the steward system 110. The steward system 110 can validate the digital signature using the acquirer public key (e.g., derived from the acquirer system's identity on the distributed ledger), decrypt the session key using the steward private key, and decrypt the encrypted payload using the decrypted session key. In such an embodiment, the use of encryption can provide increased security with minimal additional functionality, and this is achieved because it uses existing key and identity information made available using the methods described above.

[0056] Computer Systems 2 illustrates an embodiment of a computing system 200. Those skilled in the art will appreciate that the embodiment of computing system 200 illustrated in FIG. 2 is provided for illustrative purposes only and is not an exhaustive list of all possible configurations of computing system 200 suitable for performing the functions of the present disclosure. For example, computer system 500 illustrated in FIG. 5 and described in more detail below may be a suitable configuration of computing system 200. In some cases, additional components of system 100 (e.g., user device 102, issuer system 104, merchant system 106, acquirer system 108, steward system 110, and blockchain node 114, etc.) may include the components illustrated in FIG. 2 and described below.

[0057] 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 user device 102, the issuer system 104, the merchant system 106, the acquirer system 108, the steward system 110, the blockchain node 114, 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, etc. In some embodiments, the receiving device 202 may include multiple devices (e.g., different receiving devices receiving data over different networks, e.g., a first receiving device receiving data over a local area network and a second receiving device receiving data over the Internet). The receiving device 202 may receive a transmitted electronic data signal, whereupon data may be superimposed on the data signal and decoded, parsed, read, or otherwise obtained upon receipt of the data signal by the receiving device 202. In some embodiments, the receiving device 202 may include an analysis module for analyzing the received data signal to obtain data superimposed thereon. For example, the receiving device 202 may include an analysis program configured to receive and convert the received data signal into usable input for functions performed by the processing device to implement the methods and systems of the present disclosure.

[0058] The receiving device 202 may be configured to receive a data signal electronically transmitted by a user device 102, an issuer system 104, a merchant system 106, an acquirer system 108, a steward system 110, and / or a blockchain node 114, which may be superimposed or encoded with an identity, a digital signature, a URN, a data set, transaction data, a transaction message, a notification message, a blockchain data value, blockchain data, a public key, a transaction identifier, a timestamp, etc.

[0059] Computing system 200 may include a communications module 204. Communications module 204 may be configured to transfer data between modules, engines, databases, memory, and other components of computing system 200 for use in performing the functions of the present disclosure. Communications module 204 may include one or more communication types and may use various communication methods for communication within the computing device. For example, communications module 204 may include a bus, a contact pin connector, wires, etc. In some embodiments, communications module 204 may also be configured to communicate between internal components of computing system 200 and external components of computing system 200 (e.g., an externally connected database, display device, input device, etc.). Computing system 200 may also include a processing unit. The processing unit may be configured to perform the functions of computing system 200 of the present disclosure, as would be apparent to one skilled in the art. In some embodiments, the processing unit may include multiple engines and / or modules (e.g., query module 216, generation module 218, verification module 220, encryption module 222, etc.) specifically configured to perform one or more functions of the processing unit. As used herein, the term "module" may refer to software or hardware that is specifically programmed to receive input, perform one or more operations using the input, and provide an output. The inputs, outputs, and operations performed by the various modules will be apparent to one of ordinary skill in the art based on this disclosure.

[0060] 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 a suitable data storage format and schema. The account database 206 may be a relational database using a structured query language to store, identify, modify, update, access, etc., the stored structured data sets. Each account profile 208 may be a structured data set configured to store data related to an account for an entity. For example, the issuer system 104 or the acquirer system 108 may store an account profile 208 related to a transaction account, which may include an account number, a payment token, a balance, a transaction history, etc. In another example, the merchant system 106 may store an account profile 208 related to a consumer's account transacting with an associated merchant, including an account for a user device 102 in the system 100, which may include the consumer's identity, a user public key, a loyalty or reward number, a transaction history, etc.

[0061] The computing system 200 may also include blockchain data 210, which may be stored in the memory 214 of the processing server 102 or stored in a separate area within or accessible by the computing system 200. The blockchain data 210 may include a blockchain, which may comprise multiple blocks, and which may be associated with the blockchain network 112. In some cases, the blockchain data 210 may further include any other data associated with the blockchain and its management and performance, including, for example, block generation algorithms, digital signature generation and confirmation algorithms, communication data for the blockchain nodes 114, smart contracts, etc. The blockchain data 210 may also include data used by the computing system 200 for operations associated with the blockchain, including, for example, cryptographic key pairs for blockchain wallets, public keys for generating destination addresses or validating digital signatures, etc.

[0062] Computing system 200 may also include memory 214. Memory 214 may be configured to store data (e.g., public keys, private keys, symmetric keys, etc.) for use by computing system 200 in performing the functions of the present disclosure. Memory 214 may be configured to store data using any suitable data formatting methodology and schema and may be any suitable type of memory (e.g., read-only memory, random-access memory, etc.). Memory 214 may include, for example, cryptographic keys and algorithms, communication protocols and standards, data formatting standards and protocols, program code for modules and processing unit application programs, and other suitable data used by computing system 200 in performing the functions of the present disclosure. This will be apparent to those skilled in the art upon reading this disclosure. In some embodiments, memory 214 may include a relational database using Structured Query Language (SQL) to store, identify, modify, update, access, etc., stored structured data sets. The memory 214 may be configured to store, for example, cryptographic keys, cryptographic key pairs, cryptographic algorithms, encryption algorithms, communication information, data formatting rules, transaction message formatting rules, network identifiers, fee data, and the like.

[0063] The computing system 200 may also include a query module 216. The query module 216 may be configured to run queries on a database to identify information. The query module 216 may receive one or more data values ​​or query strings, and based thereon, may run the query string on an indicated database (e.g., the entity database 206 of the computing system 200) to identify information stored therein. The query module 216 may then output the identified information to an appropriate engine or module of the computing system 200 as needed. The query module 216 may, for example, run queries on the memory 214 to identify URNs and associated public keys to validate a received data set or to generate a new data set.

[0064] Computing system 200 may include a generation module 218. Generation module 218 may be configured to generate data for use by computing system 200 in performing the functions of the present disclosure. Generation module 218 may receive instructions as input, generate data based on the instructions, and output the generated data to one or more modules of computing system 200. For example, generation module 218 may be configured to generate data sets, digital signatures, transaction messages, notification messages, transaction identifiers, new encryption keys, session keys, etc.

[0065] Computing system 200 may include a validation module 220. Validation module 220 may be configured to perform validation on computing system 200 as part of the functionality of the present disclosure. Validation module 220 may receive instructions as input, which may include data used to perform the validation, perform the validation as requested, and output the results of the validation to another module or engine of computing system 200. Validation module 220 may be configured, for example, to verify a digital signature using an appropriate signature generation algorithm and key, verify a hash value by hashing provided data using an appropriate one-way hashing algorithm, verify a fee amount, verify an entity's identity using a public key and blockchain data, verify transaction data in a dataset, etc.

[0066] Computing system 200 may include encryption module 222. Encryption module 222 may be configured to perform encryption and decryption as part of the functionality described above for computing system 200. Encryption module 222 may receive instructions as input, which may also include data to be encrypted or decrypted, may perform encryption or decryption as requested, and may output the results of the encryption or decryption operations to another module or engine of computing system 200. Encryption module 222 may be configured, for example, to encrypt a generated data set before transmission or to decrypt a received encrypted data set.

[0067] The computing system 200 may also include a transmitting device 224. The transmitting device 224 may be configured to transmit data over one or more networks via one or more network protocols. In some examples, the transmitting device 224 may be configured to transmit data to the user device 102, the issuer system 104, the merchant system 106, the acquirer system 108, the steward system 110, the blockchain node 114, and other entities via one or more communication methods, such as a local area network, a wireless area network, cellular communication, Bluetooth, radio frequency, the Internet, etc. In some embodiments, the transmitting device 224 may include multiple devices (e.g., different transmitting devices for transmitting data over different networks (e.g., a first transmitting device transmitting data over a local area network and a second transmitting device transmitting data over the Internet)). The transmitting device 224 may electronically transmit a data signal with the superimposed data, the data being analyzed by a receiving computing device. In some embodiments, the transmitting device 224 may include one or more modules for superimposing, encoding, or shaping data into a data signal suitable for transmission.

[0068] The transmitting device 224 may be configured to electronically transmit a data signal to the user device 102, the issuer system 104, the merchant system 106, the acquirer system 108, the steward system 110, and / or the blockchain node 114, which may be superimposed or encoded with an identity, a digital signature, a URN, a data set, transaction data, a transaction message, a notification message, a blockchain data value, blockchain data, a public key, a transaction identifier, a timestamp, etc.

[0069] Decentralized and digital surrogate payment processing FIG. 3 illustrates a process 300 for processing payment transactions in system 100, where payment tokens are utilized instead of actual payment credentials and transaction datasets are stored in a distributed ledger.

[0070] At S302, a user of the user device 102 can use its input module to select a payment method to be used for the upcoming payment transaction. At S304, the user device 102 can electronically transmit a token request to the issuer system 104 using an appropriate communications network and method (e.g., via the sending device 224), for example, via an application program executed by the user device 102 associated with the issuer system 104. The token request can include at least an identifier associated with a transaction account selected by the user of the user device 102. In some cases, the token request can be digitally signed by the user device 102 using the user's private key. The issuer system 104 can receive the token request (e.g., via the receiving device 202) and, if signed, can validate the digital signature (e.g., via the verification module 220) using the user's public key (e.g., received in a previous onboarding process, obtained from a distributed ledger of identities, etc.).

[0071] Once validated, the issuer system 104 can identify (e.g., via query module 216) an account profile (e.g., account profile 208) associated with the transaction account selected by the user device 102 and indicated in the token request, and can generate (e.g., via generation module 218) a new payment token for the transaction account, the payment token including at least a URN that includes an identifier associated with the issuer system 104. The issuer system 104 (e.g., via generation module 218) can digitally sign the payment token using the issuer private key, and at S308 can electronically transmit the signed payment token to the user device 102 (e.g., via sending device 224) for receipt (e.g., via receiving device 202). In some embodiments, upon receipt, the user device 102 can validate (e.g., via verification module 220) the digital signature of the payment token.

[0072] At S310, the user device 102 may generate TX1 (e.g., via the generation module 218) as a first data set for a new payment transaction. TX1 may include at least a payload comprising a signed payment token, a timestamp, a transaction identifier, a transaction amount, and a URN for the merchant system 106 ("merchant URN"), and a digital signature on the payload generated by the user device 102 (e.g., via the generation module 218) using the user's private key. The transaction identifier, transaction amount, and merchant URN may be entered into the user device 102 by its user, received from the merchant system 106, or obtained using other suitable methods. At S312, the user device 102 may transmit TX1 to the merchant system 106 (e.g., via the transmission device 224) using an appropriate communications network and method. The merchant system 106 can receive TX1 (e.g., via receiving device 202), verify the transaction identifier, transaction amount, and merchant URN as equal to expected values ​​(e.g., via validation module 220), and validate the digital signature on the payload using the user public key (e.g., obtained from a distributed ledger of identities, the consumer's account profile, etc.).

[0073] At S314, the merchant system 106 may generate TX2 (e.g., via the generation module 218) as a second data set for the payment transaction. TX2 may include at least a payload comprising a timestamp, a transaction identifier, signed payment credentials for the merchant's transaction account at the acquirer system 108, a URN for the acquirer system 108 ("acquirer URN"), fee data, TX1, and a digital signature on the payload generated by the merchant system 106 (e.g., via the generation module 218) using the merchant private key. At S316, the merchant system 106 may transmit TX2 to the acquirer system 108 (e.g., via the transmitting device 224) using an appropriate communications network and method. The acquirer system 108 may receive TX2 (e.g., via the receiving device 202), may verify the transaction identifier, acquirer URN, and fee data as equal to expected values ​​(e.g., via the validation module 220), may validate the digital signature on the merchant's payment credentials using the acquirer public key, and may validate the digital signature on the payload using the merchant public key (e.g., obtained from a distributed ledger of identities, an account profile on the merchant system 106, etc.).

[0074] At S318, the acquirer system 108 may generate TX3 (e.g., via the generation module 218) as a third data set for the payment transaction. TX3 may include at least a payload comprising a timestamp, a transaction identifier, the acquirer URN, a URN for the steward system 110 ("steward URN"), fee data, and TX2, and a digital signature on the payload generated by the acquirer system 108 (e.g., via the generation module 218) using the acquirer private key. At S320, the acquirer system 108 may electronically transmit the generated TX3 to a blockchain node 114 in the blockchain network 112 (e.g., via the sending device 224) for writing thereto to the blockchain in a blockchain data value that is confirmed and included in a new block added to the blockchain. At S322, the acquirer system 108 may transmit TX3 to the steward system 110 (e.g., via the sending device 224) using an appropriate communication network and method. The steward system 110 can receive TX3 (e.g., via the receiving device 202), and can verify the transaction identifier, steward URN, and fee data as equal to expected values ​​(e.g., via the validation module 220), and can validate the digital signature on the payload using the acquirer public key (e.g., obtained from a distributed ledger of identities, an account profile at the acquirer system 108, etc.).

[0075] At S324, the steward system 110 can generate TX4 (e.g., via the generation module 218) as a fourth data set for the payment transaction. TX4 can include at least a payload comprising a timestamp, a transaction identifier, a steward URN, a URN for the issuer system 104 ("issuer URN"), TX3, and a digital signature on the payload generated by the steward system 110 (e.g., via the generation module 218) using the steward private key. At S326, the steward system 110 can electronically transmit the generated TX4 to a blockchain node 114 in the blockchain network 112 (e.g., via the sending device 224) for writing thereto to the blockchain in a blockchain data value that is confirmed and included in a new block that is added to the blockchain. At S328, the steward system 110 can transmit TX4 to the issuer system 104 (e.g., via the sending device 224) using an appropriate communication network and method. The issuer system 104 can receive TX4 (e.g., via receiving device 202), can verify the transaction identifier, issuer URN, and fee data as equal to expected values ​​(e.g., via validation module 220), can use the issuer public key to validate the digital signature on the user's payment token in TX1, and can use the steward public key (e.g., obtained from a distributed ledger of identities, an account profile in steward system 110, etc.) to validate the digital signature on the payload.

[0076] At S330, the issuer system 104 (e.g., in the account database 206) can identify (e.g., via the account profile 208) the transaction account that will be used to fund the payment transaction if approved, based on the URN included in the payment credentials included in the TX1 portion of the TX4 payload. At S332, the issuer system 104 can determine that the payment transaction is approved based, for example, on the transaction amount included in the TX1 payload being less than the available balance or available credit for the identified transaction account and other transaction data complying with any applicable transaction restrictions.

[0077] At S334, the issuer system 104 can generate TX5 (e.g., via the generation module 218) as a fifth data set for the payment transaction. TX5 can include at least a payload comprising a timestamp, a transaction identifier, the issuer URN, the steward URN, an authorization for the payment transaction, and TX4, and a digital signature on the payload generated by the issuer system 104 (e.g., via the generation module 218) using the issuer private key. At S336, the issuer system 104 can, and does, electronically transmit the generated TX5 to a blockchain node 114 in the blockchain network 112 (e.g., via the sending device 224) for writing thereto to the blockchain in a blockchain data value that is confirmed and included in a new block added to the blockchain. At S338, the issuer system 104 can transmit TX4 to the steward system 110 (e.g., via the sending device 224) using an appropriate communication network and method. The steward system 110 can receive TX4 (e.g., via the receiving device 202), can verify the transaction identifier, steward URN, and authorization as equal to expected values ​​(e.g., via the validation module 220), and can validate the digital signature on the payload using the issuer public key (e.g., obtained from a distributed ledger of identities, an account profile on the issuer system 104, etc.).

[0078] At S340, the steward system 110 can generate TX6 (e.g., via the generation module 218) as a sixth data set for the payment transaction. TX6 can include at least a payload comprising a timestamp, a transaction identifier, the issuer URN, the steward URN, the acquirer URN, a state for the payment transaction, and TX5, and a digital signature on the payload generated by the steward system 110 (e.g., via the generation module 218) using the steward private key. At S342, the steward system 110 can electronically transmit the generated TX6 to a blockchain node 114 in the blockchain network 112 (e.g., via the sending device 224) for writing thereto to the blockchain in a blockchain data value that is confirmed and included in a new block added to the blockchain. At S344, the steward system 110 can electronically transmit an endorsement message to the acquirer system 108 via an appropriate communication network and method. The approval message may include at least a transaction identifier and an indication that the payment transaction has been approved and successfully processed. The acquirer system 108 may receive the approval message (e.g., via the receiving device 202) and, at S346, may forward the approval message to the merchant system 106 (e.g., via the transmitting device 224) using an appropriate communications network and method. The merchant system 106 may receive the approval message (e.g., via the receiving device 202) and, at S348, may provide the goods purchased using the payment transaction to the consumer.

[0079] Exemplary Method for Pre-Authorization of Payment Transactions FIG. 4 illustrates a method 400 for pre-authorization of payment transactions using tokenized payment credentials.

[0080] At S402, a first data set may be received by a receiver (e.g., receiving device 202) of a processing server (e.g., steward system 110), where the first data set (e.g., TX3) is signed with a first digital signature and includes at least an acquirer identification value (e.g., acquirer URN) and a second data set (e.g., TX2). At S404, the first digital signature may be verified by a verification module (e.g., verification module 220) of the processing server using a first public key of a first cryptographic key pair associated with the acquirer identification value. At S406, a second data set may be extracted from the first data set in response to verifying the first digital signature, where the second data set includes at least a merchant identification value (e.g., merchant URN) and a third data set (e.g., TX1).

[0081] At S408, a third data set can be extracted from the second data set, the third data set including at least an issuer identification value (e.g., issuer URN, a second portion of the URN in the payment credential, etc.) and transaction data. At S410, an issuing computing system (e.g., issuer system 104) can be identified by a processor (e.g., query module 216) of the processing server based on at least the issuer identification value. At S412, a fourth data set (e.g., TX4) can be transmitted by a transmitter (e.g., sending device 224) of the processing server to the issuing computing system, the fourth data set including at least the first data set and a steward identification value (e.g., steward URN).

[0082] In one embodiment, method 400 may further include verifying, by a verification module of the processing server, that the acquirer value corresponds to the acquirer identification value before extracting the third data set, wherein the second data set further includes the acquirer value, and the third data set is extracted in response to verifying that the acquirer value corresponds to the acquirer identification value. In some embodiments, the first data set may be encrypted using a second public key of a second encryption key pair, and method 400 may further include decrypting the first data set by an encryption module of the processing server (e.g., encryption module 222) using the private key of the second encryption key pair. In one embodiment, method 400 may also include encrypting, by an encryption module of the processing server, the fourth data set using the issuer public key before transmission to the issuer computing system.

[0083] In some embodiments, the acquirer identification value, merchant identification value, issuer identification value, and steward identification value may each include at least an identifier and an associated public key. In further embodiments, each of the acquirer identification value, merchant identification value, issuer identification value, and steward identification value may be digitally signed using the private key of an identity encryption key pair that includes each associated public key. In one embodiment, the transaction data may include tokenized payment account data. In further embodiments, the tokenized payment account data may be digitally signed by the issuer computing system.

[0084] Computer System Architecture 5 illustrates a computer system 500, in which embodiments of the present disclosure, or portions thereof, may be implemented as computer-readable code. For example, the user device 102, issuer system 104, merchant system 106, acquirer system 108, steward system 110, and blockchain node 114 of FIG. 1 and the computing system 200 of FIG. 2 may be implemented in the computer system 500 using hardware, a non-transitory computer-readable medium having instructions stored thereon, or a combination thereof, and may be implemented in one or more computer systems or other processing systems. The hardware may embody modules and components used to implement the methods of FIGS. 3 and 4.

[0085] Where programmable logic is used, such logic may be executed on commercially available processing platforms configured with executable software code, resulting in special-purpose or dedicated devices (e.g., programmable logic arrays, application-specific integrated circuits (ASICs), etc.). Those skilled in the art will appreciate that embodiments of the disclosed subject matter may be implemented in a variety of computer system configurations, including multi-core, multi-processor systems, minicomputers, mainframe computers, distributed functionality linked or clustered computers, and general-purpose or miniature computers that may be implemented in virtually any device. For example, at least one processor unit and memory may be used to implement the embodiments.

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

[0087] Various embodiments of the present disclosure are described with respect to this exemplary computer system 500. After reading this disclosure, it will be apparent to one skilled in the art how to implement the present disclosure using other computer systems and / or computer architectures. While operations are disclosed as sequential processes, some operations may in fact be performed in parallel, concurrently, and / or in distributed environments, where program code is stored locally or remotely for access by uniprocessor or multiprocessor machines. Furthermore, in some embodiments, the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.

[0088] The processor unit 504 may be a special-purpose or general-purpose processor unit specially configured to perform the functions of the present disclosure. The processor unit 504 may be connected to a communications infrastructure 506 (e.g., a bus, a message queue, a network, a multi-core message passing scheme, etc.). The network may be any network suitable for performing the functions of the present disclosure and may include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., Wi-Fi), a mobile communications network, a satellite network, the Internet, fiber optics, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to those skilled in the art. The computer system 500 may also include a main memory 508 (e.g., random access memory, read-only memory, etc.) and may also include a secondary memory 510. The secondary memory 510 may include a hard disk drive 512 and a removable storage drive 514 (e.g., a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, etc.).

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

[0090] In some embodiments, secondary memory 510 may include alternative means for allowing computer programs or other instructions to be loaded into computer system 500 (e.g., 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, other removable storage units 522 and interfaces 520, as will be apparent to those skilled in the art.

[0091] Data stored in computer system 500 (e.g., in main memory 508 and / or secondary memory 510) may be stored on any type of suitable computer-readable medium, such as optical storage (compact disc, digital versatile disc, Blu-ray disc, etc.) or magnetic tape storage (e.g., hard disk drive). The data may be organized in any type of suitable database structure (e.g., a relational database, a Structured Query Language (SQL) database, a distributed database, an object database, etc.). Suitable structures and storage types will be apparent to those skilled in the art.

[0092] Computer system 500 may also include a communications interface 524. Communications interface 524 may allow software and data to be sent and received between computer system 500 and external devices. Exemplary communications interface 524 may include a modem, a network interface (e.g., an Ethernet card), a communications port, a PCMCIA slot and card, etc. The software and data transferred via communications interface 524 may be in the form of signals. The signals may be electronic, electromagnetic, optical, or other signals apparent to those skilled in the art. The signals propagate over communications path 526. The paths are configured to carry the signals and may be implemented using wire, cable, fiber optics, a telephone line, a cellular phone link, a radio frequency link, etc.

[0093] Computer system 500 may further include a display interface 502. Display interface 502 may be configured to allow data to be transferred between computer system 500 and an external display 530. Exemplary display interfaces 502 may include a high-definition multimedia interface (HDMI), a digital visual interface (DVI), a video graphics array (VGA), etc. Display 530 may be any suitable type of display that displays data transferred via display interface 502 of computer system 500, including a cathode ray tube (CRT) display, a liquid crystal display (LCD), a light-emitting diode (LED) display, a capacitive touch display, a thin-film transistor (TFT) display, etc.

[0094] The computer program medium and computer usable medium may refer to memory (e.g., main memory 508 and secondary memory 510), which may be semiconductor memory (such as DRAM). These computer program products may be means for providing software to computer system 500. Computer programs (e.g., computer control logic) may be stored in main memory 508 and / or secondary memory 510. Computer programs may also be received via communications interface 524. Such computer programs, when executed, may enable computer system 500 to perform methods of the present disclosure. In particular, computer programs, when executed, may enable processor unit 504 to implement the methods illustrated in FIGS. 3 and 4 as described herein. Such computer programs therefore represent the controller of computer system 500. The present disclosure is implemented using software. The software may be stored in a computer program product and loaded into computer system 500 using removable storage drive 514, interface 520, and hard disk drive 512 or communications interface 524.

[0095] The processor unit 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, or in some embodiments, software (e.g., corresponding to program code or programs stored in the main memory 508 or the secondary memory 510). In such embodiments, the program code may be compiled by the processor unit 504 (e.g., 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 written in a programming language (e.g., assembly language or machine code) that is translated into a lower-level language for execution by the processor unit 504 and / or any additional hardware components of the computer system 500. The compilation process may include the use of lexical analysis, preprocessing, syntactic analysis, semantic analysis, syntax-driven translation, code generation, code optimization, and any other techniques that may be suitable for translating the program code into a lower-level language suitable for controlling the computer system 500 to perform the functions of the present disclosure. Those skilled in the art will appreciate that such processing results in computer system 500 being a specially configured computer system 500 that is uniquely programmed to perform the functions described above.

[0096] Although other approaches are possible consistent with the present disclosure, systems and methods are provided for pre-authorizing payment transactions using tokenized credentials. While various exemplary embodiments of the disclosed systems and methods are described above, it should be understood that they are presented by way of example only, and not by way of limitation. They are not exhaustive and do not limit the disclosure to the precise form disclosed. Modifications and variations are possible in light of the above teachings. Modifications and variations may be obtained from implementations of the present disclosure without departing from the scope or spirit of the disclosure.

Claims

1. 1. A method for pre-authorization of a payment transaction using tokenized credentials, comprising: receiving, by a receiver of a processing server, a first data set, said first data set being signed with a first digital signature and including at least an acquirer identification value and a second data set; verifying, by a verification module of the processing server, the first digital signature using a first public key of a first cryptographic key pair associated with the acquirer identification value; extracting the second data set from the first data set in response to verifying the first digital signature, the second data set including at least a merchant identification value and a third data set; extracting the third data set from the second data set, the third data set including at least an issuer identification value and transaction data; identifying, by a processor of the processing server, an issuer computing system based at least on the issuer identification value; transmitting, by a transmitter of the processing server, a fourth data set to the issuer computing system, the fourth data set including at least the first data set and a steward identification value.

2. The method of claim 1 further comprising: verifying, by the verification module of the processing server, that an acquirer value corresponds to the acquirer identification value before extracting the third data set; the second data set further includes the acquirer value; The method, wherein the third data set is extracted in response to verifying that the acquirer value corresponds to the acquirer identification value.

3. 10. The method of claim 1, the first data set is encrypted using a second public key of a second encryption key pair; The method further comprises: decrypting, by an encryption module of the processing server, the first data set using a private key of the second encryption key pair.

4. The method of claim 1 further comprising: encrypting, by an encryption module of the processing server, the fourth data set with a public key of the issuer computing system before transmission to the issuer computing system.

5. 10. The method of claim 1, wherein the acquirer identification value, the merchant identification value, the issuer identification value, and the steward identification value each include at least an identifier and an associated public key.

6. 6. The method of claim 5, wherein each of the acquirer identification value, the merchant identification value, the issuer identification value, and the steward identification value is digitally signed using a private key of an identity encryption key pair that includes each of the associated public keys.

7. 10. The method of claim 1, wherein the transaction data comprises tokenized payment account data.

8. 8. The method of claim 7, wherein the tokenized payment account data is digitally signed by the issuer computing system.

9. 1. A system for pre-authorization of payment transactions using tokenized credentials, comprising: an issuer computing system; a processing server, the processing server comprising: a receiver for receiving a first data set, the first data set being signed with a first digital signature and including at least an acquirer identification value and a second data set; a verification module that verifies the first digital signature using a first public key of a first cryptographic key pair associated with the acquirer identification value; 1. A processor, comprising: extracting the second data set from the first data set in response to verifying the first digital signature, the second data set including at least a merchant identification value and a third data set; extracting the third data set from the second data set, the third data set including at least an issuer identification value and transaction data; identifying an issuer computing system based at least on the issuer identification value; a transmitter for transmitting a fourth data set to the issuer computing system, the fourth data set including at least the first data set and a steward identification value.

10. 10. The system of claim 9, the validation module of the processing server verifies that an acquirer value corresponds to the acquirer identification value before extracting the third data set; the second data set further includes the acquirer value; The system, wherein the third data set is extracted in response to verifying that the acquirer value corresponds to the acquirer identification value.

11. 10. The system of claim 9, the first data set is encrypted using a second public key of a second encryption key pair; The system, wherein the processing server further includes an encryption module that decrypts the first data set using a private key of the second encryption key pair.

12. 10. The system of claim 9, wherein the processing server further comprises an encryption module that encrypts the fourth data set with a public key of the issuer computing system before transmission to the issuer computing system.

13. 10. The system of claim 9, wherein the acquirer identification value, the merchant identification value, the issuer identification value, and the steward identification value each include at least an identifier and an associated public key.

14. 14. The system of claim 13, wherein each of the acquirer identification value, the merchant identification value, the issuer identification value, and the steward identification value is digitally signed using a private key of an identity encryption key pair that includes each of the associated public keys.

15. 10. The system of claim 9, wherein the transaction data includes tokenized payment account data.

16. 16. The system of claim 15, wherein the tokenized payment account data is digitally signed by the issuer computing system.

Images