In the current payments ecosystem, merchants, processors and acquirers currently use PANs (primary account numbers) to process payment transactions and to identify cardholders for loyalty programs, fraud checks and reporting.
While the use of PANs for such purposes has been useful, the use of PANs as accountholder identification mechansms is problematic. If PANs are retained by merchants, for example, the merchants will need to be PCI (payment card industry) compliant. To be PCI compliant, merchants need to take a number of steps to improve the security of their data systems. Such steps can be resource and time intensive to implement and maintain.
One way to avoid the need to be PCI compliant is to use payment tokens or “tokens” instead of PANs. Tokens can be substitutes for real PANs. A token can be used in place of a real PAN in a payment transaction. If the token is stolen by an unauthorized user (e.g., a hacker), then a new token can be issued in place of the token that was stolen. In this situation, the underlying real PAN is protected and the consumer's basic account information need not be re-issued.
Although the use of tokens is desirable, the number of tokens used in a particular payments ecosystem can be very large. In some cases, each accountholder PAN can be mapped to multiple tokens (1-N mapping). For example, if a PAN is used in multiple digital wallets, each wallet instance can have a different static token for the same cardholder PAN. In another example, a different token relating to a PAN can be issued for each transaction.
Because the number of tokens corresponding to a single PAN is unknown to an entity such as merchant, and because a token is intended to obscure a real PAN, it is difficult if not impossible for an entity such as a merchant to determine who the accountholder is if the merchant is in possession of the token. As such, in a conventional token based payments system, entities such as merchants are unable to perform fraud processing, operate loyalty programs, and other processes that would necessarily require them to know who the accountholder is or might be.
Embodiments of the invention address these and other problems, individually and collectively.
USPTO Backgrounds
USPTO Backgrounds