💾 Archived View for ruario.flounder.online › gemlog › 2023-02-10_payments_and_tokens.gmi captured on 2023-04-19 at 22:29:26. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-03-20)
-=-=-=-=-=-=-
From time to time I have heard people talk about the potential for credit/debit card details being leaked on mobile payment devices and wearables. Now I am not expert but from the little (high level) understanding I have of this process, that cannot actually happen. Common mobile payment systems and contactless wearables (like a payment ring, keychain/fob or watch) don't even have the "real" card details and they don't need them! This is because the entire system is based on "tokens".
Rather than your actual card number (a.k.a. "Primary Account Number" or "PAN") they have a payment token in its place. This token is often called a "Device Account Number" (DAN) or "Device Primary Account number" (DPAN). If you were to gain access to it, it might look like a normal card number but it isn't and how it can be used is quite different compared with the PAN. You are not going to type it into a website and buy stuff online or encode it on a magnetic strip and use it in a store. Both would simply fail because it is not like a normal credit/debit card number.
A good comparison would be physical tokens in the real world. At many fairgrounds, theme parks or arcades you can trade your real money for tokens which can be used as payment, but these tokens are limited in that you can only use them within the designated environment. This (somewhat) diminishes the value to a thief.
The main limitation of a DAN is that it is no good on its own, it must be combined with a single use, unique number. Sometimes these are called a dynamic cryptogram¹. In addition to being single use, the number will only be usable with the current merchant.
These dynamic cryptograms can only be generated by your device or a Token Service Provider (TSP), who are further up the financial chain than the mere merchant you are dealing with directly. Your device and the TSP have some extra data, that is never received by the merchant (or stored by anyone else) and it is certainly never exposed over the contactless connection. It is yet another token, the payment token key. This key is also often also referred to as a cryptogram but I will call it a key here for simplicity and to avoid confusing it with the dynamic kind.
Your device uses data about the transaction (e.g. the id of the merchant you are buying from, time stamp, price of transaction, etc.) and combines this with information the device has such as the DAN, expiry date and the payment token "key". With a bit of calculation it ends up with that dynamic cryptogram. Since some of the data varies (merchant, price, timestamp, etc.) that dynamic cryptogram is always different. The unknown parts (especially your key) however make it impossible for anyone without this knowledge to calculate it.
Once done, the DAN (along with its expiry date) and the dynamic cryptogram can be passed to the merchant. Upstream in the payment processing, the TSP will eventually receive this. The TSP has enough information to perform the calculation again, since it receives the merchant id, price, time stamp, DAN, expiry date, etc. and it already knows the the payment token key associated with your DAN. If its calculation results in the same dynamic cryptogram then it can be certain that your device authorised the transaction (since nobody else should know it). The TSP also knows something your device does not, your real card number (PAN), which it also has stored in its database and associated with your DAN. This PAN can now be used to actually charge you.
To reiterate the DAN is useless for payment without an appropriate dynamic cryptogram, and a potential bad actor cannot work out a valid one because they do not have the payment token key needed for generation. Even if they intercepted the payment early on and tried to reuse it, it is tied to a particular merchant because the merchant id was part of the data set used for the dynamic cryptogram's generation. More importantly, the TSP would reject a reused number anyway because it is designed to be single use and it was already used!
P.S. Now of course, if the bad actor gets access to your actual device and can authenticate, then yes they could use these details just as you can. My point here however is that copying (all) the details off the device to use them elsewhere is far from straightforward and your PAN is not even there in the first place.
⁂
¹ Dependent on the merchant's equipment a dynamic "card verification value" (CVV) might be used instead of the dynamic cryptogram. They are generated and are used in a similar way, so I just stick with the term dynamic cryptogram for the rest of the explanation.
Here's How Google Pay, Apple Pay & Samsung Pay Protect Your Card Details
How Apple Pay Works Under the Hood [FreeCodeCamp]
How Apple Pay works under the hood [Codeburst]
⁂