US20170308891A1 - System and Method for Distributed Real Time Authorization of Payment Transactions - Google Patents

Abstract

Systems and methods enable the real-time authorization of payment transactions initiated by personal and mobile computing devices. In one embodiment, a financial account server associated with a payment recipient, or payee, is configured to receive a payment data envelope from a payee computing device. The payment data envelope can further include information that allows for the authentication of the payee and payer identities as well as payment restrictions or instructions. The payee financial account server processes the payment data envelope and transmits the envelope to a financial account server associated with the payer. The payer financial server authenticates the payer identification, authorizes the payment transaction, and transmits a transaction status message to the payee financial server, which in turn transmits the message to the payee computing device.

Description

CROSS REFERENCE TO RELATED APPLICATION
• This divisional application claims priority from pending U.S. nonprovisional application Ser. No. 14/227,770 filed Mar. 27, 2014, the entirety of which is incorporated herein.
TECHNICAL FIELD AND BACKGROUND
• The present invention relates generally to the field of payment transactions, and more particularly, to systems and methods for distributed, real-time authorization of payment transactions initiated by a mobile device. The systems and methods are capable performing the functions of existing centralized card networks in a unique and efficient manner, and the systems and methods further permit the implementation of the many features and advantages offered by modern computing devices when conducting payment transactions.
• Traditional payment transactions between a merchant and a consumer often use credit or debit cards that are processed by a card reader or other point of sale (“POS”) device. The POS device reads static, preprogrammed information from a magnetic strip on the card and transmits the information to an issuing bank through an acquirer (merchant) bank and a centralized card network (e.g., VISA™ or MASTERCARD™). The issuing bank approves or declines the transaction and, if approved, transmits a payment to the acquirer bank through the card network. The issuing bank also transmits an approval or decline notice to the POS device that is routed through the card network and the acquirer bank. The card network typically subtracts an interchange fee before routing the payment to the acquirer bank.
• Traditional methods of conducting payment transactions have the disadvantage that the information exchanged cannot be customized for each transaction, and the methods are not capable of taking advantage of opportunities provided by recent advances in computing and mobile technology. To illustrate, it is now possible to initiate payment transactions using personal computers or cellular “smartphones” that are capable of transmitting and receiving a variety of useful information during a payment transaction, such as coupon codes, payment instructions, and additional security features for authenticating a consumer's identity (e.g., biometric information or machine gesture recognition).
• It would, therefore, be advantageous to provide payment transaction systems and methods that are capable of processing customizable payment transactions initiated and conducted by computing devices. It would also be advantageous to provide distributed payment transaction systems and methods that permit direct communication between financial service providers, such as acquirer and issuing banks, without the need to route payment transactions through a centralized card network that deducts interchange fees.
• The systems and methods of the present invention enable the new generation of payment transactions initiated and performed by computing devices and address the requirements needed to bring the such innovations to market by providing a low-cost, highly scalable, and resilient distributed banking and payment platform capable of performing real-time authorization of payment transactions initiated by mobile and other computing devices.
SUMMARY
• According to one embodiment of the invention, a method and system of authorizing payment transactions is provided. The method includes receiving, by a first server associated with a payee financial account, a payment data envelope transmitted by a payee computing device. The payment data envelope includes payer data, encrypted payee data, and payment instructions. The payee financial account server decrypts the encrypted payee data, verifies the payee identity by comparing the payee data in the received payment data envelope to payee data stored in a database, and then transmits the payment data envelope to a second financial server associated with the payer. The payee financial server then receives a transaction status message from the payer financial server indicating whether the payment transaction was authorized.
• In another aspect of the invention, the payer data includes a payer account alias that is transmitted by the payee financial account server to a routing key and management server. In return, the payee financial account server receives, from the routing key and management server, routing information for transmitting the payment data envelope to the payer financial account server.
• According to another embodiment of the invention, a method and system includes receiving, by a first server associated with a payer financial account, a first payment data envelope transmitted by a second server associated with a payee financial account. The payment data envelope includes encrypted payer data, payee data, and payment instructions. The payer financial account server decrypts the encrypted payee data and verifies the payer identity by comparing the payer data in the first payment data envelope to payer data stored in a database. The payer financial account server also determines a whether the payment is authorized or declined. The payer financial server then generates a transaction status message that is transmitted to the payee financial account server.
• In one aspect of the invention, the payee data includes a payee account alias that is transmitted by the payer financial account server to a routing key and management server. In return, the payer financial account server receives, from the routing key and management server, routing information for transmitting the transaction status message to the payee financial account server.
• Another aspect of the invention provides for the receipt of a second payment data envelope containing payer data transmitted by an identity management server associated with the payer and/or generated by a payer computing device. The payer financial account server verifies the payer identity and authorizes the payment transaction by: (1) comparing the payer data in the second payment data envelope to payer data stored in a database; and (2) comparing the payer data in the first payment data envelope to the payer data in the second payment data envelope.
• In yet another aspect of the invention, the encrypted payer data comprises cancellable biometric information.
• In one embodiment of the invention, the payer financial account server authorizes a payment transaction by determining whether data in the payment data envelope complies with one or more payment restrictions associated with the payer and stored in a database on the server. Payment restrictions may include, for instance: a predetermined upper limit on the payment amount; a geographic limitation on the location where the payer can initiate a payment transaction; a limitation on the types of products for which a payer can initiate a payment transaction; and/or a limitation on the identity of the payment recipient for whom the payer can initiate a payment transaction.
• In another embodiment of the invention, a first server associated with a payee financial account facilitates a payment transaction by first storing payee data to a database and associating the payee data with payee transaction data. The first server then receives a first payment data envelope associated with a payment transaction from a payee device where the payment data envelope includes a payer alias, a payee alias, a payee shared secret, and crypto data including encrypted payee data and encrypted payee transaction data. The first server decrypts the encrypted payee data and payee transaction data from the payment data envelope using the payee shared secret. Next, the first server retrieves the stored payee data using the decrypted payee transaction data and compares the decrypted payee data with the retrieved payee data. The first server validates the payee identity through this comparison, and if the identity can be verified, then the first server transmits the payer alias to a routing & key management (“RKM”) server. In return, the first server receives an IP address for a second server associated with a payer financial account. The first server utilizes this IP address to transmit the first payment data envelope to the second server.
• In another aspect of the invention, the first server receives a transaction status message from a second server associated with a payer financial account. The first payment data envelope includes an instruction data array, and the transaction status message includes a transaction flag with a value of authorized or declined. When the transaction flag with a value of authorized is received by the first server, the first server creates a temporary database record of the payment transaction that is used to update a payee account balance. When the transaction flag has a value of declined, the first server transmits the first payment data envelope to an alternate consumer account server based on the instruction data array.
• The method described can also include steps whereby the second server stores a consumer PIN and biometric information and associates the consumer PIN and biometric information with consumer payment information. The second server then receives the first payment data envelope from the first server, and the first payment data envelope includes a consumer shared secret and consumer crypto data including encrypted biometric data, encrypted PIN and encrypted payment information. The second server decrypts the encrypted PIN, biometric information, and payment information from the first payment data envelop using the consumer shared secret and retrieves the stored consumer PIN and biometric information using the decrypted payment information. The second server then compares the decrypted consumer PIN and biometric information with the retrieved consumer PIN and biometric information. The second server authorizes the payment transaction based on the comparison and generates a transaction status message. The transaction status message is transmitted to the first server after obtaining an IP address for the first server from a RKM server.
• Yet another embodiment utilizes the second server to store one or more payment restrictions to a data storage device and associate the one or more payment restrictions with the payer. The second processor server determines whether data in the first payment data envelope or a second payment data envelope complies with the one or more payment restrictions. Payment restrictions may include, for instance: a predetermined upper limit on the payment amount; a geographic limitation on the location where the payer can initiate a payment transaction; a limitation on the types of products for which a payer can initiate a payment transaction; and/or a limitation on the identity of the payment recipient for whom the payer can initiate a payment transaction.
• In another feature of the invention, the first payment data envelope can include payment instructions that are used to determine the amount paid as part of the payment transaction. The payment information can include, for instance, the cost of goods or services along with a gratuity amount to be added to the cost amount or include a discount amount that should be subtracted from the transaction cost amount. The second server uses the payment instructions and payment information to determine the final payment amount that is then included in the transaction status message transmitted to the first server by the second server.
BRIEF DESCRIPTION OF THE DRAWINGS
• Features, aspects, and advantages of the present invention are better understood when the following detailed description of the invention is read with reference to the accompanying figures, in which:
• FIG. 1 is a diagram of a distributed, real-time payment transaction authorization system according to one embodiment;
• FIG. 2 is a data flow diagram illustrating an exemplary payment transaction authorization system and method according to one embodiment of the invention;
• FIG. 3 is an exemplary payment data envelope illustrating payer data;
• FIG. 4 is an exemplary payment data envelope illustrating payer data;
• FIG. 5 is an exemplary payment data envelope illustrating payer and payee data;
• FIG. 6 is an exemplary payment data envelope illustrating payer and payee data;
• FIG. 7 is a data flow diagram illustrating an exemplary payment transaction authorization system and method according to one embodiment of the invention;
• FIG. 8 is a data flow diagram illustrating an exemplary payment transaction authorization system and method according to one embodiment of the invention;
• FIG. 9 is a data flow diagram illustrating an exemplary payment transaction authorization system and method according to one embodiment of the invention; and
• FIG. 10 is a data flow diagram illustrating an exemplary distributed payment authorization system.
DETAILED DESCRIPTION
• The present invention will now be described more fully hereinafter with reference to the accompanying drawings in which exemplary embodiments of the invention are shown. However, the invention may be embodied in many different forms and should not be construed as limited to the representative embodiments set forth herein. The exemplary embodiments are provided so that this disclosure will be both thorough and complete and will fully convey the scope of the invention and enable one of ordinary skill in the art to make, use, and practice the invention.
• Disclosed herein are systems and methods for distributed, real-time authorization of payment transactions. Although the embodiments described herein are generally described with reference to exemplary commercial transactions where a consumer purchases goods or services from a merchant, those skilled in the art will recognize that the systems and methods are applicable to payment transactions generally. Payment transaction types can include, but are not limited to, sales of goods or services, cancellations, product returns or refunds, credit-based transactions, and promotions.
• As used herein, the term “payee” generally describes an individual or entity receiving payment during a transaction, such as a merchant, vendor, retailer, or other seller of goods and services. The term “payer” is intended to generally describe a person or entity that makes a payment during a transaction, such as a purchaser of products or services. The term “payer” may be used interchangeably with the terms “consumer” or “purchaser.” Those skilled in the art will recognize that the roles of a payer and payee in any transaction can be reversed as happens when, for example, a customer returns a product to a merchant for a refund.
• As shown inFIG. 1, a system according to one embodiment of the present invention generally includes a computing device (e.g., an Internet-enabled device) operated by aconsumer101, a computing device associated with apayee102, an identity management service106 (“IdM”), and acomputer system200 associated with one or more financial service providers (“FSP”). TheFSP computer system200 may include one or more network computing devices, such as a financial server associated with apayee account103, a financial server associated with aconsumer account105, and a routing & key management (“RKM”)server104, as well as one or more computing devices associated with FSP employees (not shown). Various components of theFSP computing system200 can be associated with different FSPs, such as when a merchant and consumer utilize financial accounts with separate FSPs.
• TheIdM service106 can include one or more network computing device, such as a server, as well as one or more personal computing devices. Similarly, thepayee computing device102 can be an autonomous device, or it can be networked to a payee computing system (not shown) that includes one or more network computing devices, such as a server, as well as other payee computing devices. A payee computing device can be associated with one or more merchants, such as when an individual person operates two separate businesses and utilizes the same payee computing device to process payment transactions for both businesses. Alternatively, a single merchant may utilize multiple payee computing devices, such as a retailer with numerous sales associates who each utilize a separate payee computing device to process payment transactions.
• The system shown inFIG. 1 is not intended to be limiting, and one of ordinary skill in the art will recognize that the systems and methods of the present invention may be implemented using other suitable hardware or software configurations. For example, theFSP computer system200 may utilize only a single server implemented by one or more computing devices, or a single computing device may implement one or more of thepayee account server103,consumer account server105,RKM server104, and/or the FSP employee computing devices. Further, a single computing device may implement more than one step of the method described herein; a single step may be implemented by more than one computing device; or any other logical division of steps may be used.
• Any suitable computing device can be used to implement theconsumer computing device101, thepayee computing device102, or the components of theFSP computer system200. Theconsumer computing device101, thepayee computing device102, and the computing devices of theFSP system200 can include a processor that communicates with a number of peripheral subsystems via a bus subsystem. These peripheral subsystems may include a memory subsystem (e.g., random access memory), a storage subsystem (e.g., optical, magnetic, or solid-state storage), user input and output subsystems (e.g., a keyboard, mouse, computer monitor, touch-screen display, microphone, or speaker), a networking subsystem, and a communication subsystem. By processing instructions stored on a storage device or in memory, the processors may perform one or more steps of the methods described herein.
• In a preferred embodiment, theconsumer computing device101 and thepayee computing device102 are portable electronic devices that include one or more integrated software applications configured to provide, among other features, a user interface configured to facilitate payment transactions and two-way communication with other electronic devices. Theconsumer computing device101 and thepayee computing device102 can be any type of suitable portable electronic device, including, for example, a cellular phone, a tablet computer, or a laptop computer. The portable electronic device can also be an application-specific device configured for processing payments, such as a merchant checkout terminal, debit/credit card reader, or virtual wallet.
• The software applications integrated with the consumer andpayee computing devices101 &102 are a program, function, routine, applet, or similar module that performs operations on the computing devices to implement the steps of the methods disclosed herein. For example, the application integrated with theconsumer computing device101 may be one or more of a digital wallet application, a coupon application, a merchant loyalty account application, or any other suitable application configured for processing payment transactions. The application integrated with thepayee computing device102 may be a mobile checkout application, a debit/credit card reader application, or any other suitable point of sale application configured for processing payment transactions. The consumer computing device application and the payee computing device application provide a user interface that outputs data and information to, and accept inputs from, a user. Types of data and information processed by the applications include text, images, audio, video, or any other form of information that can exist in a computer-based environment. The user interface can include various display screens that output data to a user as well as functions for accepting user inputs and commands, such as text boxes, pull-down menus, radio buttons, scroll bars, or other suitable functions known to one of ordinary skill in the art.
• The integrated software applications interface with a communication subsystem to provide for a secure connection with other electronic devices. Possible connections include a local area network, a wide area network, an intranet, an Internet connection, a mobile telephone network, a personal area network, or any other suitable connection. The one or more communication subsystems may include a wireless communication system configured to communicate through radio frequency (“RF”), WI-FI (e.g., wireless local area network products based on the Institute of Electrical and Electronics Engineers 802.11 standards), near field communications (“NFC”), Bluetooth, or Low Energy Bluetooth. In one example, a consumer has the ability to make purchases with theconsumer computing device101 by using NFC to wirelessly establish a secure link with thepayee computing device102, which can be connected to (i) a payee computer system configured to facilitate commercial transactions, and (ii) aFSP computer system200.
• A consumer is able to link multiple personal financial accounts to theconsumer computing device101, including checking and savings accounts, credit card accounts, store-specific charge accounts, and electronic funding service accounts (e.g., PAYPAL™). In this manner, a consumer is able to utilize applications integrated with the consumer computing device to purchase goods and services using any of the linked financial accounts. The integrated application can also provide other functions permitting the consumer to receive account balance information, make withdrawals, or deposit funds, among other features.
• Theconsumer computing device101 andpayee computing device102 include asecure element109 to ensure confidentiality of sensitive consumer or payee data (e.g., credit card or bank account numbers) during transmission between electronic devices. Thesecure element109 exists within a removable smart chip or a secure digital card or is embedded within a fixed chip on the computing device. Thesecure element109 includes an integrated software application that performs the functions described herein. Thesecure element109 is capable of storing encrypted consumer orpayee data313 &332 and allowing only trusted applications to access the data. In this manner, thesecure element109 permits software applications to interact with certain functions in thesecure element109 while protecting sensitive data stored in theelement109.
• In an exemplary embodiment, thesecure element109 generates anaccount alias312 &331 for sensitive consumer or payee data; though, theaccount alias312 &331 could also be entered by the consumer or provided by a merchant. Thealias312 &331 is passed to the software applications and transmitted between devices rather than the unencrypted consumer data. Thealiases312 &331 are identifiers for sensitive consumer or payee data that cannot be used to make a payment without validcrypto data313 &332 that corresponds to thealiases312 &331. Thealiases312 &331 do not need to be stored securely because payments made with an alias are not accepted unless the correspondingcrypto data313 &332 is also supplied.
• In the embodiment shown inFIG. 2 depicting a purchase made by a consumer, thecrypto data313 is generated using a shared secret314 that operates on thealias312 or sensitive consumer data. The shared secret314 can be, for example, a symmetric key representing a password, a random number, a counter value that is incremented for each alias value, or any other suitable value. The sharedsecret314 is distributed to thesecure element109 at the time the device is manufactured as well as loaded into thepayee computing device102 and/or thefinancial servers103 &105 before a payment transaction is initiated. Alternatively, the sharedsecret314 is created at the start of a communication session using a key-agreement protocol.
• Those of ordinary skill in the art will recognize that the above-described embodiments are not intended to be limiting, and the system and methods described herein can be implemented using other suitable means for establishing a secure connection, such as public/private key encryption, digital signature authentication, or the Wi-Fi Protected Access 2 standard, among others. Further, in embodiments where the payee is making a payment to the consumer, such as during the return of merchandise to a merchant, skilled artisans will recognize that the process is reversed, and the payee generatescrypto data332 using a shared secret333 that operates on apayee alias331. The payee shared secret333 can be the same or different from the consumer sharedsecret314. In the case of public/private key encryption, the public key will be transmitted as a shared secret314 &333 in thepayment envelope301.
• In one or more embodiments, when a consumer initiates a request to make a payment transaction using sensitive consumer data, the financial server determines whether the combination of thealias312 andcrypto data313 are valid using the shared secret314 that is known to thesecure element109 and the financial server. The financial server uses the shared secret314 to verify thealias312 and thecrypto data313. The financial server receives thealias312 from theconsumer computing device101 via thepayee computing device102 and combines thealias312 with other information, as described above. The financial server can then generate the samecrypto data313 using the sharedsecret314 and received data and compare the result with the receivedcrypto data313. If the comparison indicates that the values are the same, then the payment transaction is authorized and proceeds as normal. Otherwise, the transaction can be denied or authorization can be withheld pending the receipt of additional information.
• Similarly, if a payee initiates a request to make a payment transaction using sensitive payee data, the financial server determines whether the combination of thepayee alias331 and payeecrypto data332 are valid using the sharedsecret333. The financial server receives thealias331 from thepayee computing device102 via theconsumer computing device101 and combines thepayee alias331 with other information. The financial server can then verify the transaction by generating the same payee cryptodata332 using the payee shared secret333 and received data and comparing the result with the receivedpayee crypto data332.
• The flow of data during a consumer payment transaction according to one embodiment is illustrated inFIG. 2. During a payment transaction, theconsumer computing device101 connects to thepayee computing device102. At201, thepayee computing device102 transmits transaction data to theconsumer computing device101 for display to a consumer. Transaction information can include, for instance, a product description, stock-keeping unit (“SKU”), product price, tax payment, merchant identifying information, coupon or discount codes, customer-loyalty information, customer preferences, warranties, product registration information, a transaction identifier, or any other information useful to the consumer.
• Theconsumer computing device101 displays the transaction information to the consumer and requests payment transaction authorization and payment instructions. In authorizing the payment transaction, the consumer optionally specifies payment instructions. As an example, the consumer can specify a gratuity amount; a discount code; the personal financial account from which the payment should be withdrawn or credited; whether payment should be performed in installments amounts, and if so, the duration and amount of the payments; a merchant rating; or any nonstandard payment instructions capable of being processed by the payee and/orFSP computer system200.
• Before transmitting203apayment instructions to thepayee computing device102, theconsumer computing device101 can optionally communicate202 with anIdM service106 associated with the consumer. TheIdM service106 is an account that permits authentication of the consumer's identity and management of the consumer's preferences or other information. Examples include, but are not limited to, social media accounts, employer accounts, or merchant loyalty accounts. TheIdM service106 provides information to the consumer that is relevant to the payment transaction, such as merchant ratings; cost comparisons; and payment transaction rules, restrictions, or controls. TheIdM service106 can also provide information useful for ensuring the security of the transaction, such as cancellable biometric data, a personal identification number (“PIN”), gesture recognition information, federated identification information, or geographic restrictions on where payment transactions can be authorized.
• To illustrate, a consumer may have an IdM service account with his or her employer that utilizes an unique user identification and password and that is associated with an employer-issued credit card for the payment of business expenses. The employer account may include preferences, available discounts, or payment restrictions. Thus, the consumer can be informed of whether the employer has a discount available through a particular merchant or whether the employer limits purchasing authorization to particular merchants, products, geographic locations, or spending limits.
• After receiving authorization and payment instructions from the consumer, a software application integrated with theconsumer computing device101 generates asecure payment envelope301 that is stored to a database on theconsumer computing device101. Thesecure payment envelope301 contains a variety of information to facilitate authentication of the consumer and payee identities, authorization of the payment transaction, and the security of the data transmitted. Anexemplary payment envelope301 generated by theconsumer computing device101 is illustrated inFIG. 3 and includes: (1)transaction data311; (2) aconsumer account alias312; (3)consumer crypto data313; (4) a sharedsecret314; and (5) a paymentinstruction data array315.
• In the event that thepayee computing device102 or one or more components of theFSP computer system200 are not configured to process payment transactions using the inventive systems and methods disclosed herein, thesecure payment envelope301 may include additional information to facilitate authorization of the payment transaction through traditional means, as shown inFIG. 4. The additional information includes, for example: (1) credit card ordebit card numbers316; (2) card expiration dates317; and (3) orother information318 necessary for authentication, such as a consumer's address, zip code, or card verification value (“CVV”).
• At203a&203b,theconsumer computing device101 transmits thepayment envelope301 and the consumer's payment transaction authorization to thepayee computing device102 as well as to theIdM service106. TheIdM service106 can in turn transmit207 thepayment envelope301 to the consumerfinancial server105 to update the consumer's account and facilitate authorization of the payment transaction, as described in more detail below. Alternatively, theconsumer computing device101 can bypass theIdM service106 and transmit thepayment envelope301 directly to the consumerfinancial server105.
• In processing thepayment envelope301, thepayee computing device102 appends payee data to the envelope, as illustrated inFIG. 5. The appended payee data includes information such as: (1)transaction data330; (2) apayee account alias331; (3)payee crypto data332; (4) a sharedsecret333; and (5) aninstruction data array334. In the event that one or more components of theFSP computer system200 or theconsumer computing device101 are not configured to process payment transactions using the inventive systems and methods described herein, thesecure payment envelope301 may further include information to permit authorization of the payment transaction through conventional means, as shown inFIG. 6. The additional information includes, for example,merchant account information335 relating to the payee's account with a FSP (e.g., an acquiring bank that contracts with the merchant to create and maintain an account that allows the merchant to accept credit card and debit card payments).
• Thepayee computing device102 can further appendnonsensitive transaction data306, such as apayer identification342 orterminal data341 identifying the payee name, location, and merchant classification. Thenonsensitive transaction data306 could be utilized by the consumer's FSP orIdM service106 to track the consumer's spending habits. To illustrate, a family can have multiple members utilizing a single checking account where each family member has a separateconsumer computing device101 with anunique payer identification342. If a parent shares an account with a child, and the child uses aconsumer computing device101 three times in a month and purchases (i) $25 in movie tickets, (ii) $50 of gasoline, and (iii) $25 in fast food, thepayer identification342 and merchant categories341 (i.e., terminal data) can be appended to thepayment envelope301 asnonsensitive data306 during each payment transaction. This information is stored to a database on the consumerfinancial server105 orIdM service106 and can be displayed to the parent as a pie chart showing that half of the child's expenditures went to dining and entertainment and half went to transportation.
• Turning again toFIG. 2, after processing thepayment envelope301, thepayee computing device102 transmits204 thepayment envelope301 to the payeefinancial server103 for storage and processing. The payee may be associated with one or more financial accounts so that if the primary payee financial account server is unavailable, thepayment envelope301 can be routed to a secondary payee financial account server.
• Upon receiving thepayment envelope301, the payeefinancial server103 retrieves the payee data from thepayment envelope301, including thepayee account alias331 and thepayee crypto data332. The payee financial server unencrypts the payeecrypto data332 using the shared secret314/333. The payee identity and transaction are authenticated by, for example, comparing payee and transaction information contained in the receivedpayment envelope301 with information stored on the payeefinancial server103. A payment request record is created and stored to a database on the payeefinancial server103.
• Thepayment envelope301 is routed from the payeefinancial server103 to the consumerfinancial server105 using information in theconsumer account alias312. As show in instep205, the payeefinancial server103 can optionally obtain from aRKM server104 additional information useful for communicating with the consumerfinancial server105, such as an Internet Protocol (“IP”) address for the consumerfinancial server105 or a session “token” or “cookie.” A token is a packet of data that contains information identifying a series of related message exchanges and that can facilitate routing and authentication of the transmitted messages. As an example, if theaccount alias312 is a routing number for a personal financial account, the payeefinancial server102 can transmit the routing number to theRKM server104 and receive in return the IP address of the consumerfinancial server105 or a token for establishing a secure communication session. The payeefinancial server103 can save the IP address, token, or other routing information to a database for faster processing until the token expires and the communication session with the consumerfinancial server105 ends.
• After thesecure payment envelope301 is transmitted206 to the consumerfinancial server105, the consumerfinancial server105 retrieves the consumer data from thepayment envelope301, including thepayee account alias312 and theconsumer crypto data313. The consumerfinancial server105 unencrypts the payeecrypto data313 using the sharedsecret314, and a payment request record is created and stored to a database on the consumerfinancial server105. The consumer's identity is authenticated and the payment transaction authorized by comparing data from the receivedpayment envelope301 with consumer or transaction data stored on the consumerfinancial server105. If the consumer and transaction data stored on the consumerfinancial server105 matches the data contained in thepayment envelope301, then the payment transaction is authorized and proceeds as normal. Otherwise, the payment authorization can be denied or authorization can be withheld pending the receipt of additional information. If the payment transaction is authorized, the consumerfinancial server105 will memo post the payment transaction by creating a temporary database record of the payment transaction in the consumer's financial account for which a complete posting to update the consumer account balance will be done as part of an end-of-day batch processing.
• In one embodiment, the consumerfinancial server105 authenticates the consumer identity and authorizes the payment transaction by retrieving207 a copy of thepayment envelope301 or other consumer or transaction data stored in a database on theIdM service106 and comparing this information with thepayment envelope301 received from the payeefinancial server103. If the consumer and transaction data stored with theIdM service106 matches the data contained in thepayment envelope301 received from the payeefinancial server103, then the identity of the consumer is authenticated and the payment transaction is authorized. Authentication through theIdM service106 is optional and can be performed in addition to, or instead of, the authentication and authorization performed by comparing data from the receivedpayment envelope301 with consumer or transaction data stored in a database on the consumerfinancial server105.
• The consumer's identity can be authenticated using cancellable biometrics, a preselected personal identification number (“PIN”), machine gesture recognition, or any other secure and independently known consumer data or combination of such data. The payment transaction can be authorized or declined based on a variety of factors, including, for example: (1) whether the consumer identity was properly authenticated; (2) whether the amount of the payment request exceeds the available account balance; and (3) whether the transaction complies with any rules, restrictions, or controls associated with the consumer's account.
• Authentication of the consumer identity and authorization of a payment transaction can be better understood with reference to the following simplified example. When establishing a personal checking account or IdM service account, a consumer can provide biometric information, like a fingerprint, as well as conventional security information, like a PIN. Biometric information can be secured by making it “cancellable,” which refers to a systematic and repeatable distortion of the biometric information through known techniques, like salting or noninvertible transforms. The consumer can also set one or more rules or restrictions governing the authorization of payment transactions, such as permitting authorization only within the zip code in which the consumer lives. The distorted biometric information is securely stored in asecure element109 of theconsumer computing device101, the consumerfinancial server105, and/or theIdM service106. The PIN is also stored in a database on the consumerfinancial server105 and can optionally be stored on theconsumer computing device101 orIdM service106 or input by a consumer during a payment transaction.
• When authorizing a payment transaction through theconsumer computing device101, the cancellable fingerprint data, PIN, and checking account number are encrypted using the sharedsecret314 and stored in thecrypto data313 of thepayment envelope301. The routing number of the checking account is stored in theconsumer account alias312 of thepayment envelope301. Thepayment envelope301 is transmitted203ato thepayee computing device102 and theIdM service106, and theIdM service106 transmits thepayment envelope301 to the consumerfinancial server105.
• Thepayee computing device102 appends to thepayment envelope301 nonsensitive data, such as the geolocation of thepayee computing device103. Thepayee computing device102 transmits204 thesecure payment envelope301 to the payeefinancial server103, which then transmits206 thepayment envelope301 to the consumerfinancial server105. To properly route thepayment envelope301, the payeefinancial server103 transmits205 the alias312 (checking account routing number) to theRKM server104, which returns an IP address for the appropriate consumerfinancial server105.
• The consumerfinancial server105 unencrypts thecrypto data313 using the sharedsecret314, and compares the received cancellable biometric data and PIN to the cancellable biometric data and PIN stored on the consumerfinancial server105 and associated with the consumer's checking account. The consumerfinancial server105 performs an additional security check by comparing the cancellable biometric data and PIN received from the payeefinancial server103 to the cancellable biometric data and PIN received from theIdM service106. The consumerfinancial server105 also compares the geolocation data contained in theterminal data341 of thepayment envelope301 to the geographic zip code restrictions associated with the consumer's account and stored in a database on the consumerfinancial server105. The payment transaction is authorized if: (1) the cancellable biometric data and PIN received from the payeefinancial server103 matches the corresponding data stored on the consumerfinancial server105 and received from theIdM service106; and (2) the zip code stored in the nonsensitiveterminal data341 of thepayment envelope301 matches the geographic zip code restriction set by the consumer.
• After verifying the consumer identity and payment transaction, the consumerfinancial server105 generates a transaction status message indicating the status of the payment transaction—i.e., that the payment transaction is authorized, declined, or that authorization is withheld pending the receipt of further information. In209, the transaction status message is transmitted to the payeefinancial server103. The transaction status message can also be transmitted to theIdM service106 and/or theconsumer computing device101. In208, the consumerfinancial server105 can optionally obtain from theRKM server104 information useful for communicating with the payeefinancial server103, such as an IP address or a session token.
• If the payment transaction is authorized, the payeefinancial server103 will memo post the payment transaction by creating a temporary database record of the payment transaction in the payee's account. In the event that the payment transaction is not authorized, the payeefinancial server103 can route thepayment envelope301 to an alternate consumer financial account server listed in theinstruction data array315. If the alternate consumer financial account also declines the payment transaction, or if no alternate payment accounts are identified, then the transaction is denied or authorization is withheld pending the receipt of additional information. In210, the payeefinancial server103 transmits the transaction status message to thepayee computing device102, which then transmits211 the transaction status message and possibly a receipt to theconsumer computing device101 for display to the consumer.
• Those skilled in the art will recognize that the embodiment illustrated inFIG. 2 is not intended to be limiting, and one or more steps can be omitted or altered, or the order of the steps can be altered, without compromising the functionality of the systems and methods disclosed herein. For instance, if the consumer and payee utilize the same FSP, it might not be necessary for the financial servers to communicate with aRKM server104 to properly route electronic communications during a payment transaction. Additionally, if the consumer does not have an account with anIdM service106, or if a payee is making a payment to the consumer, thentransmissions202,203b,207, and211binvolving theIdM service106 could be omitted. In that case, theconsumer computing device101 could communicate directly with the consumerfinancial server105 when transmitting thepayment envelope301 or receiving consumer information and financial account settings and preferences. In other embodiments, theconsumer computing device101 can receive the transaction status message from only thepayee computing device102, from only theIdM service106, or from both thepayee computing device102 and theIdM service106.
• The flexibility of the present systems and methods allows them to accommodate a variety of payment systems and POS devices. To illustrate, if a merchant is capable of processing anonymous payments, theconsumer computing device101 can transmit thepayment envelope301 and payment request to anIdM service106 and/or directly to the consumerfinancial server105, as shown inFIG. 7. The consumerfinancial server105 authenticates the consumer's identity and authorizes the payment transaction by comparing the data in the receivedpayment envelope301 with data stored in a database on the server or with data in apayment envelope301 received from theIdM service106. If the transaction is authorized, the consumerfinancial server105 transmits atransaction authorization350 message to theIdM service106 along with apayment code360. Thepayment code360 can be transmitted to theconsumer computing device101 and then relayed to the payee orally or electronically for redemption with a FSP in exchange forremuneration370. In this embodiment, the payee does not receive consumer data contained in thepayment envelope301, so the identity of the consumer remains confidential and anonymous.
• Another exemplary embodiment capable of processing anonymous payments is depicted inFIG. 8. Theconsumer computing device101 can transmit apayment envelope301 and payment approval to anIdM service106, which transmits the payment envelope to the consumerfinancial server105. The consumerfinancial server105 authenticates the consumer's identity and authorizes or declines the payment transaction. If the transaction is authorized, the consumerfinancial server105 transmits atransaction authorization350 message to the payeefinancial server103, which transmits thetransaction authorization message350 to thepayee computing device102.
• In yet another embodiment illustrated inFIG. 9, the present invention can be used with a secure payment system where the consumer utilizes a merchant-specific charge account or merchant-specific consumer identification and where the merchant securely requests payment authorization from the consumer's FSP without receiving apayment envelope301 from the consumer. In this embodiment, theconsumer computing device101 transmits to the payee computing device102 a payee-specific consumer identifier380 that is recognized by both the payee and the consumer's FSP. The payee's backend system (e.g., the consumer financial server103) establishes a secure connection with the consumerfinancial account server105 and transmits apayment request390 with the payee-specific consumer identifier380. If the transaction is authorized, the consumerfinancial server105 transmits atransaction authorization message350 to the payee backend system, which transmits the transaction authorization message to thepayee computing device102, which in turn transmits the authorization message to theconsumer computing device101. This embodiment eliminates any security risk posed by transmitting from theconsumer computing device101 to the payee computing device102 apayment envelope301 containing sensitive consumer data.
• Skilled artisans will appreciate that the present systems and methods are capable of accommodating the use of multiple payee financial servers as well as multiple consumer financial servers, as illustrated inFIG. 10. Multiple payee financial servers can be used if, for instance, a single merchant utilizes multiple FSPs; a payee computing device is used for multiple merchants; or a single payee FSP routes payment transactions through multiple financial servers. Multiple consumer financial servers can be used in instances where one payee financial server processes payment transactions for multiple consumers with separate FSPs, or when a single consumer utilizes a number of financial accounts with separate FSPs.FIG. 10 also illustrates the distributed nature of the present systems and methods in that payment transactions are authorized without the need to route the transactions through a centralized card network.
• Although the foregoing description provides embodiments of the invention by way of example, it is envisioned that other embodiments may perform similar functions and/or achieve similar results. Any and all such equivalent embodiments and examples are within the scope of the present invention.

