3DS V1 sun setting was announced last year and I believe this year by Oct 22 everyone has to switch to EMV 3DS (3DS V2) . As far as liability in EMV 3DS is concerned, in most cases it will be issue me in case of chargebacks but not all. In some cases , for instance particular cases where the card was not authenticated or the authentication was rejected , the transaction liability could be with the merchant. ECI (Electronic Commerce Indicator) value determines whether the authentication was successful or not. For example a visa transaction with ECI value of 7 would indicate that the transaction authentication was rejected hence liability with merchant. Similarly there could be other cases and values for other card schemes . From a merchant perspective it’s always best to check with acquirer on more details specific to each card scheme. Hope this helps
Thanks for your videos, it's really helpful like an induction or much better:). I have a question in an online txion as you described in 3DS flow why the verification to be taken to issuer web site, an AUTH message will do the same thing rt?
Hi Saurabh, You have imparted vast knowledge on PCI , Can you also please help providing What are the standard day to day activities could be with a Business Analyst in Payments and Cards domain. Like What type of usual requirements, Can you provide an example internal usage of an application for reconciliation or security monitoring. etc. This will help me in cracking interviwe and be really appreciated. thanks in advance,
Hi My questing is that, when we do an ECOM transaction so it always ask for the OTP, but you mentioned in 3DS2 there is no OTP required, the system just do a risk assessment and if the transaction is under low risk so the transaction happen successfully. OTP does not required in POS transaction, so your statement is correct here but not with the ECOM transaction. Please confirm, I am getting you correctly or not.
Hi Saurabh, thanks for the informative lecture, and the way to introduce it with simple words. It would be great if you can answer the following two questions that I have. 1) Is the PSP that is making funds transaction a part in the 3DS? 2) If the seller turns on 3DS, and issuer bank does not, what will happen? In terms of buyer user experience. 3) Can the seller turn on 3DS based on which issuer bank has turned on 3DS? Thanks a lot!
1. Yes - there is something called PSP initiated 3DS 2. The issuing bank will not be able to respond. With PSD2 and SCA is kind of mandatory to support though 3. Merchant connects to directory server for 3DS auth however there are out of scope and exemption cases. For example low value under 30 euro transaction may not be required to be authenticated. I don’t think they can turn it off in any case of their choice though
Is the Liability shift from the merchant/acquirer to the issuing banks mainly to make business conditions fairer for everyone, or would you add additional reasons? Thanks for the great content!
Thank you for liking the content . Correct liability shift sort of allows merchant to run business accepting payments without worrying about liability in case something goes wrong . Obviously issuers are large institutions better equipped to handle such cases
Thank you for the informational video. I am trying to pay with my Barclays Bank - VISA Card from UK for PAN card (INR1017) and keep getting "CARD NOT ENROLLED FOR 3DSECURE". Checked with Barclays and they can not find anything wrong. I have been in touch via Email with PAN (Proteantech in India) and they are saying card is not 3D secure. I have tried other UK cards (some belong to Mastercard) as well, same message. Not getting anywhere and any ideas?
Please kindly discuss issuer and merchant liabilities changes from 3DS V1 and EMV 3DS. Thank you and more power!
3DS V1 sun setting was announced last year and I believe this year by Oct 22 everyone has to switch to EMV 3DS (3DS V2) .
As far as liability in EMV 3DS is concerned, in most cases it will be issue me in case of chargebacks but not all. In some cases , for instance particular cases where the card was not authenticated or the authentication was rejected , the transaction liability could be with the merchant.
ECI (Electronic Commerce Indicator) value determines whether the authentication was successful or not. For example a visa transaction with ECI value of 7 would indicate that the transaction authentication was rejected hence liability with merchant. Similarly there could be other cases and values for other card schemes .
From a merchant perspective it’s always best to check with acquirer on more details specific to each card scheme.
Hope this helps
You are great. No words for sharing such a valuble domain knowledge !
very good planation in simple terms. Thank You
please do make a video on 3DS2. This video is very good and easy to understand the 3DS concepts
very nicely presented Saurabh - learning from you how to present our thoughts with utmost clarity & conviction. Keep on sharing more such videos.
Thank you Gaurav. Looking forward to more exciting content from you as well !
Nice explanation..i am planning to pivot my career in product management in payment domain..this would help me to gain knowledge on payment domain
Payments needs a lot of talented people like you ! All the best
awesome explanation, Thank you so much Saurabh
Thank you so much for the video… it’s so helpful. I should have came across it sooner
Simply understanding, thankyou. Please if you can make video on PSD2
Thank you as always for these videos
Thanks Saurabh for your explanation.
Thank you Betelhem. Glad you liked it 😊
Good video once again. Can you do a series on open banking & alternate payments
Yes thanks Arun ! You always suggest great topics 😊
Great explanation, thank you 😊
Thank you Manisha 🙏🏽
Thank you!
I have learned a lot with your help
thanks
Great video, thank you
Thanks for your videos, it's really helpful like an induction or much better:). I have a question in an online txion as you described in 3DS flow why the verification to be taken to issuer web site, an AUTH message will do the same thing rt?
Many thanks.
You are welcome!
Thank you Saurabh.
Hey Gosaye ! How are you buddy ! Thank you 😊
Hi Saurabh, You have imparted vast knowledge on PCI , Can you also please help providing What are the standard day to day activities could be with a Business Analyst in Payments and Cards domain. Like What type of usual requirements, Can you provide an example internal usage of an application for reconciliation or security monitoring. etc.
This will help me in cracking interviwe and be really appreciated. thanks in advance,
Very helpful
Hi
My questing is that, when we do an ECOM transaction so it always ask for the OTP, but you mentioned in 3DS2 there is no OTP required, the system just do a risk assessment and if the transaction is under low risk so the transaction happen successfully.
OTP does not required in POS transaction, so your statement is correct here but not with the ECOM transaction.
Please confirm, I am getting you correctly or not.
Sorry for late reply, but it appears you are right
Hi Saurabh, thanks for the informative lecture, and the way to introduce it with simple words.
It would be great if you can answer the following two questions that I have.
1) Is the PSP that is making funds transaction a part in the 3DS?
2) If the seller turns on 3DS, and issuer bank does not, what will happen? In terms of buyer user experience.
3) Can the seller turn on 3DS based on which issuer bank has turned on 3DS?
Thanks a lot!
1. Yes - there is something called PSP initiated 3DS
2. The issuing bank will not be able to respond. With PSD2 and SCA is kind of mandatory to support though
3. Merchant connects to directory server for 3DS auth however there are out of scope and exemption cases. For example low value under 30 euro transaction may not be required to be authenticated. I don’t think they can turn it off in any case of their choice though
Is the Liability shift from the merchant/acquirer to the issuing banks mainly to make business conditions fairer for everyone, or would you add additional reasons?
Thanks for the great content!
Thank you for liking the content . Correct liability shift sort of allows merchant to run business accepting payments without worrying about liability in case something goes wrong . Obviously issuers are large institutions better equipped to handle such cases
can you also make a video on how to migrate to 3ds 2, would be very helpful :)
cool vid, thank you
Glad you liked it!
Kindly make a video on PDS2, thanks
there is some content already on that topic .Could you elaborate what additionally would you like to see on PSD2
how do we migrate from 3ds to 3ds 2? is there any php library available?
I have added a link in the description of the video that explains migration details. It is from the paypal developer community website
How the 3DS Authentication of card is done?
this is what the video intended to cover , could you elaborate your question
Can I buy a 3d debit card?
please create video on PSD2- Thanks
What would you like to see on PSD2
PLEASE MAKE SOME VIDEO ON DIGITALISITION ALSO IN BANKING
Hi Pooja , could you please elaborate
Thank you for the informational video. I am trying to pay with my Barclays Bank - VISA Card from UK for PAN card (INR1017) and keep getting "CARD NOT ENROLLED FOR 3DSECURE". Checked with Barclays and they can not find anything wrong. I have been in touch via Email with PAN (Proteantech in India) and they are saying card is not 3D secure. I have tried other UK cards (some belong to Mastercard) as well, same message. Not getting anywhere and any ideas?
sorry for late reply . There could you many reasons but ultimately you need to check either with the issuer or the acquirer side to fix this