Mechanism for fraud-resistant consumer transactions   

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 11/863,075, filed Sep. 27, 2007, which claims the benefit of U.S. Provisional Application No. 60/848,570, filed Sep. 27, 2006, each of which is hereby incorporated by reference in its entirety.

TECHNICAL FIELD

The described technology is directed to the field of technology supporting financial transactions, and, more particularly, to the field of technology supporting secure financial transactions.

The card numbers used by Customers in consumer credit and debit transactions today are vulnerable to fraud and misuse largely because they are static identifiers. That is, the same identifier that is used in a first transaction can immediately be used again in subsequent transactions not authorized by the Customer. Interception of the credit/debit number is not a concern now, since SSL, which is almost universally used, maintains a private communication channel between Customer and Merchant. However, by submitting the card number at all, the Customer gives up control of it to the Merchant—at least in principle. Dishonest merchants can abuse this control. More commonly, the Merchant accidentally reveals (i.e., loses) the card data to a dishonest intruder, or to a dishonest employee.

Card Organizations (VISA, MasterCard, etc.) and their participating Financial Institutions have tried to counter this vulnerability by demanding more identifying information (e.g., ‘name’, ‘address’, ‘CCV’, etc.) from the Customer as part of each transaction in order to authorize payment. However, all of these pieces of information are themselves only static identifiers. At best their use only delays exposure to the very same fraud vulnerability, i.e., abuse by dishonest or insecure Merchants. In fact, requiring that customer to provide additional identifying information to the merchant may give rise to greater risk to identity theft or other forms of fraud enabled by this identifying information in the case of a dishonest or insecure merchant.

Information security techniques that address this threat much more robustly do exist. These techniques (e.g., digital signatures, one time use hardware tokens, etc.) achieve a much higher level of fraud protection by using a unique identifier for each transaction which can be generated only by the proper individual. Unfortunately, it has been difficult to introduce them to the general population because of the huge legacy effect imposed by the existing credit and debit card systems, as well as a reluctance by Customers to adopt less convenient processes, even when more secure.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram showing some of the components typically incorporated in at least some of the computer systems and other devices on which the facility executes.

FIGS. 2-5 are data flow diagrams showing interactions performed in accordance with the technique.

FIG. 6 is a flow diagram showing steps typically performed by the facility in order to perform a system initialization process.

FIG. 7 is a flow diagram showing steps typically performed by the facility in order to complete a customer registration process.

FIG. 8 is a flow diagram showing steps typically performed by the facility in order to conduct a secure online payment.

DETAILED DESCRIPTION

A software facility for supporting fraud-resistant consumer transactions (“the facility”) is provided that uses a shared, recirculating pool of “pay-through accounts” as the basis for individual consumer charges. When a customer has placed an order with a web merchant and is ready to make an online payment to pay for the order, an invoice reflecting the amount of the payment to be made is signed using a private key of the customer and submitted to a payment translation service. After verifying that the signature is valid, the payment translation service selects a pay-through account from a pool of pay-through accounts that are shared across a number of different customers, such as all of the customers having an account at the same financial institution as the customer in question. Because each pay-through account in the pool can be used to make payments on behalf of different customers at different times, the pay-through accounts in the pool are sometimes referred to as “recirculating.” The payment translation service then transfers the amount of the payment from the customer\'s account at the financial institution to the selected pay-through account, and returns information identifying a credit or debit card number associated with the selected pay-through account to the customer. This information is then submitted to the merchant, which uses it to submit and settle a charge against the selected pay-through account. This approach has the advantage that it uses standard, existing banking mechanisms and procedures, without the need to recognize charge transactions as corresponding to one-time use credit card numbers, or do any special processing for them. Ultimately, by standard settlement processes, the amount transferred from the customer\'s account to the selected pay-through account is transferred to the merchant.

In various embodiments, the facility provides a number of different approaches to exchanging any necessary data. These include having the customer cut and paste information between a first browser window corresponding to a browsing session with the merchant in the second browsing window corresponding to a browsing session with the payment translation service; a customized browser, or browser plug-in that automatically handles all necessary exchange of information; a shopping portal hosted by the payment translation service or financial institution, through which the customer does all of his or her shopping, and which intercepts exchanges between the customer\'s browser and the merchant\'s server as necessary to implement the facility; and augmentation of merchants\' web sites to direct the customer to interact with the payment translation service in a way that results in payment information for the pay-through account being provided by the payment translation service to the merchant.