Claims (12)

What is claimed is:

1. A computer-implemented method of authorizing payment transactions comprising:

(a) storing, by a first server, payee data and associating, by the first server, the payee data with payee transaction data;

(b) receiving, by the first server, a first payment data envelope associated with a payment transaction from a payee device, the payment data envelope comprising a payer alias, a payee alias, a payee shared secret, and crypto data including encrypted payee data and encrypted payee transaction data;

(c) decrypting, by the first server, the encrypted payee data and payee transaction data from the payment data envelope using the payee shared secret, and retrieving, by the first server, the stored payee data using the decrypted payee transaction data and comparing, by the first server, the decrypted payee data with the retrieved payee data;

(d) validating, by the first server, a payee identity based on the comparison;

(e) based on validating the payee identity, transmitting, by the first server, the payer alias to an RKM server;

(f) receiving, by the first server, a second server IP address from the RKM server; and

(g) transmitting, by the first server, the first payment data envelope to a second server using the second server IP address.

2. The computer-implemented method ofclaim 1 wherein the first payment data envelope further comprises an instruction data array and the method further comprises the steps of:

(a) receiving, by the first server, from the second server, a transaction status message having a transaction flag with a value of authorized or declined, wherein:

(i) when the transaction flag has a value of authorized, the first server creates a temporary database record of the payment transaction that is used to update a payee account balance; and

