Method and system for payment processing using distributed digital substitutes

Abstract

A method for pre-authorization of payment transactions by means of tokenized credentials, comprising: receiving a first data set signed with a first digital signature and comprising 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 a second data set including a merchant identification value and a third data set from the first data set in response to verification of the first digital signature; extracting a third data set comprising an issuer identification value and transaction data from the second data set; identifying an issuing computing system based on the issuer identification value; and transmitting a fourth data set to the issuing computing system, the fourth data set including the first data set and the steward identification value.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of and priority to U.S. Patent Application No. 17 / 876,140, ​​filed on July 28, 2022. The entire disclosure of the above application is incorporated herein by reference. Technical Field

[0003] The present disclosure relates to payment processing using distributed digital alternatives, and more particularly to pre-authorization of payment transactions using tokenized credentials. Background Art

[0004] In modern times, consumers often digitize their payment cards for security and convenience. Digitization typically involves the creation of a digital token that is used in place of standard payment credentials used to pay for an account, where the consumer presents the digital token in place of a traditional payment card when making a payment transaction. The payment token is added to the transaction message transmitted across the payment rails and as part of the payment processing, it is replaced with the standard payment credential by a token service provider. The token service provider is often the payment network that processes the transaction on its rails, or may be a third-party provider associated with it.

[0005] Payment tokens are often stored on mobile devices, such as smart phones or smart watches, to provide convenience to consumers. Many consumers are interested in the additional security that payment tokens can provide, as the actual payment credentials are not stored on the consumer's device, which can provide additional security if the device is stolen or the transmission is intercepted. However, in the current system, payment tokens are distributed by token service providers who must participate in the payment transaction and perform de-tokenization, thereby providing opportunities for the theft or interception of the actual payment credentials. Therefore, there is a need for improved payment processing systems to provide complete privacy of the actual payment credentials when using digital payment instruments. Summary of the invention

[0006] The present disclosure provides a description of a system and method for pre-authorization of payment transactions with tokenized credentials. The system includes several entities, each entity having its own unique identifier for verification by all other entities in the system. A consumer using its computing device submits its credentials and a payment token issued directly to it by the issuer of the associated payment account to a merchant in a first data set. The merchant attaches its credentials to the first data set to create a second data set, which is forwarded to the merchant's acquirer. The acquirer attaches its credentials to the second data set to create a third data set, which is forwarded to a steward (such as a payment processor). The steward attaches its credentials 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 attaches its own credentials to a fifth data set including the fourth data set and authorization for the transaction, which is sent back to the steward. The steward generates a sixth data set including the fifth data set and any completion information (such as status, steward's credentials, etc.). The sixth data set is written to a distributed ledger, such as a blockchain, along with other data sets generated throughout the process. The result is a transaction that can be fully verified at each step, in which each entity involved can be individually verified by each other entity, and in which no entity other than the issuer of the transaction account has access to the true payment credentials, thereby providing significantly greater security for consumers without sacrificing convenience. In some cases, the credentials of each entity may also be stored on a distributed ledger (such as a blockchain) to provide even greater security in verifying the entities involved in the transaction. The result is a system that is overall more secure and trustworthy than what is traditionally available.

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

[0008] A system for pre-authorizing payment transactions with the aid of tokenized credentials, comprising: an issuing computing system; and a processing server, the processing server comprising a receiver, the receiver receiving a first data set, wherein the first data set is signed with a first digital signature and includes at least an acquirer identification value and a second data set; a verification module, the verification module using a first public key of a first cryptographic key pair associated with the acquirer identification value to verify the first digital signature; a processor, the processor extracting a second data set from the first data set in response to verification of the first digital signature, wherein the second data set includes at least a merchant identification value and a third data set; extracting a third data set from the second data set, wherein the third data set includes at least an issuer identification value and transaction data; and identifying the issuing computing system based at least on the issuer identification value; and a transmitter, the transmitter transmitting a fourth data set to the issuing computing system, wherein the fourth data set includes at least the first data set and a steward identification value. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The scope of the present disclosure can be best understood from the following detailed description of exemplary embodiments when read in conjunction with the accompanying drawings, which include the following figures:

[0010] Figure 1 is a block diagram illustrating a high-level system architecture for payment processing using a distributed digital alternative according to an exemplary embodiment.

[0011] Figure 2 is a diagram illustrating a method of Figure 1 Block diagram of a computing system that uses distributed digital alternatives for payment processing in a system.

[0012] Figure 3 is a diagram illustrating a method of Figure 1 Flowchart of a process for payment processing using distributed digital alternatives in a system.

[0013] Figure 4 is a flow chart illustrating an exemplary method for pre-authorization of a payment transaction via tokenized credentials according to an exemplary embodiment.

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

[0015] Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter.It should be understood that the detailed description of the exemplary embodiments is for illustrative purposes only and is therefore not intended to necessarily limit the scope of the present disclosure. DETAILED DESCRIPTION

[0016] A system for payment processing using distributed digital alternatives

[0017] Figure 1 A system 100 for processing payment transactions using distributed digital substitutes (such as payment tokens) is illustrated, where transaction data and identity data may be stored in a distributed ledger (such as a blockchain).

[0018] System 100 may include user device 102. User device 102 may be any type of computing device suitable for performing the functions discussed herein, such as Figure 2 or Figure 5 1 and discussed in more detail below, which may include a desktop computer, a notebook computer, a laptop computer, a tablet computer, a cellular phone, a smart phone, a smart watch, a smart television, a wearable computing device, an implantable computing device, etc. The user device 102 may be owned by a consumer or otherwise associated with a consumer. As used herein, the user device 102 may refer to the user device 102 itself or to an associated consumer. The consumer may have a transaction account issued to it by an issuing financial institution, where the issuing financial institution is represented in the system 100 by the issuer system 104, which may refer to the issuing financial institution itself or one or more computing systems thereof, which may be associated with the issuing financial institution. Figure 2 and Figure 5 The same computing system shown in and discussed in more detail below.

[0019] To utilize the system 100, a consumer may use a user device 102 to request that an issuer system 104 issue it a payment token for a particular transaction account. The token may be requested using any suitable method or interface, such as via an application or webpage associated with the issuer system 104, which may be used by the user device 102, which is a customer of the issuing financial institution. The issuer system 104 may authenticate the user device 102, such as using the methods discussed below or using a conventional authentication process, and may generate a payment token for the selected transaction account. The payment token may be a digital value that represents and is uniquely associated with a transaction account. In an exemplary embodiment, the payment token may be generated such that the transaction account cannot be identified using the payment token without prior knowledge of the transaction account.

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

[0021]

[0022] As referred to herein, a "URN" is a unique value that can be generated by any suitable entity using any suitable format. In the above example, the issuer system 104 can generate a URN where the first portion before the ":" can be a substitute 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 of transaction messages including the above payment credentials. The value of "exp" can be the expiration date of the credential. The signature can be a digital signature generated for the credential, such as on a combination of the URN and the expiration date, which combination can be generated using a private key of a cryptographic key pair (referred to herein as the "issuer private key" and the "issuer public key") of the issuer system 104.

