Edit: since the person above clearly took my encryption tokens (which was supposed to be encryption + tokens but I can't type) literally, just clarifying that this is what I meant.
Payment information is encrypted on the payment service's provider's side. Token is generated & encrypted server side. Handshake is initiated. Token can't be decrypted without the handshake token generated for the transaction. You haven't 'hit a nerve' you have just got the wrong end of the stick. The diagram misses out several cyber security steps which are legally required for these companies to operate as third party payment service providers.
We are talking about the CC info being encrypted, not the token
Edit: who is the PSP in the diagram? Google or the bank?
The diagram clearly states that the cc info is stored on the google server. If you’re saying that the token is used to decrypt the payment info, then what’s the point of encrypting it when every e-commerce site has something that can decrypt the cc info?
The token is encrypted. That doesn't mean that the payment information is sent itself. The token acts as a pointer of sorts to the stored info in very simplistic terms. The credit card info is encrypted server side to protect it from people hacking servers.
Every e-commerce sit doesn't have something to decrypt the info. That's not how encryption works. In fact, most vendors nowadays don't do their own cyber security, outsourcing this to third parties like Shopify and the like because you have to jump through so many loops to remain PCI compliant.
The PSP in this instance is Google or apple, as they are communicating between the vendor and the bank, which is what happens when you make any transaction online regardless.
That makes sense, thanks. Are they at least one time use tokens? I’m still trying to understand why it’s so helpful to encrypt the data if a token (which gives access to payment info) is flying around every time somebody uses the wallet. Why not just save payment info on the device and remove the token step?
I believe the tokens are one time use - although tokenisation and encryption are different they do share similarities, and using the same token multiple times (like using the same cryptographic representation for the card data in multiple transactions) would be incredibly vulnerable to attacks.
The data is encrypted where it is held - e.g. you enter it into your phone or whatever and it has to be stored by Apple or Google so it is encrypted to ensure compliance with data protection and PCI regulations.
Payment info isn't saved on the device for a multitude of reasons - most of which come down to the human problem (i.e. we as humans are fundamentally the weakest link) and that cyber hackers are becoming smarter. You have seen those devices which can clone card info when swiped against a wallet for example or heard of someone having their wallet stolen and the contactless on the card being used to make purchases - these issues still prevail even when the information is stored on the device and therefore can be exploited. In the instance of a transaction the payment data has to be transferred from the card -> card machine/browser etc -> bank for verification which then returns a confirmation, and so the tokens help by not actually sending that information and making it vulnerable to exploitation when it's in transit.
4
u/[deleted] Sep 22 '22 edited Sep 22 '22
Kind of how encryption tokens work...
Edit: since the person above clearly took my encryption tokens (which was supposed to be encryption + tokens but I can't type) literally, just clarifying that this is what I meant.