would love to see a end to end video for a transaction, from customer/holder, -> merchant -> acquirer, all the way through to the issuer bank and back...
Hello, thanks for the video, it definitely helps. Two questions: 1. If I understand correctly, tokenizing is replacing sensitive data (credit card #) by a random combination that only the "tokenizer" and the end user/final receiver can understand (know the real meaning). Correct ? 2. Using a token is different and better than an encryption, as encrypted data is stored while there is no data stored with tokenization. Did I get that correctly ?
You are a fast learner! 1- Correct! With tokenization a random string is assigned by the tokenizer. Who is often the payment gateway for a merchant. 2- That is also correct. Encryption as you likely know uses a cipher, which means that it can possibly be cracked. This is why the payment industry landed on using tokenization to store card numbers. Tokenizing is safer, as if those tokens end up in an attacker's hands they are nearly worthless. It's worth noting that payment gateways are required by the PCI-DSS to encrypt all the traffic to them, so when the token is in transit, it would also be encrypted, like most web traffic is these days. Hope that this answers your questions! Hope you found this video helpful and educational!
It is because you are a good teacher ! Thanks for sharing the knowledge and making those terms easy to understand for me. Regarding your last note in the response, isn’t it a waste of time/energy/resource to encrypt something that cannot be read if hacked ?
@@marieemmanuellekouadio8404 Fair point! Google recently started preferring to see ALL traffic being sent on HTTPS. It is commonly believed that they did this to counteract the global eavesdropping networks that are known to exist. So the reality is that nearly all traffic, even RUclips is encrypted in transit. You are right that it is less sustainable from an energy perspective, however it has become the global standard. Also worth noting is that there is other personally identifiable information that is often sent as part of the payment API call, such as name and address. That would make it a good idea to encrypt the data also.
Fiserv could be/is likely using tokenization services from the card networks, including Mastercard. Then merchants, like a SaaS software company as an example, would be buying a tokenization service from Fiserv. There are many types of tokens, there are different tokens that work at each level to keep card numbers as secure as the industry knows how.
Is a new token created for each sale? For example, if I use a pay app at say Target and buy something, and then go to a grocery store, do they both get the same token? If they do, couldn't someone use the token number to say you purchased something from them and withdraw that money out of your account?
Hi Jack! Yes, a new payment gateway token is created for each merchant for each card. Not often for each new sale. Certainly 2 tokens would be created in your example as there are 2 merchants involved. Each merchant gets a unique token per card. In this way the system avoids the pitfall that you mention. Now there is also tokenization on your digital wallet, that is on your phone, say with Google Pay, now your card number in this case is not actually passed to the merchant at all instead they create a different value ( a token) that is given to the merchant. This further protects your card data as in this case less merchants have your actual card number. Does this answer your question?
The tokenization that we are primarily discussing in this video doesn't directly relate to the mobile phone. However there is a form of tokenization on the mobile wallets that are used on our smart devices. In the case if the phone has a good lock code and the mobile wallet is configured properly, there is little chance of the device being used for fraudulent purchases. However no lock code, plus poor configuration of the mobile wallet could lead to some fraudulent charges being approved. However the primary account numbers of the credit cards would be protected by the mobile wallet application in nearly all circumstance. Thank you for your question! To learn more about payments, subscribe to our channel!
Hi Christeena! When I know about them, you will! :) However I don't immediately see a direct connection here. If you have some ideas about using these concepts together. I would really like to hear it!
This was really helpful. Thank you. If a merchant stores a token and uses that token for merchant initiated transactions or other payments, is strong customer authentication needed upon the first payment with the tokenized card? If the card changes and there's a new token, can earlier authentication apply to it?
Happy to help! The first time a consumer enters their card number into a merchant's form, that transaction can require SCA. Once that token has been through SCA for a particular merchant, then it should not have to go through it a second time. I cannot give a 100% true rule for whether or not a new token for the same card would require SCA, typically I would think it would not. Exceptions likely exist.
If my use case is to authorize a customer at the time of contract generation in SalesForce and use that card every month for billing without having the customer to enter card details every month, where can this Token be stored in SalesForce for recurring use ? Our plan is to use Chargent
In Chargent that token is stored on the Chargent Order record in the tokenization field. You can also find it on the transaction record. Very happy to hear you will be using Chargent! Please let us know how we can help!
In the context of payments, tokens are divided between High-value tokens (HVT) and Low-value tokens (LVT), which are also security tokens. Is there a layman term or examples to better understand HVT and LVT?
Sorry those are not terms I am familiar with! My cursory review indicates that the industry is still struggling with specific definitions about this. I am confident there is someone that can answer this, I hope they do in the comments here for you!
would love to see a end to end video for a transaction, from customer/holder, -> merchant -> acquirer, all the way through to the issuer bank and back...
Love that idea! We can do that video!
Hello, thanks for the video, it definitely helps. Two questions:
1. If I understand correctly, tokenizing is replacing sensitive data (credit card #) by a random combination that only the "tokenizer" and the end user/final receiver can understand (know the real meaning). Correct ?
2. Using a token is different and better than an encryption, as encrypted data is stored while there is no data stored with tokenization. Did I get that correctly ?
You are a fast learner! 1- Correct! With tokenization a random string is assigned by the tokenizer. Who is often the payment gateway for a merchant. 2- That is also correct. Encryption as you likely know uses a cipher, which means that it can possibly be cracked. This is why the payment industry landed on using tokenization to store card numbers. Tokenizing is safer, as if those tokens end up in an attacker's hands they are nearly worthless. It's worth noting that payment gateways are required by the PCI-DSS to encrypt all the traffic to them, so when the token is in transit, it would also be encrypted, like most web traffic is these days. Hope that this answers your questions! Hope you found this video helpful and educational!
It is because you are a good teacher ! Thanks for sharing the knowledge and making those terms easy to understand for me. Regarding your last note in the response, isn’t it a waste of time/energy/resource to encrypt something that cannot be read if hacked ?
@@marieemmanuellekouadio8404 Fair point! Google recently started preferring to see ALL traffic being sent on HTTPS. It is commonly believed that they did this to counteract the global eavesdropping networks that are known to exist. So the reality is that nearly all traffic, even RUclips is encrypted in transit. You are right that it is less sustainable from an energy perspective, however it has become the global standard. Also worth noting is that there is other personally identifiable information that is often sent as part of the payment API call, such as name and address. That would make it a good idea to encrypt the data also.
@@ChargentByAppFrontier Got it. Everything you said became clearer when I "googled" HTTPS and API. Thank you ! I learnt a lot.
Who buys tokenization services from provider such as Mastercard or Fiserv? Who are the customers?
Fiserv could be/is likely using tokenization services from the card networks, including Mastercard. Then merchants, like a SaaS software company as an example, would be buying a tokenization service from Fiserv. There are many types of tokens, there are different tokens that work at each level to keep card numbers as secure as the industry knows how.
Fantastic video
Thanks for watching!
Is a new token created for each sale? For example, if I use a pay app at say Target and buy something, and then go to a grocery store, do they both get the same token? If they do, couldn't someone use the token number to say you purchased something from them and withdraw that money out of your account?
Hi Jack! Yes, a new payment gateway token is created for each merchant for each card. Not often for each new sale. Certainly 2 tokens would be created in your example as there are 2 merchants involved. Each merchant gets a unique token per card. In this way the system avoids the pitfall that you mention. Now there is also tokenization on your digital wallet, that is on your phone, say with Google Pay, now your card number in this case is not actually passed to the merchant at all instead they create a different value ( a token) that is given to the merchant. This further protects your card data as in this case less merchants have your actual card number. Does this answer your question?
@@ChargentByAppFrontier Yes it does! Thank you very much for the prompt response.
What happens if the mobile phone falls into the wrong hands, there is a risk, right?
The tokenization that we are primarily discussing in this video doesn't directly relate to the mobile phone. However there is a form of tokenization on the mobile wallets that are used on our smart devices. In the case if the phone has a good lock code and the mobile wallet is configured properly, there is little chance of the device being used for fraudulent purchases. However no lock code, plus poor configuration of the mobile wallet could lead to some fraudulent charges being approved. However the primary account numbers of the credit cards would be protected by the mobile wallet application in nearly all circumstance. Thank you for your question! To learn more about payments, subscribe to our channel!
Can i know about any research papers based on tokenisation using block chain
Hi Christeena! When I know about them, you will! :) However I don't immediately see a direct connection here. If you have some ideas about using these concepts together. I would really like to hear it!
This was really helpful. Thank you. If a merchant stores a token and uses that token for merchant initiated transactions or other payments, is strong customer authentication needed upon the first payment with the tokenized card? If the card changes and there's a new token, can earlier authentication apply to it?
Happy to help! The first time a consumer enters their card number into a merchant's form, that transaction can require SCA. Once that token has been through SCA for a particular merchant, then it should not have to go through it a second time. I cannot give a 100% true rule for whether or not a new token for the same card would require SCA, typically I would think it would not. Exceptions likely exist.
If my use case is to authorize a customer at the time of contract generation in SalesForce and use that card every month for billing without having the customer to enter card details every month, where can this Token be stored in SalesForce for recurring use ? Our plan is to use Chargent
In Chargent that token is stored on the Chargent Order record in the tokenization field. You can also find it on the transaction record. Very happy to hear you will be using Chargent! Please let us know how we can help!
In the context of payments, tokens are divided between High-value tokens (HVT) and Low-value tokens (LVT), which are also security tokens. Is there a layman term or examples to better understand HVT and LVT?
Sorry those are not terms I am familiar with! My cursory review indicates that the industry is still struggling with specific definitions about this. I am confident there is someone that can answer this, I hope they do in the comments here for you!
Great video. Thank you!
Thanks Justin Best - glad you liked it. Was any part particularly helpful to you?
@@ChargentByAppFrontier the Vegas analogy was very helpful for me!
But there has to be some form of encryption, no? Anything that is unique is encrypted, whether it be loosely or otherwise
Hi There! Yep, encryption is used while the data is in transit. Tokenization is for sensitive data at rest.
Only for credit card and not for debit card?
Tokenization works for all types of cards, including debit and credit. It can also be used for bank account details and other payment methods!
@@ChargentByAppFrontier Need a Technical Co Founder for our startup for doing same process
Ok
Thanks for watching! Please let us know if you have any questions!
Tokens generated by payment Gateway ?
If you close your eyes and listen you would think it's Seth rogan
Seth rogan what’s up
Thank you!