Method and system for using records to guarantee instant payments

Abstract

A method for processing guaranteed electronic transactions, comprising: storing account profiles, each account profile including an account number and a balance; receiving a transaction message from an acquiring financial institution via a payment network, the message including a specific account number, a transaction amount, and payment guarantee data; identifying a specific account profile containing the specific account number; deducting the transaction amount from the account balance in the specific account profile; generating a payment guarantee record, the payment guarantee record including the transaction amount and data related to the payment guarantee data; generating a return message including a response code indicating transaction approval and data associated with the generated record; sending the generated record to a computing system via a communications network; and sending the generated return message to the acquiring financial institution via the payment network.

Description

[0001] This application is a divisional application of application number 201780027631.4, filed March 28, 2017.

[0002] Cross Reference to Related Applications

[0003] This application claims the benefit of and priority to U.S. Application No. 15 / 148,121, filed May 6, 2016. The entire disclosure of the above application is incorporated herein by reference. TECHNICAL FIELD

[0004] The present disclosure relates to the use of recorded guarantees in order to verify payment transactions by acquirers, to facilitate immediate payment to merchants involved in payment transactions, particularly using a blockchain or other third party network to verify guarantees related to the payment transactions. BACKGROUND

[0005] When conducting transactions with merchants, many consumers choose to use issued payment instruments, such as credit cards and checks, in lieu of traditional paper fiat currency. While such payment instruments provide a degree of convenience to consumers, such as protection against fraud and theft, transaction accounting, etc., the use of such instruments can be disadvantageous to merchants. For example, due to processing, clearing, and settlement times, merchants can need several days to receive funds for transactions conducted using issued payment instruments, whereas transactions conducted using paper fiat currency enable merchants to have immediate access to funds. The use of issued payment instruments is also disadvantageous to merchants in that there is generally no guarantee that a transaction will clear, and if the consumer does not in fact have funds, the merchant can be at risk of not receiving any payment at all.

[0006] To overcome these disadvantages, some issuing financial institutions have begun to issue guaranteed checks to their customers. A guaranteed check is a check that guarantees the underlying amount to be paid, so that the issuing financial institution can guarantee to the acquiring financial institution and the merchant that the funds represented by the consumer's check are available to be paid to the merchant at any time. However, many merchants can lack the computing systems necessary to process guaranteed checks. In addition, the use of checks is often cumbersome, if not impossible, for Internet-based and other types of electronic commerce transactions. Still further, many consumers often find the use of checks to be inconvenient and can prefer to use other payment instruments, such as payment cards.

[0007] Accordingly, a technical solution is needed in which payment transactions can be guaranteed in a manner that is easily verifiable by the acquiring financial institution and / or merchant, and the guarantee can be used with multiple types of payment instruments and multiple transaction types, including e-commerce transactions. By applying the guarantee with multiple payment instruments and transaction types, the guarantee can be used in more situations, providing greater convenience to both consumers and merchants, which can result in merchants receiving immediate, guaranteed payments while maintaining a high level of consumer convenience. SUMMARY

[0008] The present disclosure provides a description of systems and methods for processing guaranteed electronic transactions.

[0009] A method of processing guaranteed electronic transactions, comprising: storing a plurality of account profiles in an account database of a processing server, wherein each account profile comprises a structured set of data related to a transaction account, including at least a transaction account number and an account balance; receiving, by a receiving device of the processing server, a transaction message related to an electronic transaction through a payment network, wherein the transaction message originates from an acquiring financial institution and is formatted based on one or more standards, wherein the transaction message comprises: a plurality of data elements, including at least a first data element, a second data element, a third data element, and one or more additional data elements configured to store additional transaction data, the first data element configured to store a primary account number, the second data element configured to store a transaction amount, the third data element configured to store payment guarantee data; performing, by a querying module of the processing server, a first query of the account database to identify a particular account profile, wherein the transaction account number included in the particular account profile corresponds to the primary account number stored in the first data element included in the received transaction message; performing, by the querying module of the processing server, a second query of the account database to deduct at least the transaction amount stored in the second data element included in the received transaction message from the account balance included in the identified particular account profile; generating, by a generating module of the processing server, a record of a payment guarantee, wherein the record of the payment guarantee includes at least the transaction amount and data associated with the payment guarantee data stored in the third data element included in the received transaction message; generating, by the generating module of the processing server, a return message, wherein the return message is formatted based on the one or more standards and includes a plurality of data elements, including at least a first data element and a second data element, the first data element configured to store a response code indicating approval of the related electronic transaction, the second data element configured to store data associated with the generated record of the payment guarantee; electronically transmitting, by a transmitting device of the processing server, the generated record of the payment guarantee to a computing system through a communication network; and electronically transmitting, by the transmitting device of the processing server, the generated return message to the acquiring financial institution through the payment network.

[0010] A system for processing guaranteed electronic transactions, comprising: an account database of a processing server configured to store a plurality of account profiles, wherein each account profile comprises a structured set of data related to a transaction account, including at least a transaction account number and an account balance; a receiving device of the processing server configured to receive a transaction message related to an electronic transaction via a payment network, wherein the transaction message originates from an acquiring financial institution and is formatted based on one or more criteria, wherein the transaction message comprises a plurality of data elements, including at least: a first data element configured to store a primary account number, a second data element configured to store a transaction amount, a third data element configured to store payment guarantee data, and one or more additional data elements configured to store additional transaction data; a querying module of the processing server configured to perform a first query on the account database to identify a particular account profile in which a transaction account number included in the particular account profile corresponds to the primary account number stored in the first data element included in the received transaction message, and to perform a second query on the account database to deduct at least the transaction amount stored in the second data element included in the received transaction message from the account balance included in the identified particular account profile; a generating module of the processing server configured to generate a record of a payment guarantee, wherein the record of the payment guarantee includes at least the transaction amount and data associated with the payment guarantee data stored in the third data element included in the received transaction message, and a return message, wherein the return message is formatted based on one or more criteria and comprises a plurality of data elements, including at least: a first data element configured to store a response code indicating that the related electronic transaction is approved, and a second data element configured to store data related to the generated record of the payment guarantee; and a transmitting device of the processing server configured to electronically transmit the generated record of the payment guarantee to a computing system via a communication network, and to electronically transmit the generated return message to the acquiring financial institution via the payment network. BRIEF DESCRIPTION OF DRAWINGS

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

[0012] Figure 1 is a block diagram illustrating a high-level system architecture for processing guaranteed electronic transactions for instant payments to merchants, in accordance with exemplary embodiments;

[0013] Figure 2 is a block diagram illustrating a processing server of Figure 1 for processing guaranteed electronic transactions, in accordance with exemplary embodiments;

[0014] Figure 3A and 3B is a flowchart illustrating a process for processing guaranteed electronic transactions and making instant payments to merchants using a system in accordance with example embodiments; Figure 1

[0015] Figure 4 is a flowchart illustrating an example method for processing guaranteed electronic transactions in accordance with example embodiments;

[0016] Figure 5 is a flowchart illustrating the processing of a payment transaction in accordance with example embodiments;

[0017] Figure 6 is a block diagram illustrating a computer system architecture in accordance with example embodiments.

[0018] Other areas of application of the present disclosure will become apparent from the detailed description provided below. It should be understood that the detailed description of the example embodiments is for illustrative purposes only and thus is not intended to necessarily limit the scope of the present disclosure. DETAILED DESCRIPTION

[0019] Glossary

[0020] Payment Network - a system or network for transferring funds by using a cash substitute. A payment network can use various different protocols and procedures to process currency transfers for various types of transactions. Transactions that can be performed through a payment network can include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. A payment network can be configured to perform transactions through a cash substitute, which can include a payment card, a letter of credit, a check, a transaction account, etc. Examples of networks or systems configured to perform a payment network include the networks or systems operated by American Express, etc. The use of the term “payment network” herein can refer to a payment network as an entity as well as the physical payment network, e.g., the equipment, hardware, and software that make up the payment network.

[0021] Transaction Account - a financial account that can be used to fund a transaction, such as a checking account, a savings account, a credit account, a virtual payment account, etc. A transaction account can be associated with a consumer, which can be any suitable type of entity associated with a payment account, which can include an individual, a family, a company, a group, a government entity, etc. In some cases, a transaction account can be virtual, such as an account operated by

