Just curious, what is the common algorithm used to tokenize a user's credit card? I know lots service use PRNG (random number). Does it just re-gen a random number when there is a confliction? What about use UUID as token? What are the pros and cons?

  • See also this question - the problem with a UUID is that it doesn't fit into database fields that were designed for a 16 digit numeric value, hindering compatibility with pre-existing systems. – gowenfawr Jan 16 '16 at 14:30
  • @gowenfawr then if the token is used only inside our org, a UUID should be fine, right? Like Amazon, they do not make their tokenization as a public service. But I see that braintree use alphabet as token. That is why I try to see the pros and cons between random number & UUID – Alfred Jan 16 '16 at 19:15
  • Correct, there's no requirement to make it isomorphic to a card, that's just how a lot of processors do it because it eases compatibility. – gowenfawr Jan 16 '16 at 19:57
  • @gowenfawr other than tokenization, I also need a fingerprint of the credit card. So that if two same credit cards come in, I could know they are the same. So which hash function provides unique hashing. As such there won't be two different cc hashed into a same fingerprint. – Alfred Jan 17 '16 at 6:05
  • If you haven't, you should read the PCI DSS Tokenization Guidelines – gowenfawr Jan 17 '16 at 23:36

Tokenization just uses random number generators to generate a certain ID and link that ID to a card, there is no way you can for instance reverse engineer the token from a card number or vice versa.

Sometimes the last 4 digits are kept as part of the token to display to the user. This is useful for certains shops, like Amazon, where a user might have configured several credit cards.

Normally tokenization happens in such a way that the randomness and keyspace are so large that colliding tokens are very unlinkely. In case a token would already be present it just needs to re-generate the random number prior to commiting into the database (often databases have unique constraints on the token as well as they're used as secondary or primary keys).

The pros are that you can reduce your PCI scope significanty. For instance databases used for analytics on a person's spend needn't be part of the PCI zone as no PAN data will be present.

There are no cons. Some con you might have is for card acquirers that do not want their helpdesk to have access to their clients card numbers. So it might be that the acquirer needs to print an additional identification number on the card of the customer so he can be identified.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.