(ii) when the transaction flag has a value of declined, the first server transmits the first payment data envelope to a third server based on the instruction data array.

3. The computer-implemented method ofclaim 1 further comprising the steps of:

(a) storing, by the second server, a consumer PIN and biometric information and associating, by the second server, the consumer PIN and biometric information with consumer payment information;

(b) receiving, by the second server, the first payment data envelope from the first server, the first payment data envelope further comprising a consumer shared secret and consumer crypto data including encrypted biometric data, encrypted PIN and encrypted payment information;

(c) decrypting, by the second server, the encrypted PIN, biometric information and payment information from the payment data envelope using the consumer shared secret, retrieving, by the second server, the stored consumer PIN and biometric information using the decrypted payment information and comparing, by the second server, the decrypted consumer PIN and biometric information with the retrieved consumer PIN and biometric information;

(d) authorizing, by the second server, the payment transaction based on the comparison of the decrypted consumer PIN and biometric information with the retrieved consumer PIN and biometric information;

(e) based on authorizing the payment transaction, generating, by the first server, a transaction status message corresponding to the authorization;

(f) transmitting, by the second server, the payee alias to the RKM server;

(g) receiving, by the second server, an first server IP address from the RKM server; and

(h) transmitting, by the second server, the transaction status message to the first server using the first server IP address.