By providing this payment translation service in some or all of the ways described above, the facility provides additional security to consumer transactions without imposing a significant burden on customers, without requiring any changes to the existing credit card and debit card charge settlement processes and mechanisms, and requiring few or no changes to the websites provided by and the processes performed by merchants.

FIG. 1 is a block diagram showing some of the components typically incorporated in at least some of the computer systems and other devices on which the facility executes. These computer systems and devices 100 may include one or more central processing units (“CPUs”) 101 for executing computer programs; a computer memory 102 for storing programs and data—including data structures, database tables, other data tables, etc.—while they are being used; a persistent storage device 103, such as a hard drive, for persistently storing programs and data; a computer-readable media drive 104, such as a CD-ROM drive, for reading programs and data stored on a computer-readable medium; and a network connection 105 for connecting the computer system to other computer systems, such as via the Internet, to exchange programs and/or data—including data structures. In various embodiments, the facility can be accessed by any suitable user interface including Web services calls to suitable APIs. While computer systems configured as described above are typically used to support the operation of the facility, one of ordinary skill in the art will appreciate that the facility may be implemented using devices of various types and configurations, and having various components, such as wireless telephones and similar devices.

FIGS. 2-5 are data flow diagrams showing interactions performed in accordance with the technique. FIG. 2 shows a financial institution computer system 200 and a customer account 201. It shows an online merchant 210 from which the customer may make a purchase. It shows a card organization computer system 220 with which the online merchant computer system interacts to settle a charge transaction, and a financial institution service provider/PNV computer system 230. It shows a payment translation service 250 that establishes a shared pool of pay-through accounts 251.

FIG. 3 shows the customer performing a check-out process 361 at the merchant to conclude a purchase. The customer\'s browser transmits a digitally-signed invoice 362 to the payment translation service 250. In response, after verifying that the invoice was properly signed by the customer, the payment translation service chooses a particular pay-through account to use for the transaction.

FIG. 4 shows the payment translation service performing a debit customer process 464, in which the existing customer account 201 is debited 482 and the selected pay-through account 251 is credited 481, both by the amount indicated by the invoice. The payment translation service then transmits payment card information 465 associated with the selected pay-through account—such as a credit card or debit card number associated with the selected pay-through account—to the merchant and/or to the customer\'s computer system. This information for the pay-through account credit card number is inserted 466 into the merchant\'s check-out form.

FIG. 5 shows the merchant submitting a charge against the pay-through account payment card in a conventional matter to a charge-settlement process, in which the charge is settled in a conventional matter. In particular, the merchant sends the charge 567 to the card organization computer system 220. The card organization computer system 220 sends the charge 568 to the financial institution service provider computer system 230. The financial institution service provider computer system 230 sends the charge 569 to the financial institution computer system 200, which causes the merchant\'s account to be credited for the amount of the charge, and the selected pay-through account to be debited for the amount of the charge.

FIGS. 6-8 are flow diagrams showing sample implementations of processes performed by the facility. FIG. 6 is a flow diagram showing steps typically performed by the facility in order to perform a system initialization process. The facility typically performs these steps once to initialize operations for a particular financial institution. In steps 601-605, the facility loops through each of a large number of pay-through accounts to populate a pool of pay-through accounts that is shared across the customers having accounts with the financial institution, such as 1,000 pay-through accounts, or 10,000, or 100,000. In step 602, the facility creates a new checking account constituting a new pay-through account. The created checking account has an account number, a credit card number, and a zero balance. In some embodiments, the created checking account has a debit card number rather than a credit card number. In some embodiments, accounts of types other than checking accounts, such as savings accounts, are created to serve as pay-through accounts.

In step 603, the facility activates the credit card number for the pay-through account created in step 602. In step 604, the facility adds to the pay-through account created in step 602 to the shared pool of pay-through accounts. In step 605, if additional pay-through accounts remain to be created, then the facility continues in step 601 to create the next one, else these steps conclude.

Those skilled in the art will appreciate that the steps shown in FIG. 6 and in each of the flow diagrams discussed below may be altered in a variety of ways. For example, the order of the steps may be rearranged; substeps may be performed in parallel; shown steps may be omitted, or other steps may be included; etc.

