Cross-posted from Admin and IT:
HiHas anyone recently turned on address verification for their credit card transactions? We are very close to turning this on but have one remaining question about tokenized cards - if their primary address is not their billing address, can you use a tokenized card? Do you have to enter the billing zip code in the payments screen? How does that work with auto-billing? If anyone has been through this transition and is willing to share their experiences, I would love to hear them!ThanksJess LevySan Francisco Operajlevy@sfopera.com
One thing to keep in mind, it is my understanding that there is no libality shift without AVS. So even if have something that can handle 3DS, it will not matter without AVS happening.
The card scheme (e.g. Visa, Mastercard, etc.) liability shift rules do not currently depend on AVS. This might have been the case previously; each scheme's liability shift rules have changed substantially, multiple times (and with regional variations) since version 1 of 3DS.Right now, a 3DS version 2 transaction that is "successfully completed through either frictionless or challenge flow" will result in a liability shift. This is true even if AVS is not enabled—and usually even if AVS is enabled and the customer fails the AVS challenge. Depending on the region, the transaction doesn't even need to pass through the frictionless or challenge flows for the liability shift to happen.
Adyen has some documentation here about Visa and Mastercard's conditions for the liability shift: 3D Secure for regulation compliance | Adyen Docs
That said, my reading of version 2.3.1.1 of the 3DS specification is that a card issuer can use the result of a customer's prior AVS challenge to help them decide whether to authorize a 3DS transaction. So it's theoretically possible that an issuer could decline a 3DS transaction based on failing AVS (normally a decision made by the payment processor), but this wouldn't affect the liability shift.
The other interplay between 3DS and AVS is that, for members using Merchant Services, we can 3DS to reduce the impact of failed AVS checks. If there is a 3DS liability shift, we can reduce a transaction's risk score so that even if a customer gets their ZIP wrong, we can authorize the transaction. In this case, there's zero risk of a chargeback to the member organization (because of the liability shift) and the legitimate customer has their transaction authorized even though they made a typo or had a memory lapse.
Thanks Nic. I am still trying to wrap my head about 3DS v2. Yes, what I stated was based on 3DS 1 rule set.