4. The method ofclaim 3 further comprising the steps of:

(a) receiving, by the second server, a second payment data envelope from an identity management server;

(b) storing, by the second server, payer data and associating, by the second server, the payer data with the customer payment information; and wherein

(c) the step of authorizing, by the second server, the payment transaction further comprises the operations of (i) retrieving, by the second server, the payer data, (ii) verifying a payer identity by comparing, by the second server, payer data in the first payment data envelope with payer data in the second payment data envelope.

5. The method ofclaim 3 further comprising the steps of:

(a) receiving, by the second server, a second payment data envelope from an identity management server;

(b) storing, by the second server, payer data and associating, by the second server, the payer data with the customer payment information; and wherein

(c) the step of authorizing the payment transaction, by the second server, comprises the operations of (i) retrieving, by the second server, the payer data, (ii) verifying a payer identity by comparing, by the second server, payer data in the second payment data envelope with the retrieved payer data.

6. The method ofclaim 3, wherein determining whether the payment transaction is authorized further comprises:

(a) storing, by the second server, one or more payment restrictions to a database;

(b) associating, by the second server, the one or more payment restrictions with the payer; and

(c) determining, by the second server, whether data in the first payment data envelope or a second payment data envelope complies with the one or more payment restrictions.

7. The method ofclaim 6, wherein the payment restrictions comprise a predetermined upper limit on the payment amount.

8. The method ofclaim 6, wherein the one or more payment restrictions comprise a geographic limitation on the location of the payment transaction.

9. The method ofclaim 6, wherein the one or more payment restrictions comprise a limitation on the types of products subject to a payment transaction.

10. The method ofclaim 3, wherein:

(a) the first payment data envelope further comprises payment instructions;

(b) the payment information comprises a cost amount; and

(c) the second server is further configured to perform the operations of (i) determining a payment amount based on the payment instructions and the cost amount, and (ii) incorporating the payment amount into the transaction status message.

11. The system ofclaim 10, wherein the payment instructions include a gratuity amount and determining the payment amount comprises the operation of adding the gratuity amount to the cost amount.

12. The system ofclaim 10, wherein the payment instructions include a discount amount and determining the payment amount comprises the operation of subtracting the discount amount from the cost amount.

Images