FIG. 7 is a flow diagram showing steps typically performed by the facility in order to complete a customer registration process. The facility typically performs the customer registration process for each customer of the financial institution for whom payment translation is enabled. In step 701, the facility obtains a digital certificate associated with the customer that can be used to verify signatures made by the customer with a private key possessed by the customer and corresponding to the digital certificate. In some cases, the private key and digital certificate are created for the customer by or on behalf of the facility. In step 702, the facility associates the certificate with the customer\'s account with the financial institution, such as by storing the certificate in a row of a table corresponding to the customer\'s account. After step 702, these steps conclude, and the customer can proceed to make online payments using the facility. In some embodiments, the facility associates authorization credentials other than a digital certificate with the customer, such as a password used by the customer, an image feature used to authenticate the user, biometric attributes used to authenticate the user, details of the challenge-response mechanism, details of a time-based access generator, etc. Where the authentication credentials already associated with the customer\'s account, such as where a password used by the customer to access the financial institution\'s online banking website is already associated with the customer\'s account, then the steps of FIG. 7 are unnecessary and can be omitted by the facility.

FIG. 8 is a flow diagram showing steps typically performed by the facility in order to conduct a secure online payment. The flow diagram is organized into three columns: a column 860 containing steps performed by a merchant\'s server, a column 870 containing steps performed by the customer\'s browser, and a column 880 containing steps performed by the payment translation service. As will be discussed below in greater detail, some of these steps can be performed in ways different than those shown, and/or by different computer systems.

In step 801, the customer\'s browser generates an order by interacting with the merchant\'s website. In response, in step 802, the merchant\'s server creates a payment page—i.e., Checkout page—that includes both a total amount due from the customer and fields for providing payment information identifying a credit card to pay that amount. In step 803, the browser uses information from the payment page received from the merchant to generate an invoice, which contains at least the amount due from the payment page. In step 804, the browser signs the invoice using the customer\'s private key, and submits the signed invoice to the payment translation service, along with information identifying the customer, such as the customer\'s account number.

In step 805, if the payment translation service is able to verify the signature on the invoice it receives from the customer\'s browser against the certificate for the customer, then the facility continues in step 806, else this process terminates. In step 806, the payment translation service selects a pay-through account from the shared pool of pay-through accounts. In some embodiments, the selection of step 806 is random. In some embodiments, the facility bases this selection on such factors as the balances of the pay-through accounts, and/or the times at which the pay-through accounts were last selected for use in a transaction. In some embodiments, only pay-through accounts whose balances are zero are eligible for selection.

In step 807, the payment translation service debits the customer\'s account and credits the pay-through account selected in step 806, both for the amount due shown by the invoice. In some embodiments, the debited customer account is a depositary account of the customer\'s, such as a checking, savings, or brokerage account. In some embodiments, the debited customer account is a credit or charge account or other line of credit. In some embodiments, the facility uses ACH transfers to effect the debit and credit options of step 807. In step 808, if both the debit and credit operations of step 807 succeed, then the facility continues in step 809, else any succeeding debit or credit operation is reversed and this process terminates. In step 809, the payment translation service returns information identifying the pay-through account selected in step 806 to the customer\'s browser. Such information may include, for example, a credit card number, expiration date, CCV, account holder name, billing address, etc. In some embodiments, the payment translation service further stores a record of the transaction, identifying at least the customer account, the pay-through account, and the amount, to facilitate later reversal of the transaction if this turns out to be necessary.

In step 810, the customer\'s browser populates and submits the payment page created by the merchant in step 802 using the information returned by the payment translation service in step 809. In step 811, when the merchant\'s server receives the submitted payment page, the merchant uses standard, conventional techniques to submit and settle a charge for the amount due against the pay-through account selected in step 806. This entire submission and settlement process can be performed by all of the involved systems without any understanding about the nature of the pay-through account or special-case processing therefor. These steps then conclude.

In some embodiments (not shown), when the pending charge or charges are settled against a pay-through account—i.e., its balance returns to zero—as part of returning the pay-through account to the pool for re-use, the facility performs a verification information reset process. This process involves altering some or all of the verification information associated with the pay-through account, such as expiration date, CCV, cardholder name, billing address, etc. By performing such alterations, the facility further reduces any opportunity for fraudulent re-use of pay-through accounts.

In various embodiments, the facility uses a variety of techniques to manage communications between the customer, the merchant, and the payment translation service. These include, but are not limited to, the following:

Customer Cut-and-Paste

The two communication channels, (1) between Customer and Merchant, and (2) between Customer and FI are implemented as two distinct web browser “windows,” or “tabs.” The Customer submits to the Merchant the payment chit information she received from the PTS via “cut-and-paste”—a feature already available in all major browsers.