[0022] ​​Merchant - an entity that offers a product (e.g., goods and / or services) for purchase by another entity (e.g., a consumer or other merchant). A merchant can be a consumer, a retailer, a wholesaler, a manufacturer, or any other type of entity that can offer a product for purchase, as will be apparent to those having skill in the relevant art. In some cases, a merchant can have special knowledge of the goods and / or services offered for purchase. In other cases, a merchant can have no or little special knowledge of the products offered. In some embodiments, an entity involved in a single transaction can be considered a merchant. In some cases, as used herein, the term "merchant" can refer to a device or apparatus of a merchant entity.

[0023] Issuer - an entity that establishes (e.g., opens) a letter of credit or line of credit for a beneficiary and authorizes drafts for withdrawal by the beneficiary in an amount specified in the letter of credit or line of credit. In many cases, an issuer can be a bank or other financial institution that is authorized to open lines of credit. In some cases, any entity that can extend a line of credit to a beneficiary can be considered an issuer. Lines of credit opened by an issuer can be represented in the form of a payment account and can be withdrawn by a beneficiary through the use of a payment card. An issuer can also provide additional types of payment accounts to a consumer, as will be apparent to those having skill in the relevant art, such as debit accounts, prepaid accounts, electronic wallet accounts, savings accounts, checking accounts, etc., and can provide a consumer with physical or non-physical means for accessing and / or using such accounts, such as debit cards, prepaid cards, automated teller machine cards, electronic wallets, checks, etc.

[0024] Payment rail - infrastructure associated with a payment network that is used in the processing of payment transactions and in the communication of transaction messages and other similar data between the payment network and other entities interconnected with the payment network. A payment rail can include hardware used to establish the payment network and interconnections between the payment network and other related entities (e.g., financial institutions, gateway processors, etc.). In some cases, a payment rail can also be influenced by software, such as through special programming of the communication hardware and devices that make up the payment rail. For example, a payment rail can include specially configured computing devices configured to route transaction messages, which can be special formatted data messages electronically transmitted over the payment rail, as discussed in more detail below.

[0025] Blockchain - a public ledger of all transactions of a blockchain-based currency. One or more computing devices can make up a blockchain network, which can be configured to process and record transactions as part of blocks in the blockchain. Once a block is complete, the block is added to the blockchain, thereby updating the transaction record. In many cases, the blockchain can be a chronological ledger of transactions, or can be presented in any other order suitable for use by the blockchain network. In some configurations, transactions recorded in the blockchain can include a destination address and an amount of currency, such that the blockchain records an amount of currency attributable to a particular address. In some instances, additional information can be captured, such as a source address, a timestamp, and the like. In some embodiments, the blockchain can also be comprised of additional data confirmed and verified by the blockchain network through proof-of-work and / or any other suitable verification techniques with which it is associated, in some instances arbitrary data. In certain cases, such data is included in the blockchain as part of a transaction, for example, in additional data appended to the transaction data. In certain instances, the inclusion of this data in the blockchain can constitute a transaction. In such instances, the blockchain can not be directly associated with a particular digital currency, virtual currency, fiat currency, or other type of currency.

[0026] Systems for processing guaranteed electronic transactions

[0027] Figure 1 A system 100 for processing electronic transactions with a record guarantee to facilitate immediate payment to a merchant is shown, where the record guarantee can be published to a third-party network for independent verification.

[0028] The system 100 can include an issuer processing server 102. The issuer processing server 102, discussed in more detail below, can be configured to generate a payment guarantee record for a payment transaction and to process subsequent payment transactions. The issuer processing server 102 can issue a transaction account to a consumer 104. As part of the issuance of the transaction account, the issuer processing server 102 can issue a payment instrument 106 to the consumer 104 for use in funding payment transactions using the corresponding transaction account. The payment instrument 106 can be any type of payment instrument suitable for performing the functions discussed herein, such as a credit card, a debit card, a virtual payment card, a controlled payment number, and the like. The payment instrument 106 can be a physical payment instrument, such as a physical payment card, or can be a virtual payment instrument, such as a payment token issued to and stored on an electronic communication device, such as a smartphone or a wearable computing device.

[0029] A consumer 104 can initiate a payment transaction at a merchant system 108 to purchase one or more goods or services. As part of the payment transaction, the consumer 104 can present a payment instrument 106 to the merchant system 108 for communicating payment details for funding the payment transaction. The merchant system 108 can receive the payment details from the payment instrument 106 using a suitable method based on the type of payment instrument 106, such as reading a magnetic stripe encoded with the payment details, receiving a data signal encoded with the payment details transmitted electronically over near field communication, reading a machine-readable code displayed on a mobile communication device encoded with the payment details, and the like. The merchant system 108 can receive the payment details and can submit the payment details and additional transaction data to an acquirer processing server 110 using a suitable communication network and method. In some instances, the merchant system 108 can electronically send the payment details and additional transaction data to the acquirer processing server 110 over a payment rail associated with a payment network 112. The additional transaction data can include at least a transaction amount, and can further include additional data such as a transaction time, a transaction date, a geographic location, a merchant identifier, a point-of-sale identifier, product data, merchant data, consumer data, offer data, reward data, loyalty data, and the like.

[0030] The acquirer processing server 110 can receive the payment details and transaction data and can generate a transaction message for the payment transaction. The transaction message can be a specially formatted data message in a format formatted according to one or more standards governing the exchange of financial transaction messages, such as the ISO 8583 standard of the International Organization for Standardization. The transaction message can include a message type indicator indicating a type of transaction message, such as an authorization request. The transaction message can further include a plurality of data elements configured to store data associated with the payment transaction, including a first data element configured to store a primary account number read from the payment instrument 106, a second data element configured to store a transaction amount, and one or more additional data elements configured to store additional transaction data and payment details. In some instances, the transaction message can further include one or more bitmaps that can indicate the data elements included in the transaction message and the data stored therein.

[0031] In some embodiments, the plurality of data elements included in the transaction message can also include a data element configured to store payment guarantee data. The payment guarantee data can be data used by the issuer processing server 102 in generating and / or submitting a guaranteed payment record. As discussed in more detail below, the payment guarantee data can include data associated with a blockchain network 114 for publishing a guaranteed payment record to the blockchain network 114. The blockchain network 114 can be a network configured to store a blockchain, possibly a ledger of electronic transactions, that can include a record of a guaranteed payment. In this case, the payment guarantee data can include an identifier associated with the blockchain network 114 used by the acquirer processing server 110 and a public key or destination address associated with the acquirer processing server 110 for receiving the guaranteed payment record. In some cases, the payment guarantee data can be an indication that the consumer 104 has requested an instant payment for the transaction. In some cases, the merchant system 108 can provide an incentive for the consumer 104 to make an instant payment, such as a discount, reward points, additional products or services, etc.

[0032] The acquirer processing server 110 can electronically transmit the transaction message for the payment transaction to the payment network 112 over the payment rails. The payment network 112 can perform any necessary processing of the received transaction message, such as fraud scoring, application of transaction controls, etc., and can forward the transaction message to the issuer processing server 102 via the payment rails. In some cases, the payment network 112 can identify the issuer processing server 102 by a primary account number stored in a corresponding data element included in the transaction message, such as based on a bank identification number (BIN) (also known as an issuer identification number (IIN)), or other identifying value contained in the primary account number.

[0033] The issuer processing server 102 can receive the transaction message over the payment rails and can then generate a guaranteed payment record for the payment transaction. The issuer processing server 102 can identify the transaction account used in the payment transaction (e.g., associated with the consumer 104 and the payment instrument 106, identified by a primary account number stored in a corresponding data element included in the transaction message) and can verify that the transaction account has a sufficient balance to cover a transaction amount stored in a corresponding data element included in the transaction message. The issuer processing server 102 can deduct the transaction amount from an account balance in the transaction account (e.g., or increase the balance as appropriate, such as based on the type of transaction account). The issuer processing server 102 can also perform any additional actions to approve the payment transaction for payment of the transaction amount by the transaction account associated with the consumer 104, such as fraud detection analysis, etc. The issuer processing server 102 can then generate a guaranteed payment record for the payment transaction.

[0034] In embodiments that use the blockchain network 114, the issuer processing server 102 can generate a blockchain transaction as the payment guarantee record. The blockchain transaction can be a transaction to pay the transaction amount stored in the corresponding data element included in the received transaction message to a destination address associated with the acquirer processing server 110. The destination address can be the destination address included in the payment guarantee data stored in the transaction message or can be a destination address generated by the issuer processing server 102 using the public key stored in the payment guarantee data. Methods for generating a blockchain destination address using a public key will be apparent to those of skill in the relevant art. The issuer processing server 102 can then electronically transmit the generated blockchain transaction to the blockchain network 114 or a computing node associated therewith for publication to the blockchain.