[0023] 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 its appropriate memory. After the user device 102 receives the payment token, the user device 102 may be ready to participate in a payment transaction funded using a transaction account associated with the payment token.

[0024] In system 100, each entity involved may have a credential associated with it, which is also referred to herein 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 an entity. In some cases, an identity may also 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 an entity using a private key of an associated cryptographic key pair of the entity. In some cases, an identity may be digitally signed by a different entity, such as an entity that can vouch for the identity of an entity. For example, an issuer system 104 may digitally sign the identity of a user device 102 using its own issuer private key.

[0025] In the example, the identity can be of the following format:

[0026]

[0027] In the example above, "publicKey" is a representation of an RSA public key, where the signature is generated using the corresponding RSA private key. In system 100, a first entity can provide its identity to a second entity, where the second entity can verify the digital signature and compare the URN with the expected URN to verify 305 that the first entity is the entity it claims to be. For example, a user device 102 can provide its identity to an 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 so that the user device 102 can verify that it is communicating with the correct issuer system 104 and not a fraudulent actor. In some embodiments, the entity identity can be stored in a distributed ledger (such as a blockchain), as discussed in more detail below. If the verification of the identity fails, the user device 102 or the issuer institution system 104 can refuse to further participate in the processing discussed herein (when applicable).

[0028] In system 100, when a user device 102 is interested in using its payment token to conduct a payment transaction, the user device 102 may communicate with a merchant system 106 using a suitable communication network and method. The merchant system 106 may be a computing system such as Figure 2 and Figure 5 1 and discussed in more detail below, the computing system is configured to perform the functions discussed herein on behalf of the merchant. As discussed herein, merchant system 106 may refer to a system of an associated merchant or the merchant itself.

[0029] The user device 102 and the merchant system 106 may communicate and agree on the terms of the payment transaction, such as the transaction amount. The user device 102 may generate a first data set for the payment transaction, referred to herein as TX1. The first data set may include at least transaction data for the payment transaction, a payment credential, and a digital signature generated on the payload of the first data set (e.g., transaction data and payment credential) using a private key of a cryptographic key pair of the user device 102 (referred to herein as a user private key and a user public key). In an example, TX1 may be in the following format:

