Payment card data theft is a major issue within the payment card industry (PCI). Data theft sometimes results from system breaches at entities involved in processing payment card transactions. Such entities include merchant organizations that receive credit card information from a cardholder, such as a card or account number, in order for a cardholder to subsequently conduct a transaction. For example, a hotel, airline, car rental agency or other entity involved with reservations may require a card number up front in order to hold a reservation and guarantee payment when the transaction is completed. As another example, a merchant or other organization may hold credit card information when a customer has recurrent payments (e.g., monthly payments on an account) and uses the card number each month in order to process the payments.
Various regulations and standards have been developed to protect consumer card information when it is held by a merchant or other entity. For example, the PCI Data Security Standard is a payment card industry standard intended to be followed by organizations that store, process or transmit cardholder data. Among other things, the standard provides measures to be taken to protect card data when stored, including the tokenization of card numbers. Tokenization involves replacing a card number with a random value or token, which protects a credit card number in the event the system storing the card information is breached. Tokens are typically provided by a tokenization service—an entity or system that provides a token to a merchant in response to a primary account number (PAN) that a merchant has received from a cardholder. The tokenization service stores and links the token to the actual PAN in its database systems, so that the actual PAN can be later retrieved and provided to the merchant upon request.
Tokenization does lead to some complexities in the use of payment cards (credit cards, debit cards and other forms of transaction cards). For example, under current practice, a merchant (or a merchant payment processor acting on behalf of a merchant) using tokenization receives a PAN from the cardholder, transmits the PAN to the tokenization service to receive a token, stores the token for subsequent use when a transaction is to be completed, contacts the tokenization service again to obtain the PAN in exchange for the token, and then uses the received PAN to process the transaction. Using the token to obtain the PAN is often referred to as “de-tokenization” and requires extra steps by the merchant and the merchant's system.
There is provided, in accordance with embodiments of the invention, methods and systems for using a token in lieu of an account identifier (such as a primary account number or PAN). In described embodiments, the token may be included in an authorization message (request) sent by a merchant (or a merchant payment processor) so that the merchant has no need to retrieve a PAN represented by the token. In embodiments, a transaction processing system receiving authorization messages checks those messages for tokens. The presence (or lack of presence) of tokens in authorization messages can be used advantageously by the transaction processing system to confirm merchant compliance with token policies and also to evaluate as an indication of potential fraud.
In one embodiment, a method for processing a transaction against an account having an account identifier includes: receiving, at a payment processing system, an authorization request message from a merchant system, the authorization request message including a token for use in lieu of an account identifier, the token provided to the merchant system by a tokenization service and linked to the account identifier for the account; providing, to the tokenization service by the payment processing system, the token in the authorization request message received from the merchant system; receiving, by the payment processing system from the tokenization service, the account identifier linked to the token; and forwarding, by the payment processing system to a financial institution maintaining the account, the authorization request message, the forwarded authorization request message including the account identifier linked to the token.
There are various embodiments and configurations for implementing the present invention. Generally, embodiments involve the use of tokenization, such that a merchant or other entity involved with a card or similar transaction obtains a token to be stored in lieu of a payment card number (e.g., a primary account number or “PAN”) or other account identifier.
In disclosed embodiments, the token is obtained from a tokenization service, which can be associated with a transaction processing system. The token is used by a merchant for processing a transaction (e.g., sending an authorization message to the transaction processing system). The merchant has no need for the PAN other than to initially request a token from the tokenization service. Once the token is requested and obtained from the tokenization service, the merchant thereafter uses the token (and not the actual PAN) to complete the transaction, such as by placing the token in the PAN field of the authorization message.
In some embodiments, an authorization message is processed by a transaction processing system (acquirer system), with the acquirer system parsing and evaluating the message to determine whether the value in the PAN field of the message is an actual PAN or a token. If the PAN field is populated with a token, the acquirer system sends a request to the tokenization service to request the actual PAN, and thereafter processes the transaction using the PAN (e.g., by forwarding the authorization message to the financial institution issuing the payment card).
In some embodiments, the presence of an actual PAN (rather than a token) in an authorization message can be used by a transaction processing system to determine whether a merchant and/or its employees are following merchant policies regarding the protection of consumer card information and to evaluate a transaction for possible evidence of fraud.
While disclosed embodiments describe transactions using a payment card in the form of a credit card, it should be understood that the present invention has application to any form of instrument used for conducting a transaction against an account, including, but not limited to, credit cards, debit cards, check cards, loyalty cards, ATM cards, gift cards, stored value cards, smart cards, key fobs, and other instruments that are used by consumers to process a transaction and that provide a card number or other identifier associated with an account against which the transaction is being posted. Also, while the disclosed embodiments refer to the use of a token to represent a PAN, it should also be appreciated that a token could also be generated to represent other sensitive information of the cardholder that might be provided as part of a card transaction, such as a card expiration date.
Turning now to
In the network 100, the POS terminals 110 are connected to a central merchant system 120 which processes and forwards card transactions through a communications network 122 to a third party transaction processing system (acquirer) 124. The transaction processing system 124 may represent systems maintained by one or more entities that process transactions on behalf of multiple merchants and then forward those transactions through a communications network 130 to issuer system 112. While, for ease of describing embodiments of the invention, the transaction processing system 124 is illustrated as a single system, it should be appreciated that there may be multiple parties and multiple systems involved in the flow of transactions between a merchant and a financial institution, such as a merchant payment processor that has arrangements with a specific merchant to process and forward card transactions on behalf of that merchant, a third party acquirer that obtains transactions from multiple merchants and/or their merchant payment processors (and uses the Issuer Identification Number—often also referred to as a Bank Identification Number—included in each PAN to route transactions to the appropriate issuer), a card association (such as Master Card, VISA, AMEX or Discover) that may operate some of the computer systems involved in processing and reconciling card transactions, and third parties that may operate the issuer system 112 and similar systems on behalf of various financial institutions for purposes of issuing cards and maintaining accounts for those financial institutions. The payment network 100 as thus far described is conventional and the various parties and systems involved are known to those skilled in the art.
Also seen in
The tokenization service 150 generates random tokens corresponding to payment card numbers and maintains one or more databases that store encrypted payment card numbers, along with the corresponding token generated for each payment card number (PAN), so that tokens and corresponding payment card numbers are linked. The generated token numbers are provided to a merchant when a payment card number is provided by the merchant. When that same token is later provided by an authorized party to the tokenization service, the tokenization service can provide the corresponding actual payment card number. The tokenization service 150 and its implementing systems are also known to those skilled in the art and are described, as examples, in “Tokenization (Data Security)” at http://en.wikipedia.org/wiki/Tokenization_(data_security), and in “PCI DSS Tokenization Guidelines” at https://www.pci securitystandards.org, as well as in numerous prior patents and patent publications.
In some embodiments, the presence of an actual PAN (rather than a token) in an authorization message can be used by a transaction processing system to determine whether a merchant and/or its employees are following merchant policies regarding the protection of consumer card information and to evaluate a transaction for possible evidence of fraud.
The particular format of tokens generated by the tokenization service 150 depends on the particular preferences of the tokenization service and its customers. For example, in some instances the token may have the same or a different number of digits as the card number that it represents. In other cases, the token may include part of the PAN, such as the payment card type (the first 2 digits of a credit card number have values that typically represent the card type, such as Master card, Visa and American Express). In some cases the token may include the last four digits of the PAN so that, if needed, the merchant or other party having possession of the token may confirm the card number with a customer without having the entire PAN. However, at least some portion of the token comprises a string of alphanumeric data bits, randomly generated by an algorithm or other encryption method at the tokenization service, in order to make the possession of the token not useful for identifying the complete, actual PAN (e.g., if the merchant system storing the token were to be breached).
Also, it should be noted that the networks 122, 130, 152 and 154 illustrated in
In accordance with embodiments of the invention, when a token is requested by the merchant system 120 (by forwarding a PAN through network 152 to the tokenization service 150), that token is thereafter used by the merchant system 120 to process a transaction without having to store or use the actual PAN. Further, in accordance with some embodiments of the invention, the token may have the same number (or a consistent usable number) of digits in relation the actual PAN, so that the token may be used to populate the PAN field of an authorization message when sent from the merchant system 120, in a manner to be described shortly. Further, in accordance with embodiments, when the transaction processing system 124 receives an authorization message from the merchant system 120, the token populating the PAN field may be used in a request by the transaction processing system to the tokenization service 150 to retrieve the actual PAN corresponding to that token, in a manner also to be described shortly (among other things, the transaction processing system may need the actual PAN in order to know where to route the transaction).
As explained earlier, in some circumstances, a merchant (or a merchant payment processor acting on behalf of a merchant) does need to store the PAN (or a token that can be used to retrieve the PAN), such as when a transaction is to be completed later but the merchant needs assurance that a PAN is available to properly complete the transaction. One example of such a circumstance is a card (and card number) being provided to a hotel when a customer makes a reservation at the hotel. In such case, the merchant will use the card number to later conduct a transaction against the card account and so, in lieu of storing the PAN provided by the cardholder, the merchant requests a token from the tokenization service 150 and stores the token at the merchant system 120, step 214. Later, when the transaction is to be completed, the merchant uses the stored token in order to initiate the transaction and sends an authorization message, with the token, to the transaction processing system 124, at step 216.
Referring briefly to
The MTI field is typically a four digit numeric field that classifies the high-level function of the message and, in the case of the message seen in
The Bit Map field is a field within the message that indicates the data elements that are present in the message. For example, one such indicated data element would be a PAN field illustrated in
The Data field includes multiple data elements having transaction information needed for a transaction, such as a PAN field. In accordance with embodiments of the invention, the PAN field of the message 300 illustrated in
Returning to
For example, the message could be parsed to evaluate the PAN field, and a token may be indicated by a marker bit within the token, such as a “0” occupying the first bit of the PAN field. As known to those familiar with a payment card numbering, a “0” is not normally used in the first bit in current numbering schemes of a PAN (the first two digits of a PAN represent the card type, and current numbering schemes for card types do not begin with the “0” value). Many other methods for identifying a token are possible. For example, the transaction processing system 124 could evaluate certain digits of the data string in the PAN field (such as the BIN—Bank Identification Number—that could comprise the first few bits, e.g., first four bits, of the data string and that identify the issuer/bank maintaining the card account), and use a look-up table to determine whether those digits are consistent with the values that might be found in a PAN or values that might be found in a token. Specifically, a bank or issuer could have two BINS that identify the bank issuing the card, with one BIN used with/forming part of an actual PAN and the other BIN used with/forming part of any token (used in lieu of a PAN for a tokenized transaction). As should be apparent, the particular method used for identifying a token may depend on the particular format used by the tokenization service 150 for tokens that it generates, and the transaction processing system 124 may evaluate the PAN field based on different formats that it expects from tokenization services used by the merchant system 120. In one embodiment, the token may have the same number of bits as the PAN (in order to occupy the same number of bits as the PAN would occupy in the PAN field). In other embodiments the token may have fewer or more bits than the PAN, and could occupy the PAN field and/or another unused portion of the Data field, as long as the transaction processing system “knows” that a token is present (by virtue of a marker bit or distinguishing bits of a token, as provided in the authorization message).
If the transaction processing system 124 determines that a token is present (a “yes” at step 232), a request (that includes the token) is made to the tokenization service 150 for the corresponding PAN, step 234. The PAN retrieved by the transaction processing system is inserted into the authorization message to replace the token, step 236, and the authorization message is processed and forwarded to the issuer system 112, step 240.
If, the transaction processing system 124 determines that the PAN field of the authorization message does in fact have a PAN rather than a token (a “no” at step 232), then the process proceeds directly to step 240 and the message, with the PAN as received from the merchant, is processed and forwarded to the issuer system 112.
In the foregoing description, it is assumed that the evaluation of an authorization message (to determine whether a token occupies the PAN field) occurs at the transaction processing system (acquirer) 124. It should be appreciated that this functionality could be implemented in software applications either at the transaction processing system or in other systems associated with the transaction processing or otherwise involved in the flow of authorization messages between the merchant system 120 and the issuer system 112. Thus, in an alternative embodiment, a separate system (such as pass-through switch) could be placed in the flow (on either side of the transaction processing system 124), and could perform steps to 230-236.
Although not illustrated in
As mentioned earlier, in one embodiment the tokenization service is implemented at the transaction processing system 124 (or at a switch or other system associated with the system 124), thus simplifying communications (the merchant only needs to communicate with the transaction processing system when requesting a token and when processing transactions that might use a token) and streamlining de-tokenization by having actual PANs associated with tokens available for access in order to process transactions at the transaction processing system.
Thus, in each of the described embodiments, the merchant system 120 is not in possession of the PAN, either when the transaction is initiated by the merchant or when a response message is received from the transaction processing system by the merchant.
In
At step 418, the integrated POS system calls out to the tokenization service (and provides the customer's card number to the tokenization service) in order to obtain a token representing the card number (PAN). At step 420, the tokenization system tokenizes the PAN (generates a token) and stores the token (in association with the PAN) for future reference. The tokenization service also passes the token to the hotel at step 424, where it may also be stored. For purposes of the present description, it is assumed that the customer checks into the hotel, with the hotel integrated POS system (such as merchant system 120) recognizing that the customer has previously provided card information and that further card information is not needed from the customer (other than perhaps verifying the last 4 digits of the customers card number, which may be included within the token as described earlier).
When the customer checks out the hotel, step 430, the hotel system enters the token and the amount of the transaction at a credit card terminal (POS terminal) for processing the transaction against the customer's card by creating an authorization message, step 432. The authorization message is received by the Message Evaluation Application at the transaction processing system 124, step 436, which determines whether the transaction has been tokenized (i.e., a token has been inserted in the PAN field of the authorization message), step 440. If the authorization message has a token, as determined in step 440, the transaction processing system requests that a clear text PAN (i.e., a non-tokenized PAN) be retrieved from the tokenization service 150. The Message Evaluation Application receives the PAN and inserts the PAN into the authorization message, step 450, and forwards it through the transaction processing system to the issuer in order to complete the authorization (step 454) and request approval by the card issuer. If the authorization message does not have a token in the PAN field of the authorization message, step 440, then the authorization message is directly passed by the Message Evaluation Application to the transaction processing system in order to complete the authorization (step 454) and request approval by the card issuer.
In particular, when the transaction is determined at step 440 (
The computer system 500 is shown comprising hardware elements that may be electrically coupled via a bus 590. The hardware elements may include one or more central processing units 510, one or more input devices 520 (e.g., a mouse, a keyboard, etc.), and one or more output devices 530 (e.g., a display device, a printer, etc.). The computer system 500 may also include one or more storage devices 540, representing remote, local, fixed, and/or removable storage devices and storage media for temporarily and/or more permanently containing computer-readable information, and one or more storage media reader(s) 550 for accessing the storage device(s) 540. By way of example, storage device(s) 540 may be disk drives, optical storage devices, solid-state storage devices such as a random access memory (“RAM”) and/or a read-only memory (“ROM”), which can be programmable, flash-updateable or the like.
The computer system 500 may additionally include a communications system 560 (e.g., a modem, a network card—wireless or wired, an infra-red communication device, a Bluetooth™ device, a near field communications (NFC) device, a cellular communication device, etc.). The communications system 560 may permit data to be exchanged with a network, system, computer, mobile device and/or other component as described earlier. The system 500 also includes working memory 580, which may include RAM and ROM devices as described above. In some embodiments, the computer system 500 may also include a processing acceleration unit 570, which can include a digital signal processor, a special-purpose processor and/or the like.
The computer system 500 may also comprise software elements, shown as being located within a working memory 580, including an operating system 584 and/or other code 588. Software code 588 may be used for implementing functions of various elements of the architecture as described herein. For example, software stored on and/or executed by a computer system, such as system 500, can be used in implementing the processes seen in
It should be appreciated that alternative embodiments of a computer system 500 may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Furthermore, there may be connection to other computing devices such as network input/output and data acquisition devices (not shown).
While various methods and processes described herein may be described with respect to particular structural and/or functional components for ease of description, methods of the invention are not limited to any particular structural and/or functional architecture but instead can be implemented on any suitable hardware, firmware, and/or software configuration. Similarly, while various functionalities are ascribed to certain individual system components, unless the context dictates otherwise, this functionality can be distributed or combined among various other system components in accordance with different embodiments of the invention. As one example, the merchant system 120 and transaction processing system 124 may each be implemented by a single system having one or more storage device and processing elements. As another example, the merchant system 120 and transaction processing system 124 may each be implemented by plural systems, with their respective functions distributed across different systems either in one location or across a plurality of linked locations.
Moreover, while the various flows and processes described herein (e.g., those illustrated in
This application claims the benefit of and is a non-provisional of U.S. Provisional Application Ser. No. 61/912,364 filed on Dec. 5, 2013, which is hereby expressly incorporated by reference in its entirety for all purposes as if fully set forth herein.
Number | Date | Country | |
---|---|---|---|
61912364 | Dec 2013 | US |