[0035] The issuer processing server 102 can generate a response transaction message indicating that the payment transaction is approved. In some cases, the response transaction message can be a newly generated transaction message. In other cases, the response transaction message can be a modification of the received transaction message. The response transaction message can include a message type indicator indicating an authorization response and can include a plurality of data elements including a data element configured to store a response code indicating that the payment transaction is approved. In cases where the payment transaction can not yet be approved by the issuer processing server 102 (e.g., due to fraud, insufficient funds, etc.), the response code can indicate that the payment transaction is not approved and that no guarantee payment record can be generated or provided.

[0036] The plurality of data elements can also include a data element configured to store data associated with the generated guarantee payment record. In embodiments that use the blockchain network 114, the data associated with the generated guarantee payment record can include data associated with the blockchain transaction. This data can include, for example, a transaction identifier provided for the blockchain transaction by the blockchain network 114 or a hash generated using the blockchain transaction. In other embodiments, the data associated with the guarantee payment record can include a hash generated by the issuer processing server 102 using the guarantee payment record. In some cases, the data can be data agreed upon by the acquirer processing server 110 and the issuer processing server 102 to indicate that the transaction has been guaranteed for payment.

[0037] The issuer processing server 102 can then electronically send the response transaction message to the payment network 112 over the payment rails. The payment network 112 can forward the response transaction message to the acquirer processing server 110. The acquirer processing server 110 can review the received response transaction message, which indicates that the transaction was approved and includes data associated with the guaranteed payment record. The acquirer processing server 110 can perform any actions associated with approving the payment transaction, such as by forwarding the approval of the transaction to the merchant system 108. The merchant system 108 can then complete the payment transaction, such as by providing the transaction goods or services to the consumer 104.

[0038] As part of processing the received response transaction message, the acquirer processing server 110 can verify the data as having confirmed that the payment for the transaction amount of the payment transaction is guaranteed. In cases where the blockchain network 114 is used, the acquirer processing server 110 can retrieve the blockchain from the blockchain network 114 and identify that a blockchain transaction associated with the payment transaction for the payment transaction amount to a destination address associated with the acquirer processing server 110 has successfully been published to the blockchain. In some embodiments, the blockchain transaction can also include an identification value associated with the payment transaction (e.g., included in a data element included in the transaction message by the acquirer processing server 110 and / or the issuer processing server 102) to identify the blockchain transaction corresponding to the response transaction message, such as in cases where the acquirer processing server 110 and the issuer processing server 102 can be processing multiple transactions.

[0039] If the verification of the guaranteed payment record is successful, the acquirer processing server 110 can instantly credit the transaction account associated with the merchant system 108 for the transaction amount. In cases where the blockchain network 114 is used and the blockchain transaction is processed, the acquirer processing server 110 can receive the funds for the payment transaction through the blockchain, which can be in the form of a blockchain currency or a fiat currency. In some cases, the blockchain transaction can be used to communicate the guaranteed payment record, and the issuer processing server 102 provides the funds to the acquirer processing server 110 using traditional settlement and clearing processes. As a result of the guarantee, the acquirer processing server 110 can still instantly credit the transaction account of the merchant system 108 due to the guarantee by the issuer processing server 102 that it will provide the funds to the acquirer processing server 110.

[0040] In some embodiments, the consumer 104 can request that funds be set aside for instant payment to a merchant prior to initiating a payment transaction. In such embodiments, the consumer 104 can submit an allocation request to the issuer processing server 102 via a computing device and a suitable communications network (e.g., the Internet) in electronic form. The allocation request can include an identification value associated with a transaction account for identification thereof, such as a primary account number, and an amount to allocate / set aside for instant payment. In some cases, the consumer 104 can also provide information associated with a future purchase for which instant payment is to be made, such as merchant information (e.g., a merchant identifier, a merchant category code, etc.), product information, a transaction time and / or date range, a geographic location and / or region, etc. The issuer processing server 102 can allocate the indicated amount in the account balance for the upcoming instant payment, which can make the amount unavailable for any other payment transaction. In some cases, the issuer processing server 102 can deduct the indicated amount directly from the transaction account. In other cases, the issuer processing server 102 can place the indicated amount in escrow, and can return the amount to the transaction account if no instant payment occurs.

[0041] In such embodiments, when the issuer processing server 102 receives a transaction message via a payment rail, where the payment message includes assurance payment data indicating that an instant payment is to be made, the issuer processing server 102 can verify that the transaction complies with any information provided by the consumer 104 for instant payment, such as that the transaction time is within the provided transaction time range, that the merchant identifier included in the transaction message matches the merchant identifier provided by the consumer 104, etc. The issuer processing server 102 can also verify that the amount allocated by the consumer 104 is greater than or equal to the transaction amount. In some embodiments, if the transaction amount is greater than the allocated amount, the issuer processing server 102 can contact the consumer 104 for additional verification. For example, if the transaction amount is higher than expected by the consumer 104 and the transaction account has sufficient balance and / or credit to pay the additional amount, the issuer processing server 102 can electronically transmit a data signal superimposed with a verification request to a mobile communications device associated with the consumer 104, the verification request indicating that the transaction amount is higher than the transaction amount allocated for instant payment and requesting verification. The consumer 104 can then provide verification for instant payment of the full transaction amount, which can be electronically communicated back to the issuer processing server 102 using a computing device. The issuer processing server 102 can then process the payment transaction and record of the assurance payment, as described above.

[0042] The methods and systems discussed herein enable the issuer processing server 102 to provide guaranteed payment to the acquirer processing server 110, enabling instant payment of a payment transaction to the merchant system 108. By using guaranteed payment records, the methods discussed herein enable payment to be guaranteed using a plurality of different payment instruments 106 and a plurality of different transaction types, including e-commerce transactions in which a consumer 104 can remotely initiate a transaction with a merchant system 108, such as over the Internet.

[0043] Issuer processing server

[0044] Figure 2 One embodiment of the issuer processing server 102 of the system 100 is shown. It will be apparent to those of ordinary skill in the relevant art that Figure 2 The embodiment of the issuer processing server 102 shown in FIG. 1 is provided by way of illustration only, and is not exhaustive of all possible configurations of the issuer processing server 102 suitable for performing the functions discussed herein. For example, Figure 6 The computer system 600, shown in FIG. 6 and discussed in more detail below, can be a suitable configuration of the issuer processing server 102.

[0045] The issuer processing server 102 can include a receiving device 202. The receiving device 202 can be configured to receive data over one or more networks via one or more network protocols. In some embodiments, the receiving device 202 can be configured to receive data over a payment rail, such as a transaction message including sensitive financial data and information transmitted using specially configured infrastructure associated with a payment network 112. In some cases, the receiving device 202 can also be configured to receive data from the consumer 104, computing devices, merchant systems 108, acquirer issuer processing servers 110, payment networks 112, blockchain networks 114, and other entities via additional networks, such as the Internet. In some embodiments, the receiving device 202 can include multiple devices, such as different receiving devices for receiving data over different networks, such as a first receiving device for receiving data over a payment rail and a second receiving device for receiving data over the Internet. The receiving device 202 can electronically receive transmitted data signals, where data can be superimposed on the data signals and decoded, parsed, read, or otherwise obtained by the receiving device 202 by receiving the data signals. In some cases, the receiving device 202 can include a parsing module for parsing received data signals to obtain data superimposed thereon. For example, the receiving device 202 can include a parser program configured to receive data signals and transform the received data signals into usable inputs for execution by processing devices to implement the functions of the methods and systems described herein.

[0046] The receiving device 202 can be configured to receive a data signal electronically transmitted by the payment network 112, which can be superimposed with or otherwise include a transaction message for a payment transaction. The transaction message can be formatted according to one or more standards, such as the ISO 8583 standard, and include a plurality of data elements, including data elements configured to store a primary account number, a transaction amount, a guaranteed payment data, and additional transaction data. In some embodiments, the receiving device 202 can also be configured to receive a data signal electronically transmitted by a computing device associated with the consumer 104, such as the data signal can be superimposed with an allocation request. The allocation request can include identification information associated with a transaction account and an allocation amount. The allocation request can also include additional information associated with a future purchase for which an instant payment is requested.