[0030] {

[0031] "payload":{

[0032] "tx-id":"731cdaa8-3245-11ec-8d3d-0242ac130003",

[0033] "amount":100.00,

[0034] "datetime":"20-12-2022T08:10:00",

[0035]

[0036] 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 transmitted to the user device 102 using a suitable communication network and method. The "amount" value may refer to the transaction amount of the payment transaction to be paid from the transaction account of the user device to the transaction account associated with the merchant. The value "datetime" may be the time and date when the transaction occurred, which may be a timestamp when TX1 was generated or a future time when the transaction is to be processed. The value "tx-receiver-urn" 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 amount and transaction identifier) ​​to the user device 102 via a quick response code or other machine-readable code, which may be read by the user device 102 and the URN and other transaction data may be extracted therefrom.

[0037] 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 prior to generating the first data set, such as to ensure that payment is being made to the correct entity. If the merchant system 106 fails the verification, the user device 102 may refuse to further participate in the payment transaction. Once the first data set is generated and the user device 102 authenticates the merchant system 106 (if applicable), the user device 102 may electronically transmit the generated first data set to the merchant system 106 using a suitable communication network and method, such as via an application or webpage of the merchant system 106, using near field communication, Bluetooth or other transmission protocols, via a quick response code, etc.

[0038] The merchant system 106 may receive the first data set and verify the data included therein, such as verifying whether the transaction amount, transaction identifier, and merchant URN are correct. The merchant system 106 may also verify the digital signature on the payment voucher using the public key of the issuer (e.g., provided by the issuer system 104, such as in a distributed ledger, discussed in more detail below), and verify the digital signature on the payload using the public key of the user device. If the user device 102 provides its identity, the merchant system 106 may also verify the identity of the user using the methods discussed herein. If any verification fails, the merchant system 106 may reject the payment transaction and stop the processing. Once the first data set is successfully verified, the merchant system 106 may generate a second data set for the payment transaction, referred to herein as TX2. The second data set may include at least the first data set and the URN of the acquirer for the merchant. In some cases, the second data set may also include payment vouchers for the merchant, such as may be associated with a transaction account selected by the merchant system 106 for receiving funds for the payment transaction paid from the user device 102. In an example, TX2 may be in the following format:

[0039] {

[0040] "payload":{

[0041] "datetime":"20-12-2022T08:10:00",

[0042] "tx-id":"731cdaa8-3245-11ec-8d3d-0242ac130003",

[0043] "accepted-mdr":"2.0%",

[0044] "credential":{

[0045] "token":{

[0046] "urn":"3403e19a-3232-11ec-8d3d-0242ac130003:c9eb1c08-322e-

[0047]

[0048] In the above example, "TX1" refers to the example of TX1 above, the entire contents of which may be included in TX2, but are not shown above for readability. The "accepted-mdr" value may be a merchant discount rate, which may be applicable to the payment transaction, as is clear to one of ordinary skill in the art. In this example, the payload may be digitally signed using the private key of the merchant system's cryptographic key pair (referred to herein as the merchant private key and the merchant public key).

[0049] Once the merchant system 106 generates and signs the second data set, 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 associated with an acquiring financial institution that issues a transaction account to the merchant system 106, such as discussed in more detail below. Figure 2 and Figure 5 As shown in , the merchant system 106 is specified in the second data set for receiving payment in the payment transaction being processed. As referred to herein, the acquirer system 108 may refer to a computing system associated with an acquiring financial institution or the acquiring financial institution itself.

[0050] The acquirer system 108 can receive the second data set and can perform verification of the second data set. The verification can include verifying the payment credentials provided by the merchant system 106 in the payload for the second data set, verifying the payment credentials of the user device included in the TX1 portion of the second data set, verifying one or more of the digital signatures in the second data set using the appropriate public key, and (if applicable) verifying the merchant identity and / or the user identity (if included in the second data set). If the verification is unsuccessful, the acquirer system 108 can deny the payment transaction and return a message to the merchant system 106 accordingly, wherein the merchant system 106 can notify the consumer that the transaction was denied. If the verification is successful, the acquirer system 108 can generate a third data set for the payment transaction, also referred to herein as TX3. The third data set can include the second data set as well as the URN of the acquirer (e.g., identity, if applicable), as well as any additional transaction data, and in some cases, the URN of the next entity involved in processing the payment transaction, which next entity is in Figure 1 In the example shown in , it can be the housekeeper system 110. In the example, TX3 can be in the following format:

[0051]

[0052] In the above example, "TX2" refers to the example of TX2 described above, the entire contents of which may be included in TX3, but are not shown above for readability. "urn" is the URN of the acquirer system 108, which matches the "acquirer-urn" in TX2. "steward-urn" is the URN of the steward system 110 that is the next recipient in the payment transaction processing. The "steward-fee" and "issuer-interchange-fee" values ​​are the fees for payment transaction processing, whose values ​​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 cryptographic key pair of the acquirer system 108 (referred to herein as the acquirer private key and the acquirer public key).

[0053] Once the third data set has been generated and signed by the acquirer system 108, the acquirer system 108 may electronically transmit the third data set to the steward system 110. The steward system 110 may be a computing system such as Figure 2 and Figure 5 1 and discussed in more detail below, which performs pre-authorization processing for payment transactions on behalf of other entities, such as issuer system 104. In some embodiments, steward system 110 can be part of issuer system 104 or acquirer system 108, where issuer system 104 or acquirer system 108, respectively, performs the functions of steward system 110, as discussed herein. In some cases, steward system 110 can be part of a payment network associated with a payment rail used to transmit data sets in system 100.

[0054] The steward system 110 may receive the third data set from the acquirer system 108 and may verify the data included in the third data set. For example, the steward system 110 may verify whether the included "steward-urn" value matches its URN, may verify the value of the fee included in the payload of the third data set, may verify the data included in the TX2 or TX1 portion of the third data set (as discussed above), and verify the digital signature of the third data set using the acquirer public key. In the event that the acquirer system 108 includes its identity in the third data set, the steward system 110 may also verify the identity of the acquirer system 108. If any verification fails, the steward system 110 may reject the payment transaction and transmit a message to the acquirer system 108 accordingly to stop the processing of the payment transaction.

[0055] If the verification is successful, then the butler system 110 may generate a fourth data set for the payment transaction, referred to herein as TX4. The fourth data set may include the third data set and the URN of the butler system. The fourth data set may also include the URN of the issuer system 104 as the next recipient of the data set as part of the processing of the payment transaction. In an example, TX4 may be in the following format:

[0056]

[0057] In the above example, "TX3" refers to the example of TX3 above, the entire contents of which may be included in TX4, but are not shown above for readability. "urn" is the URN of the steward system 110, which matches the "steward-urn" in TX3. "issuer-urn" is the URN of the issuer system 104 that is the next recipient in the payment transaction processing. The payload of TX4 may be digitally signed using the private key of the cryptographic key pair of the steward system 110 (referred to herein as the steward private key and the steward public key).

[0058] Once the fourth data set is generated, steward system 110 may use a suitable communication network and method to electronically transmit the signed fourth data set to issuer system 104. In the event that steward system 110 may perform pre-authorization processing for multiple issuing financial institutions, steward system 110 may use the payment credential included in TX1 in the fourth data set to identify issuer system 104, where in the above example, the second portion of the URN in the credential is uniquely associated with issuer system 104.

[0059] The issuer system 104 may receive the fourth data set from the steward system 110 and verify the fourth data set and the data included therein. The verification of the fourth data set may include verifying whether 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. In the case where the steward system 110 includes its identity in the fourth data set, the issuer system 104 may also verify the identity of the steward system 110 using the process discussed above. If any verification fails, the issuer system 104 may reject the payment transaction and return a message to the steward system 110 accordingly to forward to the acquirer system 108 and ultimately to the merchant system 106. In some cases, the issuer system 104 may electronically transmit a notification message to the user device 102 indicating that the payment transaction was rejected, such as notifying the user device 102 in the event that a malicious actor attempts to use a transaction account associated with the user device 102.

[0060] If the fourth data set is successfully verified, the issuer system 104 can use the first part 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 use conventional methods to determine whether the payment transaction should be approved or rejected, such as ensuring that the balance of the transaction account covers the amount of the payment transaction, the transaction complies with any controls on the transaction account, etc. If the transaction is rejected for processing, the issuer system 104 can electronically transmit a notification to the steward system 110 and / or the user device 102, as discussed above.

[0061] If the payment transaction is approved, the issuer system 104 may deduct the amount from the user's transaction account accordingly and generate a fifth data set for the payment transaction, also referred to herein as TX5. The fifth data set may include the fourth data set as well as the URN of the issuer, the URN of the steward system 110, and an indication of the result of the authorization process by the issuer system 104. In an example, TX5 may be in the following format:

[0062]

[0063]

[0064] In the above example, "TX4" refers to the example of TX4 described above, the entire contents of which may be included in TX5, but are not shown above 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 system 110, which is the next recipient in the payment transaction processing, which matches the URN of TX4 and the "steward-urn" in TX3. The payload of TX5 can be digitally signed using the issuer private key. The "authorization" value indicates the result of the authorization processing of the issuer system, which in this example is the approval of the payment transaction. In some cases, the fifth data set does not need to include the signature of the issuer system 104 on the payload.

[0065] Once the fifth data set is generated and signed, the issuer system 104 may electronically transmit the signed fifth data set to the butler system 110 using a suitable communication network and method. The butler system 110 may verify the fifth data set, such as by verifying the included URN, authorization, and other data and signatures included therein (as discussed above), including verifying the signature for the payload of the fifth data set using the issuer public key. Upon successful verification of the fifth data set, the butler system 110 may generate a sixth data set, also referred to herein as TX6. The sixth data set may include the fifth data set as well as the URN of the butler system, the URN for the issuer system 104, the URN for the acquirer system 108, and an indication that the payment transaction has been completed. In an example, TX6 may be in the following format:

[0066] {

[0067] "payload":{

[0068] "urn":"abcccc08-322e-11ec-8d3d-0242ac130123:1233e19a-3232-11ec-8d3d-0242ac110101",

[0069] "datetime":"20-12-2022T08:10:00",

[0070] "tx-id":"731cdaa8-3245-11ec-8d3d-0242ac130003",

[0071] "status":"COMPLETED",

[0072] "issuer-urn":"abcccc08-322e-11ec-8d3d-0242ac130123:1233e19a-3232-11ec-8d3d-0242ac110101",

[0073] "acquirer-urn":"c9eb1c08-322e-11ec-8d3d-0242ac130123:1233e19a-3232-11ec-8d3d-0242ac110003",

[0074] TX5,

[0075] },

[0076] "signature":

[0077] "345ec54654642298ad78h2bf5d5c24b05761eb80b6de8eaa91e355567cf6cb325""

[0078] }

[0079] In the above example, "TX5" refers to the example of TX5 above, all of which may be included in TX6, but is not shown above for readability. "urn" is the URN of the butler system 110. "issuer-urn" is the URN of the issuer system 104, which matches the URN of TX5 and the "issuer-urn" in TX4. "acquirer-urn" is the URN of the acquirer system 108, which matches the URN of TX3 and the "acquirer-urn" in TX2. The payload of TX6 may be digitally signed using the butler private key. The "status" value indicates the status of the payment transaction being processed at this point, which in this example is complete. In some cases, the sixth data set does not need to include the signature of the payload by the butler system 110.

[0080] The butler system 110 may electronically transmit the sixth data set to the acquirer system 108. The acquirer system 108 may identify the status value in the sixth data set and transmit a notification to the merchant system 106 that the transaction has been successfully processed. The acquirer system 108 may credit the merchant's transaction account for receiving funds for the payment transaction with the amount included in the transaction data in TX1, and will receive a settlement from the issuer system 104 using conventional methods. The merchant system 106 may complete the payment transaction, such as by providing the traded 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.

[0081] The methods and systems discussed herein enable payment transactions to be processed using payment tokens in place of actual account credentials, where the actual account credentials are known only to the issuer system 104 that issued the transaction account, which provides significantly greater security for consumers and issuing financial institutions without sacrificing convenience. Note that the solutions described herein are not limited to four-party credit transactions, but can also be applied to person-to-person transactions for any two users (including their banks). As discussed above, the use of identity and signatures as part of the process provides an additional level of security to ensure that each entity is trustworthy and can be executed in payment transactions conducted at a physical location or in fully electronic (e.g., e-commerce) payment transactions.

[0082] In some embodiments, data sets in system 100 can be transferred from one entity to another using a payment rail associated with a payment network. A payment rail can refer to a network infrastructure associated with a payment network that is specifically configured for transmitting transaction messages. A transaction message can be a specially formatted data message that is formatted according to one or more standards that govern the exchange of financial transaction messages, such as the ISO 8583 or ISO 20022 standards of the International Organization for Standardization. As referred to herein, a "payment network" can refer to a system or network that transfers money for thousands, millions, and even billions of transactions during a given period of time using cash substitutes. A payment network can use a variety of different protocols and processes to handle the transfer of money for various types of transactions. Transactions that can be performed via a payment network can include product or service purchases, credit card purchases, debit transactions, funds transfers, account withdrawals, and the like. Examples of networks or systems configured to perform as a payment network include those composed of American The term "payment network" as used herein may refer to both the payment network as an entity and the physical payment network, such as the equipment, hardware and software comprising the payment network, also referred to herein as a payment rail.

[0083] In some embodiments where a data set is transmitted via a payment rail, the data set may be included in a transaction message. In some cases, the values ​​in the payload of the data set may be stored in appropriate data elements of the transaction message, where the past data set (e.g., TX1 in the second data set) may be stored in a data element reserved for private use. In some cases, the complete data set may be stored in a data element reserved for private use, where other data elements may include null values ​​or other predetermined data to indicate to entities in system 100 that the payment transaction includes a digital substitute for processing using the methods discussed above.

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

[0085] In some embodiments, the system 100 may also include a blockchain network 112. The blockchain network 112 may be composed of a plurality of blockchain nodes 114. Each blockchain node 114 may be a computing system, such as the one discussed in more detail below. Figure 2 or Figure 5 The computing system shown in the figure is configured to perform functions related to the processing and management of the blockchain, including the generation of blockchain data values, the verification of proposed blockchain transactions, the verification of digital signatures, the generation of new blocks, the verification of new blocks, and the maintenance of copies of the blockchain.

[0086] A blockchain may be a distributed ledger consisting of 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 is generated, and may be represented using any suitable method (e.g., UNIX timestamp, DateTime, etc.). The block reference value may be a value that references an earlier block in the blockchain (e.g., based on a 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 before the corresponding 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. The data reference value may similarly be a reference to one or more data values ​​stored in the block including 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.

[0087] The use of block reference values ​​and data reference values ​​in each block header can result in the blockchain being immutable. Any attempted modification of a data value requires the generation of a new data reference value for that block, which will require the generation of a new block reference value for subsequent blocks, and also requires the generation of a new block reference value in each subsequent block. This must be performed and updated in each individual blockchain node 114 in the blockchain network 112 before a new block is generated and added to the blockchain in order to make the change permanent. Computational and communication constraints can make such modifications extremely difficult, if not impossible, thereby making the blockchain immutable.

[0088] In some embodiments, a blockchain may be used to store information about a blockchain transaction conducted between two different blockchain wallets. A blockchain wallet may include a private key of a cryptographic key pair that is used to generate a digital signature used as an authorization for a payer to a blockchain transaction, wherein the digital signature may be verified by the blockchain network 112 using a public key of a cryptographic key pair. In some cases, the term "blockchain wallet" may specifically refer to a private key. In other cases, the term "blockchain wallet" may refer to a computing device (e.g., user device 102, etc.) that stores a private key for use in a blockchain transaction. For example, each computing device may each have its own private key for a corresponding cryptographic key pair, and may each be a blockchain wallet for transactions with a blockchain associated with a blockchain network. The computing device may be any type of device suitable for storing and utilizing a blockchain wallet, such as a desktop computer, a laptop computer, a notebook computer, a tablet computer, a cellular phone, a smart phone, a smart watch, a smart TV, a wearable computing device, an implantable computing device, and the like.

[0089] Where applicable, each blockchain data value stored in the blockchain may correspond to a blockchain transaction or other storage of data. A blockchain transaction may include at least: a digital signature of the sender of the currency (e.g., user device 102) generated using the sender's private key, a blockchain address of the recipient of the currency (e.g., merchant system 106) generated using the recipient's public key, and the amount of blockchain currency being transferred or other data being stored. In some blockchain transactions, the transaction may also include one or more blockchain addresses of the sender that currently store the blockchain currency (e.g., a digital signature proving that they have access to such currency), and an address for any changes retained by the sender generated using the sender's public key. Addresses to which cryptocurrencies have been sent that can be used in future transactions are referred to as "output" addresses because each address has previously been used to capture the output of a previous blockchain transaction, also referred to as "unspent transactions" because there is currency sent to an address in a previous transaction but the currency remains unspent. In some cases, a blockchain transaction may also include the sender's public key for use by entities when verifying 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 may verify the digital signature using the public key in the cryptographic key pair of the sender's wallet, and also verify the sender's access to the funds (e.g., unspent transactions have not been spent and sent to an address associated with the sender's wallet), a process known as "confirmation" of the transaction, and then include the blockchain transaction in a new block. In traditional blockchain implementations, new blocks may be verified by other nodes in the blockchain network 112 before being separately added to the blockchain and distributed to all blockchain nodes 114 in the blockchain network 112. In cases where a blockchain data value may not be associated with a blockchain transaction, but rather with the storage of other types of data, the blockchain data value may still include or otherwise involve verification of a digital signature.

[0090] In the system 100, a blockchain or other distributed ledger may be used to store data sets generated as part of the processing of the payment transaction discussed above. In an example, the acquirer system 108 may electronically transmit a third data set to the blockchain node 114 to include it in the blockchain data value, which is included in the new block that has been confirmed and added to the blockchain. The issuer system 104 may electronically transmit a fifth data set to the blockchain node 114 to add it to the blockchain, and the butler system 110 may electronically transmit the fourth and sixth data sets to the blockchain node 114 to add it to the blockchain. In this example, several data sets for payment transactions may be stored on the blockchain, which may be made publicly accessible. This may enable any entity involved in the payment transaction to verify the data set at the corresponding point in the transaction to ensure that the value and fee are correct and to verify the digital signature. Because a payment token is used instead of an actual payment credential, the data set can be stored on a publicly accessible ledger without compromising the associated transaction account, because only the authorized user device 102 can use the payment token in any future transaction due to having the correct private key.

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

[0092] In an embodiment where a distributed ledger is used to store identities, as part of the process discussed above, each entity in the system 100 can use the distributed ledger when verifying the identity of another entity. In an example, the merchant system 104 can provide its URN and transaction amount together with the identity of the merchant system to the user device 102 when proposing a payment transaction. The user device 102 can access the distributed ledger storing the identity to identify the blockchain data value storing the identity associated with the merchant system 104 to match the stored identity with the identity provided by the merchant system 104. In another example, the merchant system 104 can provide the user device 102 with a digital signature of its URN and transaction amount generated using its merchant private key. The user device 102 can access the identity of the merchant system on the distributed ledger and identify the merchant public key therefrom, and verify the digital signature of the URN and transaction amount using the merchant public key, wherein the digital signature will be successfully verified using the merchant public key only when the merchant system 104 uses the corresponding merchant private key, thereby authenticating the merchant system 104 as authentic. In such an example, each entity in the system 100 can use the distributed ledger to verify the identity of any other entity in the system 100. Where identities are included in a dataset stored on a blockchain, each entity can verify the identity of each other entity at any point in a payment transaction by extracting the identity from the dataset and verifying it (as discussed above).

[0093] 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 of the user device 102, wherein 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 verify the identity of the merchant system and provide the results of the verification to the user device 102, which may then use the verification as part of verifying the data provided by the merchant system 104 prior to generating the first data set.

[0094] Using a distributed ledger to store the identities of the entities involved in the system 100 can provide another level of security to ensure that each participant in a payment transaction is authentic and, due to the decentralized and immutable nature of the distributed ledger, can significantly reduce the likelihood of fraud in any payment transaction.

[0095] 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 transmission, wherein the receiving entity may decrypt the data after receipt before verification. In the case where the data set is digitally signed by the transmitting entity, a digital signature may be generated on the decrypted payload, or in some cases, a digital signature may be generated on the encrypted payload, wherein the data set may include the encrypted payload and the digital signature. In an example, the acquirer system 106 may be configured to encrypt communications with the butler system 110, including a third data set. The acquirer system 106 may generate a random temporary symmetric key, referred to herein as a session key. The acquirer system 106 encrypts the payload of the third data set using the session key, and then the acquirer system 106 may encrypt the session key using the butler public key (e.g., retrieved from the butler system identity on the distributed ledger). The acquirer system 106 may digitally sign the encrypted payload and the encrypted session key with the acquirer private key, and transmit the entire package to the butler system 110 as the third data set. The steward system 110 can verify the digital signature using the acquirer public key (e.g., retrieved from the acquirer system identity on the distributed ledger), decrypt the session key using the steward private key, and then decrypt the encrypted payload using the decrypted session key. In such embodiments, the use of encryption can provide greater security with minimal added functionality due to the use of existing key and identity information available using the methods discussed above.

[0096] Computing System

[0097] Figure 2 An embodiment of a computing system 200 is illustrated. It will be apparent to those skilled in the relevant art that Figure 2 The embodiment of the computing system 200 shown in the figure is provided for illustration only and is not intended to be an exhaustive description of all possible configurations of the computing system 200 suitable for performing the functions discussed herein. Figure 5 The computer system 500 shown in and discussed in more detail below may be a suitable configuration for the computing system 200. In some cases, additional components of the system 100 (such as the user device 102, the issuer system 104, the merchant system 106, the acquirer system 108, the steward system 110, and the blockchain node 114) may include Figure 2 Components shown in and discussed below.

[0098] The computing system 200 may include a receiving device 202. The receiving device 202 may be configured to receive data on one or more networks via one or more network protocols. In some cases, 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 butler system 110, the blockchain node 114 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, the Internet, etc.). In some embodiments, the receiving device 202 may be composed of a plurality of devices, such as different receiving devices for receiving data through different networks, such as a first receiving device for receiving data through a local area network and a second receiving device for receiving data via the Internet. The receiving device 202 may receive an electronically transmitted data signal, wherein the data may be superimposed or otherwise encoded on the data signal, and the data signal is received via the receiving device 202 to decode, parse, read or otherwise obtain. In some cases, the receiving device 202 may include a parsing module for parsing the received data signal to obtain the data superimposed thereon. For example, receiving device 202 may include a parser program configured to receive data signals and transform the received data signals into usable inputs for functions executed by a processing device to perform the methods and systems described herein.

[0099] The receiving device 202 can be configured to receive a data signal electronically transmitted by 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 data signal can be superimposed or otherwise encoded with an identity, a digital signature, a URN, a data set, a transaction data, a transaction message, a notification message, a blockchain data value, a blockchain data, a public key, a transaction identifier, a timestamp, etc.

[0100] The computing system 200 may also include a communication module 204. The communication module 204 may be configured to transmit data between modules, engines, databases, memories, and other components of the computing system 200 for performing the functions discussed herein. The communication module 204 may include one or more communication types and utilize various communication methods for communication within the computing device. For example, the communication module 204 may include a bus, a pin connector, 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 (such as externally connected databases, display devices, input devices, etc.). The computing system 200 may also include a processing device. The processing device may be configured to perform the functions of the computing system 200 discussed herein, as is clear to those skilled in the relevant art. In some embodiments, the processing device may include and / or be composed of multiple engines and / or modules specifically configured to perform one or more functions of the processing device, such as a query module 216, a generation module 218, a verification module 220, an encryption module 222, etc. As used herein, the term "module" may be software or hardware that is specifically programmed to receive input, perform one or more processes using the input, and provide output. Based on this disclosure, those skilled in the art will be clear about the inputs, outputs, and processes performed by the various modules.

[0101] 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 mode. The account database 206 may be a relational database that utilizes a structured query language to store, identify, modify, update, access, and the like structured data sets stored therein. Each account profile 208 may be a structured data set configured to store data related to an entity's account. For example, the issuer system 104 or the acquirer system 108 may store an account profile 208 associated with a transaction account, and the account profile 208 may include an account number, a payment token, a balance, a transaction history, and the like. In another example, the merchant system 106 may store an account profile 208 associated with an account of a consumer who conducts transactions with a related merchant, including an account profile 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, and the like.

[0102] The computing system 200 may also include blockchain data 210, which may be stored in the memory 214 of the processing server 102 or in a separate area within the computing system 200 or accessible thereto. The blockchain data 210 may include a blockchain, which may include a plurality of blocks and is associated with the blockchain network 112. In some cases, the blockchain data 210 may also include any other data associated with the blockchain and its management and execution, such as a block generation algorithm, a digital signature generation and confirmation algorithm, communication data for blockchain nodes 114, smart contracts, etc. The blockchain data 210 may also include data used by the computing system 200 for actions associated with the blockchain, such as a cryptographic key pair for a blockchain wallet, a public key for generating a destination address or verifying a digital signature, etc.

[0103] The computing system 200 may also include a memory 214. The memory 214 may be configured to store data for use by the computing system 200 in performing the functions discussed herein, such as public and private keys, symmetric keys, etc. The memory 214 may be configured to store data using suitable data formatting methods and patterns, and may be any suitable type of memory, such as read-only memory, random access memory, etc. The memory 214 may include, for example, encryption keys and algorithms, communication protocols and standards, data formatting standards and protocols, program code for modules and applications for processing devices, and other data that may be suitable for use by the computing system 200 in performing the functions disclosed herein, as will be clear to those skilled in the relevant art. In some embodiments, the memory 214 may be composed of a relational database or may otherwise include a relational database that utilizes a structured query language to store, identify, modify, update, access, etc., structured data sets stored therein. 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, cost data, etc.

[0104] The computing system 200 may include a query module 216. The query module 216 may be configured to perform a query on a database to identify information. The query module 216 may receive one or more data values ​​or query strings and may execute the query string based on an indicated database (such as 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. For example, the query module 216 may perform a query on the memory 214 to identify a URN and an associated public key to verify a received data set or generate a new data set.

[0105] The computing system 200 may also include a generation module 218. The generation module 218 may be configured to generate data for use by the computing system 200 in performing the functions discussed herein. The generation module 218 may receive instructions as input, may generate data based on the instructions, and may 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 a data set, generate a digital signature, generate a transaction message, generate a notification message, generate a transaction identifier, generate a new cryptographic key, generate a session key, etc.

[0106] The computing system 200 may also include a verification module 220. The verification module 220 may be configured to perform verification for the computing system 200 as part of the functionality discussed herein. The verification module 220 may receive instructions as input (which may also include data for performing verification), may perform verification upon request, and may output the results of the verification to another module or engine of the computing system 200. The verification module 220 may, for example, be configured to verify a digital signature using a suitable signature generation algorithm and key, verify a hash value by hashing the supplied data using a suitable one-way hash algorithm, verify a fee amount, verify an entity identity using a public key and blockchain data, verify transaction data in a data set, and the like.

[0107] The computing system 200 may also include an encryption module 222. The encryption module 222 may be configured to perform encryption and decryption for the computing system 200 as part of the functionality discussed herein. The encryption module 222 may receive instructions as input (which may also include data to be encrypted or encrypted data to be decrypted), may perform encryption or decryption upon request, and may output the results of the encryption or decryption operation to another module or engine of the computing system 200. For example, the encryption module 222 may be configured to encrypt a generated data set or decrypt a received encrypted data set prior to transmission.

[0108] The computing system 200 may also include a transmission device 224. The transmission device 224 may be configured to transmit data on one or more networks via one or more network protocols. In some cases, the transmission 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 butler system 110, the blockchain node 114 and other entities via one or more communication methods, local area network, wireless area network, cellular communication, Bluetooth, radio frequency, the Internet, etc. In some embodiments, the transmission device 224 may be composed of multiple devices, such as different transmission devices for transmitting data through different networks, such as a first transmission device for transmitting data via a local area network and a second transmission device for transmitting data via the Internet. The transmission device 224 may electronically transmit a data signal superimposed with data that can be parsed by the receiving computing device. In some cases, the transmission device 224 may include one or more modules for superimposing, encoding or otherwise formatting data into a data signal suitable for transmission.

[0109] The transmission device 224 can 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 data signal can be superimposed with an identity, a digital signature, a URN, a data set, a transaction data, a transaction message, a notification message, a blockchain data value, a blockchain data, a public key, a transaction identifier, a timestamp, etc. encoded in other ways.

[0110] Using distributed digital alternatives for payment processing

[0111] Figure 3 Illustrated is a process 300 for processing a payment transaction in the system 100 that utilizes a payment token in place of actual payment credentials, wherein the transaction data set is stored in a distributed ledger.

[0112] In step 302, using its input module, the user of the user device 102 may select a payment method to be used for the upcoming payment transaction. In step 304, the user device 102 may electronically transmit (such as via the transmission device 224) a token request to the issuer system 104 using a suitable communication network and method (such as via an application associated with the issuer system 104 executed by the user device 102). The token request may include at least an identifier associated with the transaction account selected by the user of the user device 102. In some cases, the token request may be digitally signed by the user device 102 using the user's private key. The issuer system 104 may receive (e.g., via the receiving device 202) the token request and, if signed, verify (e.g., via the verification module 220) the digital signature using the user's public key (e.g., received in a previous new user onboarding process, obtained from an identity distributed ledger, etc.).

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

[0114] In step 310, the user device 102 may generate (e.g., via the generation module 218) TX1 as a first data set for a new payment transaction. TX1 may include at least a payload including a signed payment token, a timestamp, a transaction identifier, a transaction amount, and a URN of the merchant system 106 ("merchant URN"), and a digital signature generated by the user device 102 on the payload using a user private key (e.g., via the generation module 218). The transaction identifier, transaction amount, and merchant URN may be input into the user device 102 by its user, received from the merchant system 106, or obtained using other suitable methods. In step 312, the user device 102 may transmit (e.g., via the transmission device 224) TX1 to the merchant system 106 using a suitable communication network and method. The merchant system 106 can receive (e.g., via the receiving device 202) TX1 and verify (e.g., via the verification module 220) that the transaction identifier, transaction amount, and merchant URN are equal to the expected values, and verify the digital signature on the payload using the user's public key (e.g., obtained from an identity distributed ledger, a consumer's account profile, etc.).

[0115] In step 314, the merchant system 106 may generate (e.g., via the generation module 218) TX2 as a second data set for the payment transaction. TX2 may include at least a payload including a timestamp, a transaction identifier, a signed payment credential for the merchant's transaction account with the acquirer system 108, a URN for the acquirer system 108 ("acquirer URN"), fee data, and TX1, as well as a digital signature on the payload generated by the merchant system 106 using the merchant private key (e.g., via the generation module 218). In step 316, the merchant system 106 may transmit (e.g., via the transmission device 224) TX2 to the acquirer system 108 using a suitable communication network and method. The acquirer system 108 can receive (e.g., via receiving device 202) TX2 and verify (e.g., via verification module 220) that the transaction identifier, acquirer URN, and charge data are equal to expected values, verify the digital signature on the merchant's payment credentials using the acquirer public key, and verify the digital signature on the payload using the merchant public key (e.g., obtained from an identity distributed ledger, an account profile of the merchant system 106, etc.).

[0116] In step 318, the acquirer system 108 may generate (e.g., via the generation module 218) TX3 as a third data set for the payment transaction. TX3 may include at least a payload including a timestamp, a transaction identifier, an acquirer URN, a URN of the steward system 110 ("steward URN"), fee data, and TX2, and a digital signature generated by the acquirer system 108 on the payload using the acquirer private key (e.g., via the generation module 218). In step 320, the acquirer system 108 may electronically transmit (e.g., via the transmission device 224) the generated TX3 to the blockchain node 114 in the blockchain network 112 to be written to the blockchain data value included in the new block confirmed and added to the blockchain. In step 322, the acquirer system 108 may transmit (e.g., via the transmission device 224) TX3 to the steward system 110 using a suitable communication network and method. The steward system 110 can receive (e.g., via receiving device 202) TX3 and verify (e.g., via verification module 220) that the transaction identifier, steward URN, and fee data are equal to expected values, and verify the digital signature on the payload using the acquirer public key (e.g., obtained from an identity distributed ledger, an account profile of the acquirer system 108, etc.).

[0117] In step 324, the steward system 110 may generate (e.g., via generation module 218) TX4 as a fourth data set for the payment transaction. TX4 may include at least a payload including a timestamp, a transaction identifier, a steward URN, a URN for the issuer system 104 ("issuer URN"), and TX3, and a digital signature generated by the steward system 110 on the payload (e.g., via generation module 218) using the steward private key. In step 326, the steward system 110 may electronically transmit (e.g., via transmission device 224) the generated TX4 to a blockchain node 114 in the blockchain network 112 to be written to the blockchain data value included in the new block confirmed and added to the blockchain. In step 328, the steward system 110 may transmit (e.g., via transmission device 224) TX4 to the issuer system 104 using a suitable communication network and method. The issuer system 104 can receive (e.g., via receiving device 202) TX4 and verify (e.g., via verification module 220) whether the transaction identifier, issuer URN, and fee data are equal to expected values, verify the digital signature on the user's payment token in TX1 using the issuer public key, and verify the digital signature on the payload using the steward public key (e.g., obtained from an identity distributed ledger, an account profile of steward system 110, etc.).

[0118] In step 330, issuer system 104 may identify (e.g., in account database 206) a transaction account (e.g., via account profile 208) for funding the payment transaction based on the URN included in the payment credentials included in the TX1 portion of the payload of TX4 (if approved). In step 332, issuer system 104 may determine that the payment transaction will be approved, such as based on the transaction amount included in the payload of TX1 being less than the available balance or available credit of the identified transaction account and other transaction data complying with any applicable transaction controls.

[0119] In step 334, the issuer system 104 may generate (e.g., via the generation module 218) TX5 as a fifth data set for the payment transaction. TX5 may include at least a payload including a timestamp, a transaction identifier, an issuer URN, a steward URN, an authorization for the payment transaction, and TX4, and a digital signature on the payload generated by the issuer system 104 using the issuer private key (e.g., via the generation module 218). In step 336, the issuer system 104 may electronically transmit (e.g., via the transmission device 224) the generated TX5 to the blockchain node 114 in the blockchain network 112 to write it to the blockchain data value included in the new block confirmed and added to the blockchain. In step 338, the issuer system 104 may transmit (e.g., via the transmission device 224) TX4 to the steward system 110 using a suitable communication network and method. The steward system 110 can receive (e.g., via receiving device 202) TX4 and verify (e.g., via verification module 220) that the transaction identifier, steward URN, and authorization are equal to expected values, and verify the digital signature on the payload using the issuer public key (e.g., obtained from an identity distributed ledger, an account profile of the issuer system 104, etc.).

[0120] In step 340, the butler system 110 may generate (e.g., via the generation module 218) TX6 as a sixth data set for the payment transaction. TX6 may include at least a payload including a timestamp, a transaction identifier, an issuer URN, a butler URN, an acquirer URN, a status of the payment transaction, and TX5, as well as a digital signature on the payload generated by the butler system 110 using the butler private key (e.g., via the generation module 218). In step 342, the butler system 110 may electronically transmit (e.g., via the transmission device 224) the generated TX6 to the blockchain node 114 in the blockchain network 112 to write it to the blockchain data value included in the new block confirmed and added to the blockchain. In step 344, the butler system 110 may electronically transmit an approval message to the acquirer system 108 via a suitable 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 (e.g., via the receiving device 202) the approval message and forward (e.g., via the transmission device 224) the approval message to the merchant system 106 using a suitable communication network and method in step 346. The merchant system 106 may receive (e.g., via the receiving device 202) the approval message and provide the item purchased using the payment transaction to the consumer in step 348.

[0121] Example method for pre-authorizing a payment transaction

[0122] Figure 4 A method 400 of pre-authorizing a payment transaction using tokenized payment credentials is illustrated.

[0123] In step 402, a first data set may be received by a receiver (e.g., receiving device 202) of a processing server (e.g., butler system 110), wherein 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). In step 404, 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. In step 406, in response to verification of the first digital signature, a second data set may be extracted from the first data set, wherein the second data set includes at least a merchant identification value (e.g., merchant URN) and a third data set (e.g., TX1).

[0124] In step 408, a third data set may be extracted from the second data set, wherein the third data set includes at least an issuer identification value (e.g., an issuer URN, a second portion of a URN in a payment credential, etc.) and transaction data. In step 410, an issuing computing system (e.g., issuer system 104) may be identified by a processor of a processing server (e.g., query module 216) based at least on the issuer identification value. In step 412, a fourth data set (e.g., TX4) may be transmitted by a transmitter of the processing server (e.g., transmission device 224) to the issuing computing system, wherein the fourth data set includes at least the first data set and a steward identification value (e.g., steward URN).

[0125] 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 also includes the acquirer value, and extracting the third data set 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 cryptographic key pair, and method 400 may further include decrypting, by an encryption module of the processing server (e.g., encryption module 222), the first data set using a private key of the second cryptographic key pair. In one embodiment, method 400 may further include encrypting, by an encryption module of the processing server using the issuer public key before transmitting to the issuing computing system.

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

[0127] Computer system architecture

[0128] Figure 5 A computer system 500 is illustrated in which embodiments of the present disclosure or portions thereof may be implemented as computer readable code. For example, Figure 1 The user device 102, the issuer system 104, the merchant system 106, the acquirer system 108, the steward system 110 and the blockchain node 114 and Figure 2 The computing system 200 of the embodiment of the present invention 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 be implemented to implement Figure 3 and Figure 4 Modules and components of the method.

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

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

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

[0132] Processor device 504 can be a dedicated or general processor device specially configured to perform the functions discussed herein. Processor device 504 can be connected to communication infrastructure 506, such as bus, message queue, network, multi-core message delivery scheme, etc. The network can be any network suitable for performing the functions disclosed herein, and can include local area network (LAN), wide area network (WAN), wireless network (e.g., WiFi), mobile communication network, satellite network, Internet, optical fiber, coaxial cable, infrared, radio frequency (RF) or any combination thereof. Other suitable network types and configurations will be clear to those skilled in the art. Computer system 500 can also include main memory 508 (e.g., random access memory, read-only memory, etc.) and can also include auxiliary memory 510. Auxiliary memory 510 can include hard disk drive 512 and removable storage drive 514, such as floppy disk drive, tape drive, optical disk drive, flash memory, etc.

[0133] Removable storage drive 514 can 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 and written by removable storage drive 514. For example, if removable storage drive 514 is a floppy disk drive or a universal serial bus port, then 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 computer-readable recording medium.

[0134] In some embodiments, secondary memory 510 may include alternative components for allowing computer programs or other instructions to be loaded into computer system 500, such as removable storage units 522 and interfaces 520. Examples of such components may include program cartridges and cartridge interfaces (e.g., as found in video game systems), removable memory chips (e.g., EEPROM, PROM, etc.) and associated sockets, and other removable storage units 522 and interfaces 520, as will be apparent to persons skilled in the relevant art(s).

[0135] Data stored in the computer system 500 (e.g., in the main memory 508 and / or the secondary memory 510) may be stored on any type of suitable computer-readable medium, such as an optical storage device (e.g., a compact disk, a digital versatile disk, a Blu-ray disk, etc.) or a tape storage device (e.g., a hard drive). The data may be configured in any type of suitable database configuration, such as a relational database, a structured query language (SQL) database, a distributed database, an object database, etc. Suitable configurations and storage types will be clear to those skilled in the relevant art.

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

[0137] The computer system 500 may also include a display interface 502. The display interface 502 may be configured to allow data to be transferred between the computer system 500 and an external display 530. Exemplary display interfaces 502 may include a high-definition multimedia interface (HDMI), a digital video interface (DVI), a video graphics array (VGA), etc. The display 530 may be any suitable type of display for displaying data transmitted via the display interface 502 of the computer system 500, including 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.

[0138] Computer program media and computer usable media may refer to memory, such as main memory 508 and secondary memory 510, which may be memory semiconductors (e.g., DRAM, etc.). These computer program products may be components for providing software to 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 communication interface 524. Such computer programs, when executed, may enable computer system 500 to implement the present methods discussed herein. In particular, the computer programs, when executed, may enable processor device 504 to implement the methods described herein. Figure 3 and Figure 4 The method shown, as discussed herein. Thus, such a computer program may represent a controller of the computer system 500. Where software is used to implement the present disclosure, the software may be stored in a computer program product and loaded into the computer system 500 using the removable storage drive 514, the interface 520, and the hard disk drive 512 or the communication interface 524.

[0139] 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 cases, software such as corresponding to program code and / or programs stored in the main memory 508 or the auxiliary memory 510 may also be utilized. In such cases, the program code may be compiled by the processor device 504 (e.g., by a compilation module or engine) before being executed by the hardware of the computer system 500. For example, the program code may be source code written in a programming language that is translated into a lower-level language (such as assembly language or machine code) for execution by the processor device 504 and / or any additional hardware components of the computer system 500.

[0140] The process of compiling may include the use of lexical analysis, preprocessing, parsing, semantic analysis, syntax-directed conversion, code generation, code optimization, and any other techniques that may be suitable for converting program code into a lower-level language suitable for controlling the computer system 500 to perform the functions disclosed herein. It will be clear to those skilled in the relevant art that such processing results in a computer system 500 that is a specifically configured computer system 500 that is specifically programmed to perform the functions discussed above.

[0141] Technology consistent with the present disclosure provides, among other features, systems and methods for pre-authorization of payment transactions with the aid of tokenized credentials. Although various exemplary embodiments of the disclosed systems and methods have been described above, it should be understood that they are given for purposes of illustration only and not limitation. This is not exhaustive and does not limit the disclosure to the exact form disclosed. In view of the above teachings, modifications and variations are possible or may be obtained from the practice of the disclosure without departing from the breadth or scope.

Claims

1. A method for pre-authorization of a payment transaction by means of a tokenized credential, comprising: receiving, by a receiver of a processing server, a first data set, wherein the first data set is signed with a first digital signature and includes 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 a second data set from the first data set in response to verification of the first digital signature, wherein the second data set includes at least a merchant identification value and a third data set; extracting a third data set from the second data set, wherein the third data set includes at least an issuer identification value and transaction data; identifying, by a processor of the processing server, an issuing computing system based at least on the issuer identification value; as well as A fourth data set is transmitted by a transmitter of the processing server to the issuing computing system, wherein the fourth data set includes at least the first data set and a steward identification value.

2. The method of claim 1, further comprising: The verification module of the processing server verifies that the acquirer value corresponds to the acquirer identification value before extracting the third data set, wherein The second data set also 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.

3. The method of claim 1, wherein encrypting the first data set using a second public key of a second cryptographic key pair, and The method further comprises: The first data set is decrypted by the encryption module of the processing server using the private key of the second cryptographic key pair.

4. The method of claim 1, further comprising: The fourth data set is encrypted by the encryption module of the processing server using the public key of the issuing computing system before being transmitted to the issuing computing system.

5. 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. The method of claim 5, wherein the acquirer identification value, the merchant identification value, the issuer identification value, and the steward identification value are each digitally signed using a private key of an identity cryptographic key pair including a corresponding associated public key.

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

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

9. A system for pre-authorization of payment transactions by means of tokenized credentials, comprising: Issue computing systems; as well as A processing server, the processing server comprising a receiver that receives a first data set, wherein the first data set is signed with a first digital signature and includes 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; processor, the processor extracting a second data set from the first data set in response to verification of the first digital signature, wherein the second data set includes at least a merchant identification value and a third data set; extracting a third data set from the second data set, wherein the third data set includes at least an issuer identification value and transaction data; as well as identifying an issuing computing system based at least on the issuer identification value; as well as A transmitter transmits a fourth data set to the issuing computing system, wherein the fourth data set includes at least the first data set and a steward identification value.

10. The system of claim 9, wherein The verification module of the processing server verifies that the acquirer value corresponds to the acquirer identification value before extracting the third data set, wherein The second data set also 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.

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

12. The system of claim 9, the processing server further comprising an encryption module, the encryption module encrypting the fourth data set using a public key of the issuing computing system before transmitting the fourth data set to the issuing computing system.

13. 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. The system of claim 13, wherein the acquirer identification value, the merchant identification value, the issuer identification value, and the steward identification value are each digitally signed using a private key of an identity cryptographic key pair including a corresponding associated public key.

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

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

Images