This approach has the advantage that there is no need for client software that lies outside of standard web browser functionality. All new functionality is embodied in PTS web pages so that deployment is trivial. No Merchant participation is required.

Shopping Portal, Hosted by the FI or PTS

Customers shop at Merchant sites via a web “connection” that goes “through” the Customer\'s FI, or trusted representative of the Fl. During the most of the shopping experience, the intermediate FI server merely passes data to and from Customer and Merchant. Only at point of “checkout” does the FI server modify the data stream. It does so by automating the “cut-and-paste” operation in that variation. In some embodiments, Customers authenticate themselves at the beginning of the shopping session, so that per-transaction authentication may be redundant, and hence is eliminated in some embodiments.

In various embodiments, the intermediate FI connection is enabled by one of two mechanisms: 1. Customers are encouraged to do their online shopping safely by starting at a site such as http://safeshop.myFI.com. 2. Customer web browser is configured to use FI server as a proxy server via a transparent protocol such as SOCKS for all browser traffic.

This approach has all the advantages of customer cut-and-paste. Additionally, there is no impact on customer shopping experience, creating no disincentive for using the facility.

Special Purpose Client Browser Plug-In

A browser plug-in approach, similar to the mechanism by which Macromedia\'s nearly ubiquitous Flash player is integrated into browsers, can similarly avoid creating any adverse impact on customer shopping experience. In fact, the shopping experience my even be improved since the plug-in can automate much of the form filling required at checkout time. Also, the potential to steer Customers towards using the new payment methodology is good. Again, absolutely no Merchant participation is required.

The plug-in may either provide an explicit mechanism for the customer to invoke a secure payment, and/or may automatically recognize merchant Checkout pages and automatically invoke a secure payment in a response. As for the former, the plug-in may, for example, provide a toolbar button for invoking a secure payment. As to the latter, the plug-in can automatically recognize a Checkout page by examining the document object model (“DOM”) for each page retrieved and displayed by the browser, looking for such indicators of a Checkout page as fields having names such as “card number,” “CCV,” “billing address,” etc. The plug-in can also analyze content on each page other than field names, including text or image content, as well as top-level attributes for the page such as the protocol used to retrieve the page.

Adapted Browser

Any techniques implemented in a browser plug-in can instead or also be directly integrated into shipping versions of one or more browsers. A customer using such a browser would not need to download or install the browser plug-in described above.

Merchant Cooperation

Merchants “embed” the payment functionality in their Checkout pages. In particular, a merchant adds to its Checkout page a control, such as a button, that, when activated by the user, sends a request to the PTS server providing invoice data. The PTS server returns a web page that performs customer authentication, after which it assigns a pay-through account and returns a copy of the merchant\'s Checkout page with information about the selected pay-through account pre-populated. The user can then submit this copy of the merchant\'s Checkout page to the merchant by activating a submit control included in the page returned by the PTS server.

The technology to support this is partially illustrated by, for example, embedded YouTube videos. Examples of existing payment systems that require Merchant participation are PayPal and Google Checkout.

In some embodiments, rather than collecting customer authentication information in a webpage served by the PTS server, the merchant further adds a mechanism to its Checkout page that collects this authentication information from the user when the control is activated and forwards it to the PTS server. In some embodiments, this functionality is provided using a javascript window or other appropriate approaches.

This approach has the advantage that Customer shopping experience can be enhanced and behavior modifications encouraged without the need for a client plug-in. Additionally, much of the form parsing capability required of the software can be drastically simplified if not completely eliminated.

Those skilled in the art will appreciate that a variety of other mechanisms may be used to exchange the data used by the facility.

While the foregoing principally describes transaction authorization from the customer taking the form of a digital signature on an invoice or purchase order that is based upon information from the merchant, in various embodiments the facility employs a wide variety of other authorization mechanisms. For example, authorization made be performed using a customer password, such as a password already used by the customer to access the financial institution\'s online banking site; an image features selection authentication system; a challenge and response authentication system; a time-based access code generator; or a variety of other mechanisms.

It will be appreciated by those skilled in the art that the above-described facility may be straightforwardly adapted or extended in various ways. For example, the facility may be used with various kinds of financial institutions, merchants, and account types. While the foregoing description makes reference to particular embodiments, the scope of the invention is defined solely by the claims that follow and the elements explicitly recited therein.