[0047] The issuer processing server 102 can also include a communication module 204. The communication module 204 can be configured to transmit data between the modules, engines, databases, memories, and other components of the issuer processing server 102 for performing the functions discussed herein. The communication module 204 can be comprised of one or more communication types and utilize various communication methods for communication within a computing device. For example, the communication module 204 can include a bus, a contact pin connector, a wire, etc. In some embodiments, the communication module 204 can also be configured to communicate between internal components of the issuer processing server 102 and external components of the issuer processing server 102, such as externally connected databases, display devices, input devices, etc. The issuer processing server 102 can also include a processing device. The processing device can be configured to perform the functions of the issuer processing server 102 discussed herein as will be apparent to those of skill in the relevant art. In some embodiments, the processing device can include and / or be comprised of a plurality of engines and / or modules specifically configured to perform one or more functions of the processing device, such as a query module 210, a generation module 212, a signature module 214, a verification module 216, etc. As used herein, the term "module" can be software or hardware specifically programmed to receive inputs, perform one or more processes using the inputs, and provide outputs. The inputs, outputs, and processes performed by the various modules will be apparent to those of skill in the art based upon this disclosure.

[0048] The issuer processing server 102 can include an account database 206. The account database 206 can be configured to store a plurality of account profiles 208 using a suitable data storage format and schema. The account database 206 can be a relational database that utilizes a structured query language to store, identify, modify, update, access, etc. structured data sets stored therein. Each account profile 208 can be a structured data set configured to store data related to a transaction account. Each account profile 208 can include at least a primary account number and an account balance. In some cases, the account profile 208 can also include additional identifying information, such as an identification value to be used in allocation requests and other data exchanges. The account profile 208 can also include additional information suitable for performing the functions discussed herein, such as communication details for sending communications to the consumer 104 or other entity associated with the transaction account, such as details for sending a verification request to a computing device that is used to verify an instant payment amount in a payment transaction.

[0049] The issuer processing server 102 can include a query module 210. The query module 210 can be configured to perform queries on databases to identify information. The query module 210 can receive one or more data values or query strings and can execute the query string based on an indicated database, such as the account database 206, to identify information stored therein. The query module 210 can then output the identified information to an appropriate engine or module of the issuer processing server 102 as needed. The query module 210 may, for example, perform a query on the account database 206 to identify an account profile 208 related to a transaction account used in a payment transaction based on a correspondence between a primary account number stored therein and a primary account number stored in a corresponding data element included in a received transaction message for the payment transaction.

[0050] The issuer processing server 102 can also include a generation module 212. The generation module 212 can be configured to receive one or more instructions for data generation, can generate data, and can output the generated data to another module or engine of the issuer processing server 102. In some cases, the instructions for generating data can be accompanied by data used in the generation. For example, the generation module 212 can be configured to generate a guaranteed payment record for a payment transaction, which can be generated based on a received transaction message or data included therein. In cases where the guaranteed payment record is a blockchain transaction, the generation module 212 can be configured to generate a destination address for the blockchain transaction using a public key, such as can be parsed from guaranteed payment data stored in a corresponding data element included in the received transaction message.

[0051] In some embodiments, the issuer processing server 102 can include a signing module 214. The signing module 214 can be configured to receive data as input, can digitally sign the data, and can output the digitally signed data. In some instances, the signing module 214 can also receive one or more keys and / or algorithms to be used in the signature. In other cases, the signing module 214 can identify (e.g., via the querying module 210) one or more keys and / or algorithms to be used to digitally sign the input data. The signing module 214 may, for example, digitally sign a blockchain transaction using a private key associated with the issuer processing server 102 and an algorithm associated with the corresponding blockchain network 114 prior to submitting the blockchain transaction to the blockchain network 114.

[0052] The issuer processing server 102 can also include a verification module 216. The verification module 216 can be configured to receive data, can perform verification of the data, and can output a result of the verification (e.g., success, failure, partial success, etc.) to another module or engine of the issuer processing server 102. For example, the verification module 216 can be configured to verify a received transaction message indicated for an instant payment as corresponding to a previously received allocation request, e.g., by comparing information provided in the allocation request to data in corresponding data elements stored in the transaction message. The verification module 216 can also be configured to use conventional methods to substantially verify a payment transaction for approval or rejection, e.g., to verify that a transaction account has sufficient balance for the payment transaction, to verify that the transaction has low fraud likelihood. Additional verifications performed as part of conventional processing of payment transactions will be apparent to those of skill in the relevant art.

[0053] The issuer processing server 102 can also include a sending device 218. The sending device 218 can be configured to send data over one or more networks via one or more network protocols. In some embodiments, the sending device 218 can be configured to send data over a payment rail, such as using specially configured infrastructure associated with the payment network 112 to transmit transaction messages including sensitive financial data and information, such as identified payment credentials. In some cases, the sending device 218 can be configured to send data to the consumer 104, computing devices, the merchant system 108, the acquirer processing server 110, the payment network 112, the blockchain network 114, and other entities via an alternative network, such as the Internet. In some embodiments, the sending device 218 can be composed of multiple devices, such as different sending devices for sending data over different networks, such as a first sending device for sending data over a payment rail and a second sending device for sending data over the Internet. The sending device 218 can electronically send data signals with superimposed data that can be parsed by a receiving computing device. In some cases, the sending device 218 can include one or more modules for superimposing, encoding, or otherwise formatting data to a data signal suitable for transmission.

[0054] The sending device 218 can be configured to electronically send a data signal to the payment network 112 that is superimposed with or otherwise includes a response transaction message that can indicate approval or denial of a corresponding payment transaction, and can also include data corresponding to a guaranteed payment record, if applicable. The sending device 218 can also be configured to electronically send a data signal to the blockchain network 114 or computing nodes associated therewith that can be superimposed with a blockchain transaction that is a guaranteed payment record for publication to a corresponding blockchain. In some embodiments, the sending device 218 can also be configured to electronically send a data signal to a computing device associated with the consumer 104, such as for communicating a verification request that requests verification of a payment transaction for an instant payment.

[0055] The issuer processing server 102 can also include a memory 220. The memory 220 can be configured to store data for use by the issuer processing server 102 in performing the functions discussed herein. The memory 220 can be configured to store data using suitable data formatting methods and schema, and can be any suitable type of memory, such as read-only memory, random access memory, etc. The memory 220 can include, for example, currency and geographic location associations, 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 can be suitable for use by the issuer processing server 102 in performing the functions disclosed herein when executed, as will be apparent to those of skill in the relevant art.

[0056] Guaranteed processing of payment transactions

[0057] Figure 3A and 3B A process for processing a guaranteed payment transaction to make an immediate payment to a merchant through a guaranteed payment record is shown.

[0058] In step 302, the receiving device 202 of the issuer processing server 102 can receive a disbursement request electronically submitted by the consumer 104 (e.g., through a suitable computing device) for disbursement of an amount for a guaranteed immediate payment for an upcoming transaction. The disbursement request can include at least a guaranteed amount and an identification value associated with a corresponding transaction account. In step 304, the querying module 210 of the issuer processing server 102 can perform a query on the account database 206 to deduct the guaranteed amount from an account balance included in an account profile 208 included in the account database 206 that includes the identification value included in the disbursement request. In some cases, the identification value can be a primary account number corresponding to the relevant transaction account.

[0059] In step 306, the acquirer processing server 110 can receive transaction data for the payment transaction from the merchant system 108. The transaction data can include payment details read from the payment instrument 106, including at least a primary account number, a transaction amount, an indication that an instant payment is to be made, and any other data used in processing the payment transaction, such as a transaction time, a transaction date, a geographic location, consumer data, merchant data, point-of-sale data, product data, offer data, loyalty data, reward data, and the like. In step 308, the acquirer processing server 110 can generate an authorization request for the payment transaction. The authorization request can be a transaction message formatted according to one or more standards, such as the ISO 8583 standard, that includes a message type indicator indicating an authorization request and a plurality of data elements, including data elements configured to store a primary account number, a transaction amount, guaranteed payment data, and additional transaction data. The guaranteed payment data can include a destination address or public key associated with the acquirer processing server 110 for receiving a blockchain transaction using the blockchain network 114, and a network identifier associated with the blockchain network 114.

[0060] In step 310, the acquirer processing server 110 can electronically transmit the authorization request to the payment network 112 via a payment rail, which can then forward the authorization request to the issuer processing server 102 via the payment rail. In step 312, the receiving device 202 of the issuer processing server 102 can receive the authorization request. In step 314, the querying module 210 of the issuer processing server 102 can perform a query of the account database 206 of the issuer processing server 102, identifying an account profile 208 including a primary account number stored in a corresponding data element included in the received authorization request, thereby identifying an account profile 208 related to a transaction account used in the payment transaction.

