[Dylan16807]

I'm not sure how that affects my reply.

To be clear, I am commenting on the difference between:

"Recurring payments work by storing credit card info in tokenized form, which is still allowed".

vs.

"Recurring payments work by storing a token instead of credit card information."

Those both answer the question, but they say different things on whether "credit card information" is stored. And they say different things about whether the headline is misleading.

[AmericanChopper]

To use card tokens for any kind of payment, you need to integrate with some kind of card data vault, which this rule seems to also prohibit. It seems to be instructing the card brands to issue unique tokens for ever cardholder + merchant pair. No idea how that would work…

[Dylan16807]

> To use card tokens for any kind of payment, you need to integrate with some kind of card data vault, which this rule seems to also prohibit.

Why would you need that?

The rule says nobody can store "actual card data".

If you're using the token for a new payment, you don't retrieve the card number, you use the token directly.

> It seems to be instructing the card brands to issue unique tokens for ever cardholder + merchant pair. No idea how that would work…

Pick a random number and store it in a database with those two other fields...?

[AmericanChopper]

That number needs to be mapped to the PAN, and somebody has to have stored that PAN somewhere in order for it to be used to process payment. This rule says nobody other than the issuer and the card brands are allowed to store the PAN.

[Dylan16807]

Sure, that's why you get the token from the issuer or card brand. That way there's only one entity that stores the PAN, and no third parties are storing it.

To quote the article linked above, "The central bank said the facility of tokenisation shall be offered by TSPs only for the cards issued by/affiliated to them."