braintree-web-drop-in
braintree-web-drop-in copied to clipboard
Allow skipping 3DS for vaulted cards
General information
- SDK/Library version: 1.33.0
- Environment: Sandbox
- Browser and OS: Firefox 91.6
Issue description
We are using the vault manager to allow customers to choose their default payment method, and we want to 3DS verify all new payment methods added to the vault. However, since we enable threeDSecure on the drop-in UI, it then requires us to provide 3DS options whenever we requestPaymentMethod or else we get an error. This means 3DS runs even for already valuted cards when they are selected. It would be great to be able to skip the 3DS check for an already valuted-and-verified card.
I think this is a good use case, thanks for recommending it. I've added it to our backlog and we'll update here when it is available.
After thinking about this a little more, I'd love to know your use case for not re-verifying the card.
My understanding of the way 3DS works is that our MPI provider, Cardinal, takes the customer info that gets passed in the threeDSecure
object as well as identifying information about the device being used and then determines if it is likely that the customer checking out is the one that owns the credit card. If it determines that it is, then no challenge is issued. And if there's a question about the ownership, then a bank challenge is displayed to confirm it.
So all that said, in most cases in production, given enough identifying customer information, the customer should not be challenged when using an already vaulted card.
Is there a good reason to manually disable these checks?
My understanding is that for one-time transactions using a vaulted card, they should still run through the 3D Secure flow to ensure that liability does shift (though, again, ideally the customer won't be presented with a challenge in that case).
We still plan to provide a hook for the onLookupComplete
callback we provide in the underlying core SDK, which should give you some flexibility to decide whether you want the challenge to run or not.
So in our use case, everything is recurring / usage-based billing. So we only do the 3DS when vaulting the card with "0.00" amount and we force challenge. Then we use the 3ds authentication id later at recurring transaction time. Drop-in isn't even presented at transaction time, so I do understand it's different from the "normal" checkout style flows that many people would be building.
Thanks for the context, we have this item in our backlog to explore.
👋 going to close this issue since it's a feature request and not a 🐛, but please note that we are still exploring this request.
For internal tracking, issue 3211