[0061] In step 316, the verification module 216 of the issuer processing server 102 can verify that a guaranteed amount allocated in the transaction account is sufficient to cover a transaction amount stored in a corresponding data element included in the received authorization request. In the event that the guaranteed amount can be insufficient, step 316 can include requesting and receiving additional verification from the instant payment consumer 104 to the merchant system 108 regarding the full transaction amount, as discussed herein.

[0062] At step 318, the generation module 212 of the issuer processing server 102 can generate a blockchain transaction as a guaranteed payment record for the payment transaction amount to the acquirer processing server 110 in order to instantaneously pay the merchant system 108 for the payment transaction. The blockchain transaction can include a destination address to which the transaction amount is to be paid, provided by the acquirer processing server 110 and included in the guaranteed payment data. In cases where a public key is provided instead of a destination address, the generation module 212 can generate the destination address from the public key using suitable methods and algorithms. At step 320, the signing module 214 of the issuer processing server 102 can digitally sign the generated blockchain transaction using a private key associated with the blockchain network 114 corresponding to the network identifier included in the guaranteed payment data in the received authorization request and suitable algorithms.

[0063] At step 322, the sending device 218 of the issuer processing server 102 can electronically send the digitally signed blockchain transaction to the blockchain network 114 or a respective computing node for publication to the blockchain. In some embodiments, the issuer processing server 102 can be a node of the blockchain network 114. In such embodiments, the issuer processing server 102 can publish the blockchain transaction directly to the blockchain using methods and systems apparent to those of skill in the relevant art. At step 324, the generation module 212 of the issuer processing server 102 can generate a hash of the blockchain transaction by applying the blockchain transaction to one or more suitable hash algorithms.

[0064] At step 326, the generation module 212 of the issuer processing server 102 can generate an authorization response for the payment transaction. The authorization response can be a modification of the received authorization request or a newly generated transaction message formatted according to one or more standards such as the ISO 8583 standard and include a message type indicator indicating the authorization response and a plurality of data elements including a data element configured to store a response code indicating that the payment transaction is approved and a data element configured to store at least the hash of the blockchain transaction. At step 328, the sending device 218 of the issuer processing server 102 can electronically send the authorization response to the payment network 112 over a payment rail, which can then forward the authorization response to the acquirer processing server 110 over the payment rail. At step 330, the acquirer processing server 110 can receive the authorization response.

[0065] At step 332, the acquirer processing server 110 can forward a message indicating that the payment transaction is approved to the merchant system 108 over a suitable communications network, such as over a payment rail associated with the payment network 112. At step 334, the acquirer processing server 110 can verify the guarantee of the payment transaction, and can credit a transaction account associated with the merchant system 108 to pay the transaction amount immediately. The verification of the guarantee can include retrieving the blockchain from the blockchain network 114 and identifying the published blockchain transaction to transfer the transaction amount to the destination address associated with the acquirer processing server 110. The acquirer processing server 110 can also hash the blockchain transaction using the same hashing algorithm used by the issuer processing server 102, and confirm that the hash matches the hash stored in the corresponding data element in the authorization response, such as for additional verification that the blockchain transaction corresponds to the authorization response.

[0066] At steps 336 and 338, the acquirer processing server 110 and the issuer processing server 102 can perform settlement. Settlement can be performed using conventional processes to settle between the issuing financial institution and the acquiring financial institution (e.g., associated with the issuer processing server 102 and the acquirer processing server 110, respectively), as will be apparent to those of skill in the relevant art. In some cases, the blockchain transaction can be used to communicate a guaranteed payment record without actually transferring currency, with conventional settlement being used to pay the transaction amount from the issuing financial institution to the acquiring financial institution. In other cases, the blockchain transaction can be used to communicate a blockchain currency amount (e.g., or an amount related thereto, such as after fees are deducted or added, etc.) equivalent to the transaction amount. In such cases, the settlement performed at steps 336 and 338 can not include the payment of funds.

[0067] Exemplary method for processing a guaranteed electronic transaction

[0068] Figure 4 A method 400 for processing a guaranteed electronic transaction is shown, in which a guaranteed payment record is used to facilitate immediate payment to a merchant for a payment transaction.

[0069] At step 402, a plurality of account profiles can be stored in an account database (e.g., account database 206) of a processing server (e.g., issuer processing server 102), wherein each account profile includes a structured set of data related to a transaction account including at least a transaction account number and an account balance. At step 404, a transaction message related to an electronic transaction can be received by a receiving device (e.g., receiving device 202) of the processing server via a payment network (e.g., payment network 112), wherein the transaction message originates from an acquirer financial institution (e.g., acquirer processing server 110) and is formatted based on one or more criteria, wherein the transaction message includes a plurality of data elements including at least a first data element configured to store a primary account number, a second data element configured to store a transaction amount, a third data element configured to store payment assurance data, and one or more additional data elements configured to store additional transaction data.

[0070] At step 406, a first query can be executed by a querying module (e.g., querying module 210) of the processing server on the account database to identify a particular account profile in which a transaction account number included corresponds to the primary account number stored in the first data element included in the received transaction message. At step 408, the querying module of the processing server can execute a second query on the account database to deduct at least the transaction amount stored in the second data element included in the received transaction message from the account balance included in the identified particular account profile.

[0071] At step 410, a payment assurance record can be generated by a generating module (e.g., generating module 212) of the processing server, wherein the payment assurance record includes at least the transaction amount and data associated with the payment assurance data stored in the third data element included in the received transaction message. At step 412, a return message can be generated by the generating module of the processing server, wherein the return message is formatted based on one or more criteria and includes a plurality of data elements including at least a first data element configured to store a response code indicating approval of the related electronic transaction and a second data element configured to store data associated with the generated payment assurance record.

[0072] At step 414, the generated payment assurance record can be electronically transmitted by a transmitting device (e.g., transmitting device 218) of the processing server to the computing system via a communication network. At step 416, the generated return message can be electronically transmitted by the transmitting device of the processing server to the acquirer financial institution via the payment network.

[0073] In one embodiment, the payment guarantee data stored in the third data element included in the received transaction message can include at least a blockchain network identifier and (i) a public key or (ii) a destination address, the payment guarantee record can be a blockchain transaction for paying the transaction amount stored in the second data element included in the received transaction message to (i) the destination address or (ii) a destination address associated with the public key, and the computing system can be a node in a blockchain network (e.g., the blockchain network 114) corresponding to the blockchain network identifier. In another embodiment, the method 400 can further include generating, by the generation module of the processing server, a destination address associated with the public key using the public key. In another embodiment, the method 400 can further include generating, by the generation module of the processing server, a hash value by applying one or more hash algorithms to the generated payment guarantee record, wherein the data associated with the generated payment guarantee record stored in the second data element included in the return message includes the generated hash value. In yet another embodiment, the method 400 can further include signing, by the signing module (e.g., the signing module 214) of the processing server, the blockchain transaction prior to sending to the computing system.

[0074] In some embodiments, the second query can be performed by the query module prior to the receiving device receiving the transaction message. In another embodiment, the method 400 can further include verifying, by the verification module (e.g., the verification module 216) of the processing server, that the amount deducted from the account balance included in the identified particular account profile via the second query is greater than the transaction amount stored in the second data element included in the received transaction message. In one embodiment, the received transaction message can further include a message type indicator indicating an authorization request. In some embodiments, the generated return message can include a message type indicator indicating an authorization response. In one embodiment, the return message can be generated by the generation module by modifying the received transaction message.

[0075] Payment transaction processing systems and processes

[0076] Figure 5 A transaction processing system and a process 500 for processing payment transactions in the system are shown. The process 500 and steps included therein can be performed by one or more components of the system 100 discussed above, such as the issuer processing server 101, the consumer 104, the payment instrument 106, the merchant system 108, the acquirer processing server 110, the payment network 112, etc. The process 500 is described below using the system 100 as an example. Figure 5The illustrated and hereinafter discussed system and process 500 for processing a payment transaction can utilize a payment rail, which can include computing devices and infrastructure configured and programmed by the entities discussed below, as appropriate, to perform the steps of the process 500, including a transaction processing server 512, which can be associated with one or more payment networks configured to process payment transactions. It will be apparent to those skilled in the relevant art that the process 500 can incorporate the processes illustrated above with respect to one or more steps involved in the processing of a payment transaction. Additionally, the entities discussed herein for performing the process 500 can include one or more computing devices or systems configured to perform the functions discussed below. For example, the merchant 506 can include one or more point-of-sale devices, local communication networks, computing servers, and other devices configured to perform the functions discussed below. Figure 3A , Figure 3B and Figure 4 Additionally, the entities discussed herein for performing the process 500 can include one or more computing devices or systems configured to perform the functions discussed below. For example, the merchant 506 can include one or more point-of-sale devices, local communication networks, computing servers, and other devices configured to perform the functions discussed below.

[0077] In step 520, the issuing financial institution 502 can issue a payment card or other suitable payment instrument to the consumer 504. The issuing financial institution can be a financial institution, such as a bank, or other suitable type of entity that manages and maintains payment accounts and / or payment instruments used in conjunction with payment accounts that can be used to fund payment transactions. The consumer 504 can have a transaction account with the issuing financial institution 502, and the issued payment card is associated with the transaction account such that when used to fund a payment transaction, the payment transaction is funded by the associated transaction account. In some embodiments, the payment card can be issued to the consumer 504 in a physical form. In other embodiments, the payment card can be a virtual payment card or otherwise provided to the consumer 504 in an electronic format.

[0078] In step 522, the consumer 504 can present the issued payment card to the merchant 506 for use in funding a payment transaction. The merchant 506 can be a business, another consumer, or any entity that can participate in a payment transaction with the consumer 504. The payment card can be presented by the consumer 504 via providing the physical card to the merchant 506, electronically transmitting (e.g., via near field communication, wireless transmission, or other suitable type and protocol of electronic transmission) payment details of the payment card, or initiating transmission of the payment details to the merchant 506 via a third party. The merchant 506 can receive the payment details (e.g., by electronic transmission, by reading them from a physical payment card, etc.), which can include at least a transaction account number associated with the payment card and / or the associated transaction account. In some cases, the payment details can include one or more application cryptograms, which can be used in the processing of the payment transaction.

[0079] In step 524, merchant 506 can enter transaction details into a point-of-sale computing system. The transaction details can include payment details provided by consumer 504 in association with a payment card and additional details associated with the transaction, such as transaction amount, time and / or date, product data, offer data, loyalty data, reward data, merchant data, consumer data, point-of-sale data, and the like. The transaction details can be entered into a point-of-sale system of merchant 506 via one or more input devices, such as an optical bar code scanner configured to scan product bar codes, a keyboard configured to receive product codes entered by a user, and the like. The merchant point-of-sale system can be a specially configured computing device and / or a special purpose computing device that is specifically used to process electronic financial transactions and communicate with a payment network (e.g., over a payment rail). The merchant point-of-sale system can be an electronic device running a point-of-sale system application, where the application causes the electronic device to receive electronic financial transaction information and transmit it to a payment network. In some embodiments, merchant 506 can be an online retailer in an electronic commerce transaction. In such embodiments, the transaction details can be entered into a shopping cart or other repository for storing transaction data in an electronic transaction, as will be apparent to those of skill in the relevant art.

[0080] In step 526, merchant 506 can electronically transmit a data signal superimposed with transaction data to a gateway processor 508. Gateway processor 508 can be an entity configured to receive transaction details from merchant 506 for formatting and transmission to an acquiring financial institution 510. In some instances, gateway processor 508 can be associated with multiple merchants 506 and multiple acquiring financial institutions 510. In such instances, gateway processor 508 can receive transaction details for multiple different transactions involving various merchants, which can be forwarded to the appropriate acquiring financial institution 510. By establishing relationships with multiple acquiring financial institutions 510 and having the necessary infrastructure to communicate with the financial institutions using payment rails, such as using application programming interfaces associated with gateway processor 508 or the financial institutions for data submission and retrieval, gateway processor 508 can act as an intermediary to enable merchants 506 to conduct payment transactions via a single communication channel and formatted with gateway processor 508 without having to maintain relationships with multiple acquiring financial institutions 510 and payment processors and the hardware associated therewith. Acquiring financial institution 510 can be a financial institution, such as a bank, or other entity that manages and controls payment accounts and / or payment instruments used in association with payment accounts. In some instances, acquiring financial institution 510 can control a transaction account of merchant 506. In some instances, a single financial institution can operate as both an issuing financial institution 502 and an acquiring financial institution 510.

[0081] The data signal transmitted from the merchant 506 to the gateway processor 508 can be superimposed with transaction details of the payment transaction, which can be formatted based on one or more standards. In some embodiments, the standards can be set by the gateway processor 508, which can use a unique proprietary format for transmitting transaction data to / from the gateway processor 508. In other embodiments, a common standard can be used, such as the ISO 8583 standard by the International Organization for Standardization. The standard can dictate the types of data that can be included, the formatting of the data, how the data is stored and transmitted, and other standards for transmitting transaction data to the gateway processor 508.

[0082] In step 528, the gateway processor 508 can parse the transaction data signal to obtain the transaction data superimposed thereon, and can format the transaction data as needed. The formatting of the transaction data can be performed by the gateway processor 508 based on proprietary standards of the gateway processor 508 or an acquiring financial institution 510 associated with the payment transaction. The proprietary standards can dictate the types of data included in the transaction data and the format of the data storage and transmission. The acquiring financial institution 510 can be identified by the gateway processor 508 using the transaction data, such as by parsing the transaction data (e.g., deconstructing into data elements) to obtain an account identifier associated with the acquiring financial institution 510 included therein. In some instances, the gateway processor 508 can then format the transaction data based on the identified acquiring financial institution 510 so as to comply with the formatting standards specified by the acquiring financial institution 510. In some embodiments, the identified acquiring financial institution 510 can be associated with the merchant 506 participating in the payment transaction, and in some cases, can manage a transaction account associated with the merchant 506.

[0083] In step 530, the gateway processor 508 can electronically transmit the data signal superimposed with the formatted transaction data to the identified acquiring financial institution 510. The acquiring financial institution 510 can receive the data signal and parse the signal to obtain the formatted transaction data superimposed thereon. In step 532, the acquiring financial institution can generate an authorization request for the payment transaction based on the formatted transaction data. The authorization request can be a special format of a transaction message formatted according to one or more standards, such as the ISO 8583 standard and standards set by a payment processor (e.g., a payment network) for processing payment transactions. The authorization request can be a transaction message including a message type indicator indicating the authorization request, which can indicate that the merchant 506 involved in the payment transaction is requesting a payment or a payment offer for the transaction from the issuing financial institution 502. The authorization request can include a plurality of data elements each configured to store data as set in the associated standards, such as for storing an account number, an application cryptogram, a transaction amount, issuing financial institution 502 information, etc.

[0084] In step 534, acquiring financial institution 510 may electronically send the authorization request to transaction processing server 512 for processing. Transaction processing server 512 may be comprised of one or more computing devices that are part of a payment network configured to process payment transactions. In some embodiments, the authorization request may be sent by a transaction processor at acquiring financial institution 510 or another entity associated with the acquiring financial institution. The transaction processor may be one or more computing devices that include multiple communication channels for communicating with transaction processing server 512 and for transmitting transaction messages and other data to and from transaction processing server 512. In some embodiments, the payment network associated with transaction processing server 512 may own or operate each transaction processor, allowing the payment network to maintain control over the communication of transaction messages to and from processing server 512 for network and information security purposes.

[0085] In step 536, transaction processing server 512 may perform value-added services for the payment transaction. Value-added services may be services specified by issuing financial institution 502 that provide additional value to issuing financial institution 502 or consumer 504 when processing the payment transaction. Value-added services may include, for example, fraud scoring, transaction or account control, account mapping, offer redemption, loyalty processing, and the like. For example, when transaction processing server 512 receives a transaction, a fraud score for the transaction may be calculated based on the data included therein and one or more fraud scoring algorithms and / or engines. In some cases, transaction processing server 512 may first identify the issuing financial institution 502 associated with the transaction and then identify any services instructed by the issuing financial institution 502 to be performed. The issuing financial institution 502 may be identified, for example, by data included in a specific data element included in the authorization request (e.g., an issuer identification number). In another example, the issuing financial institution 502 may be identified by a primary account number stored in the authorization request, for example, by using a portion of the primary account number (e.g., a bank identification number, an issuer identification number, etc.).

[0086] In step 538, transaction processing server 512 may electronically transmit the authorization request to issuing financial institution 502. In some cases, the authorization request may be modified, or additional data may be included in or sent along with the authorization request as a result of value-added services performed by transaction processing server 512. In some embodiments, the authorization request may be transmitted to a transaction processor located at issuing financial institution 502 or an entity associated therewith (e.g., owned or operated by transaction processing server 512), which may forward the authorization request to issuing financial institution 502.

[0087] In step 540, the issuing financial institution 502 can authorize the transaction account to fund the payment transaction. The authorization can be based on the available credit line of the transaction account and the transaction amount of the payment transaction, the fraud score provided by the transaction processing server 512, and other considerations apparent to those of skill in the relevant art. The issuing financial institution 502 can modify the authorization request to include a response code indicating approval of the payment transaction (e.g., or indicating denial if the transaction is denied). The issuing financial institution 502 can also modify the message type indicator of the transaction message to indicate that the transaction message is changed to an authorization response. In step 542, the issuing financial institution 502 can send (e.g., through a transaction processor) the authorization response to the transaction processing server 512.

[0088] In step 544, the transaction processing server 512 can forward the authorization response to the acquiring financial institution 510 (e.g., through a transaction processor). In step 546, the acquiring financial institution can generate a response message indicating that the payment transaction is approved or denied, as indicated in the response code of the authorization response, and can send the response message to the gateway processor 508 using the standards and protocols set by the gateway processor 508. In step 548, the gateway processor 508 can forward the response message to the merchant 506 using the appropriate standards and protocols. In step 550, assuming the transaction is approved, the merchant 506 can then provide the product purchased by the consumer 504 to the consumer 504 as part of the payment transaction.

[0089] In some embodiments, once the process 500 is complete, payment from the issuing financial institution 502 to the acquiring financial institution 510 can be performed. In some cases, the payment can be made immediately or within one business day. In other cases, the payment can be made after a period of time and in response to a clearing request submitted by the acquiring financial institution 510 to the issuing financial institution 502 through the transaction processing server 512. In such cases, the clearing request for multiple payment transactions can be aggregated into a single clearing request, which the transaction processing server 512 can use to identify who and to whom to make the overall payment in order to settle the payment transactions.

[0090] In some cases, the system can also be configured to perform processing of payment transactions in cases where a communication path can not be available. For example, if the issuing financial institution is not available to perform authorization of a transaction account (e.g., at step 540), the transaction processing server 512 can be configured to perform authorization of the transaction on behalf of the issuing financial institution 502. Such an action can be referred to as "stand-in processing," where the transaction processing server "stands in" for the issuing financial institution 502. In such cases, the transaction processing server 512 can utilize rules set by the issuing financial institution 502 to determine approval or denial of the payment transaction, and can modify the transaction message accordingly before forwarding to the acquiring financial institution 510 in step 544. The transaction processing server 512 can retain data associated with the transaction that it stand-in processed, and can transmit the retained data to the issuing financial institution 502 once communication is reestablished. The issuing financial institution 502 can then process the transaction account accordingly to account for the time of lost communication.

[0091] In another example, if the transaction processing server 512 is not available to submit an authorization request by the acquiring financial institution 510, the transaction processor at the acquiring financial institution 510 can be configured to perform processing of the transaction processing server 512 and the issuing financial institution 502. This transaction processor can include rules and data suitable for determining approval or denial of a payment transaction based on data included therein. For example, the issuing financial institution 502 and / or the transaction processing server 512 can set limits on transaction types, transaction amounts, etc., which can be stored in the transaction processor and used to determine approval or denial of a payment transaction based thereon. In such cases, the acquiring financial institution 510 can receive an authorization response for a payment transaction even if the transaction processing server 512 is not available, thereby ensuring that transactions are processed and do not experience downtime even in cases of unavailable communication. In such cases, the transaction processor can store transaction details of the payment transaction, which can be transmitted to the transaction processing server 512 (e.g., and from there to the associated issuing financial institution 502) once communication is reestablished.

[0092] In some embodiments, the transaction processor can be configured to include multiple different communication channels that can utilize multiple communication cards and / or devices to communicate with the transaction processing server 512 to transmit and receive transaction messages. For example, the transaction processor can be composed of multiple computing devices, each having multiple communication ports connected to the transaction processing server 512. In such embodiments, the transaction processor can cycle through the communication channels when transmitting transaction messages to the transaction processing server 512 to mitigate network congestion and ensure faster, smoother communication. Furthermore, in cases where a communication channel can be interrupted or unavailable, an alternative communication channel is thus available to further increase uptime of the network.

[0093] In some embodiments, the transaction processor can be configured to communicate directly with other transaction processors. For example, the transaction processor at the acquiring financial institution 510 can identify that the authorization request involves the issuing financial institution 502 that does not require value-added services (e.g., by a bank identification number or issuer identification number included in the transaction message). The transaction processor at the acquiring financial institution 510 can then send the authorization request directly to the transaction processor at the issuing financial institution 502 (e.g., without the authorization request passing through the transaction processing server 512), where the issuing financial institution 502 can process the transaction accordingly.

[0094] The methods discussed above for processing payment transactions utilize a variety of communication methods using multiple communication channels, and include fail-safe measures to provide for the processing of payment transactions at multiple points in the process and at multiple locations in the system, and to ensure that communications reach their destinations successfully even in the event of an interruption, which can provide a robust system that ensures payment transactions are always processed successfully with minimal errors and interruptions. This advanced network and its infrastructure and topology are often referred to as a “payment rail,” in which transaction data can be submitted from merchants at millions of different points of sale to the payment rail, routed through the infrastructure to the appropriate transaction processing server 512 for processing. The payment rail can make it possible for general purpose computing devices, without specialized programming and / or configuration, to not properly format communications or submit communications to the rail. Through the specialized use of computing devices, computing devices can be configured to submit transaction data to the appropriate entity (e.g., gateway processor 508, acquiring financial institution 510, etc.) for processing using this advanced network, and can quickly and efficiently receive a response regarding the ability of the consumer 504 to fund the payment transaction.

[0095] Computer system architecture

[0096] Figure 6 A computer system 600 is shown in which embodiments of the present disclosure, or portions of embodiments, can be implemented as computer-readable code. For example, Figure 1 The issuer processing server 102 of Figure 3A , Figure 3B , Figure 4 and Figure 5 may be implemented in computer system 600 using hardware, software, firmware, non-transitory computer readable media having instructions stored thereon, or a combination thereof and can be implemented in one or more computer systems or other processing systems.

[0097] If programmable logic is used, the logic can be implemented using a specially programmed processor, using application specific integrated circuits, programmable logic arrays, hardwired circuits, or using any combination of the preceding. Those of ordinary skill in the art will recognize how to best implement the disclosed embodiment depending upon the particular requirements of the electrical system at hand. It is expected that one of ordinary skill, upon inspecting the following specification and / or figures, will be able to implement appropriate software, firmware, and / or hardware to implement the disclosed subject matter.

[0098] The processor units or devices discussed herein can be single processor, multiple processor, or combinations thereof. The processor devices can have one or more processor "cores." The terms "computer program medium," "non-transitory computer readable medium" and "computer usable medium" as discussed herein are generally used to refer to tangible media such as removable storage unit 618, removable storage unit 622, and the hard disk installed in hard disk drive 612.

[0099] Various embodiments of the present disclosure are described in terms of this example computer system 600. Those skilled in the relevant art will recognize how to implement the present disclosure using other computer systems and / or computer architectures. Although the operations in the various embodiments can have been described as a sequential process, some of the operations can in fact be performed in parallel, concurrently, and / or in a distributed environment and with program code stored locally or remotely for access by single or multi-processor machines. In addition, in some embodiments the order of operations can be rearranged without departing from the spirit of the disclosed subject matter.

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

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

[0102] In some embodiments, the secondary storage 610 can include additional devices for allowing computer programs or other instructions to be loaded into the computer system 600. Such devices can include, for example, a removable storage unit 622 and an interface 620. Examples of such devices can include a program cartridge and cartridge interface (such as that found in video game systems), a removable memory chip (for example, an EPROM, a PROM, etc.) and associated socket, and other removable storage units 622 and interfaces 620, which will be apparent to those of relevant skill.

[0103] Data stored in the computer system 600 (for example, in the main memory 608 and / or the secondary storage 610) can be stored on any type of suitable computer-readable media, such as optical storage (for example, optical discs like CDs, DVDs, Blu-ray discs, etc.) or magnetic tape storage (for example, hard disk drives). The data can be configured in any type of suitable database configuration, such as a relational database, a structured query language (SQL) database, a distributed database, an object database, etc. Suitable configurations and storage types will be apparent to persons of relevant skill.

[0104] The computer system 600 can also include a communications interface 624. The communications interface 624 can be configured to allow software and data to be transferred between the computer system 600 and external devices. Exemplary communications interfaces 624 can include a modem, a network interface (for example, an Ethernet card), a communications port, a PCMCIA slot and card, etc. Software and data transferred via the communications interface 624 can be in the form of signals, which can be electronic, electromagnetic, optical, or other signals as will be apparent to persons of relevant skill. The signals can travel via the communications path 626, which can be configured to carry the signals and can employ wire, cable, fiber optics, phone lines, cellular phone links, radio frequency links, etc.

[0105] The computer system 600 can also include a display interface 602. The display interface 602 can be configured to allow data to be transferred between the computer system 600 and an external display 630. Exemplary display interfaces 602 can include a High-Definition Multimedia Interface (HDMI), a Digital Visual Interface (DVI), a Video Graphics Array (VGA), etc. The display 630 can be any appropriate type of display for displaying data transmitted via the display interface 602 of the computer system 600, 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.

[0106] The computer program medium and the computer-usable medium can refer to memories such as the main memory 608 and the secondary memory 610, which can be memory semiconductors, for example, DRAMs, etc. These computer program products can be means for providing software to the computer system 600. The computer programs, for example, computer control logic, can be stored in the main memory 608 and / or the secondary memory 610. The computer programs can also be received via the communications interface 624. These computer programs, when executed, can enable the computer system 600 to implement the methods as discussed herein. In particular, the computer programs, when executed, can enable the processor device 604 to implement the methods as illustrated by the flowcharts of FIGS. 1-8, as discussed herein. Accordingly, such computer programs can represent controllers of the computer system 600. Where the disclosure is implemented using software, the software can be stored in a computer program product and loaded into the computer system 600 using the removable storage drive 614, the interface 620, and the hard disk drive 612, or the communications interface 624. Figure 3A 、 Figure 3B 、 Figure 4 and Figure 5 Accordingly, such computer programs can represent controllers of the computer system 600. Where the disclosure is implemented using software, the software can be stored in a computer program product and loaded into the computer system 600 using the removable storage drive 614, the interface 620, and the hard disk drive 612, or the communications interface 624.

[0107] The processor device 604 can include one or more modules or engines configured to perform the functions of the computer system 600. Each module or engine can be implemented using hardware and, in some cases, software, such as program code and / or programs corresponding to programs stored in the main memory 608 or the secondary memory 610. In such cases, the program code can be compiled by the processor device 604 (e.g., by a compiling module or engine) prior to execution by the hardware of the computer system 600. For example, the program code can be source code written in a programming language that is translated into a lower level language, such as assembly language or machine code, for execution by the processor device 604 and / or any additional hardware components of the computer system 600. The compilation process can include the use of lexical analysis, preprocessing, parsing, semantic analysis, syntax-directed translation, code generation, code optimization, and any other techniques that can be applicable to translating program code into a lower level language suitable for controlling the computer system 600 to perform the functions disclosed herein. Those skilled in the relevant art will appreciate that such a process results in the computer system 600 being a specially configured computer system 600 that is uniquely programmed to perform the functions described above.

[0108] Among other features, the technology consistent with the present disclosure provides systems and methods for processing guaranteed electronic transactions. While various example embodiments of the disclosed systems and methods have been described above, it should be understood that they have been presented by way of example only, and not limitation. There are many other ways to implement the disclosed technology. Although particular embodiments of the present disclosure have been described, alternatives, modifications, equivalents, and further refinements of different parts of the described embodiments are possible. Numerous specific details of the disclosure have been set forth in this disclosure in order to provide a thorough understanding of the disclosure. However, it should be understood that implementation of those without the specific details would be within the scope and spirit of the basic principles described herein. Furthermore, the ordering of the operations is not essential, unless otherwise indicated.

Claims

1. A method for processing a guaranteed electronic transaction, comprising: Prior to initiating a payment transaction, receiving, by a receiving device of the processing server, an allocated amount associated with the transaction account selected by the user, the allocated amount selected by the user corresponding to a portion of the account balance reserved for future transactions; receiving, by the receiving device of the processing server, a transaction message related to an electronic transaction via a payment network, wherein the transaction message includes a primary account number, a transaction amount, payment guarantee data, and additional transaction data; executing, by a processing device of the processing server, a first query on an account database to identify a specific account profile, wherein the transaction account number included in the specific account profile corresponds to the primary account number included in the received transaction message; performing, by the processing device of the processing server, a second query on the account database and deducting one of the transaction amount included in the received transaction message or the user-selected allocation amount from the portion of the account balance included in the identified particular account profile; generating, by the processing device of the processing server, a record of the payment guarantee; generating, by the processing device of the processing server, a return message, wherein the return message includes a response code indicating approval of the related electronic transaction and data associated with the generated record of the payment guarantee; electronically transmitting, by a transmitting device of the processing server, the generated record of the payment guarantee to a computing system via a communications network; and The sending device of the processing server electronically sends the generated return message to the acquiring financial institution via the payment network.

2. The method according to claim 1, wherein The payment guarantee data included in the received transaction message includes at least a blockchain network identifier and a public key or a destination address, The record of the payment guarantee is a blockchain transaction for paying the transaction amount included in the received transaction message or the allocated amount selected by the user to the destination address or the destination address associated with the public key, and The computing system is a node in the blockchain network corresponding to the blockchain network identifier.

3. The method of claim 2, further comprising: The destination address associated with the public key is generated by the processing device of the processing server using the public key.

4. The method of claim 2, further comprising: The processing device of the processing server generates a hash value by applying one or more hash algorithms to the generated record of the payment guarantee, wherein The data associated with the generated payment guarantee record included in the return message includes the generated hash value.

5. The method of claim 2, further comprising: The blockchain transaction is signed by the processing device of the processing server before being sent to the computing system.

6. The method of claim 1, wherein: The second query is performed by the processing device block before the transaction message is received by the receiving device.

7. The method of claim 6, further comprising: Verifying, by the processing device of the processing server, that the amount deducted from the account balance included in the identified specific account profile via the second query is greater than the transaction amount included in the received transaction message.

8. The method of claim 1, wherein: The received transaction message also includes a message type indicator indicating an authorization request.

9. The method of claim 1, wherein: The generated return message includes a message type indicator indicating an authorization response.

10. The method of claim 1, wherein: The return message is generated by the processing device by modifying the received transaction message.

11. A system for processing guaranteed electronic transactions, comprising: The receiving device of the processing server is configured to Prior to initiating a payment transaction, receiving a user-selected allocation associated with the transaction account, the user-selected allocation corresponding to a portion of the account balance reserved for future transactions; and receiving, via a payment network, a transaction message related to an electronic transaction, wherein the transaction message includes a primary account number, a transaction amount, payment guarantee data, and additional transaction data; The processing device of the processing server is configured to performing a first query on an account database to identify a specific account profile, wherein the transaction account number included in the specific account profile corresponds to the primary account number included in the received transaction message, and performing a second query on the account database for deducting one of the transaction amount or the user-selected allocation amount included in the received transaction message from the portion of the account balance included in the identified particular account profile; wherein the processing device of the processing server is configured to generate a record of the payment guarantee, and a return message, wherein the return message includes: a response code indicating approval of the related electronic transaction, and data associated with a record of the generated payment guarantee; and The sending device of the processing server is configured to electronically transmitting a record of the generated payment guarantee to a computing system via a communications network, and The generated return message is electronically sent to the acquiring financial institution via the payment network.

12. The system of claim 11, wherein: The payment guarantee data included in the received transaction message includes at least a blockchain network identifier and a public key or a destination address, The record of the payment guarantee is a blockchain transaction for paying the transaction amount or the user-selected allocation amount included in the received transaction message to the destination address or the destination address associated with the public key, and The computing system is a node in the blockchain network corresponding to the blockchain network identifier.

13. The system of claim 12, wherein: The processing device of the processing server is further configured to generate the destination address associated with the public key using the public key.

14. The system of claim 12, wherein: The processing device of the processing server is further configured to generate a hash value by applying one or more hashing algorithms to the generated record of the payment guarantee, and The data associated with the generated payment guarantee record included in the return message includes the generated hash value.

15. The system of claim 12, wherein: The processing device of the processing server is configured to sign the blockchain transaction before sending it to the computing system.

16. The system of claim 11, wherein: The second query is performed by the processing device prior to receipt of the transaction message by the receiving device.

17. The system of claim 16, further comprising: in, The processing device of the processing server is configured to verify that an amount deducted from the account balance included in the identified specific account profile via the second query is greater than the transaction amount included in the received transaction message.

18. The system of claim 11, wherein: The received transaction message also includes a message type indicator indicating an authorization request.

19. The system of claim 11, wherein: The generated return message includes a message type indicator indicating an authorization response.

20. The system of claim 11, wherein the return message is generated by the processing device by modifying the received transaction message.

Images