No UI feedback presented for 3DS BraintreeError

General information

• SDK/Library version: 1.25.0
• Environment: Sandbox and Production
• Browser and OS: Chrome on Windows 10

Issue description

The DropIn doesn’t show any UI feedback when requestPaymentMethod() errors due to a 3DS issue.

To Replicate

• Go To https://codepen.io/braintree/pen/KjWqGx
• Use the “Error on Authentication” 3DS test card 4000000000001125, 01/2024
• Click “Pay Now”
• You can see the error showing in the console but there is no feedback to the user that anything has gone wrong

Compare that to the feedback given for things like invalid card number:

---

As a 2nd point to this; if we are supposed to handle the UI of these errors ourselves, how are we supposed to differentiate between the errors which the DropIn has already presented feedback for and the ones which it has not?

Currently I am doing if (error.name === 'DropinError' && error.message === 'No payment method is available.') to detect the handled ones but that feels very fragile.

[crookedneighbor]

I think the ideal way to approach is a combination of option 1 and 2. Since the 3ds verification only happens as a result of calling requestPaymentMethod, it’ll need to reject anyway when the 3ds flow fails in the authentication step.

To fully present option 2, where we expose an error to the customer, we’ll need to request translations from our localization team, which can take several weeks to process. In the interest of time, we’re going to go with option 1 for now. Hoping to get a release out today or tomorrow.

Here’s the PR with the important changes: https://github.com/braintree/braintree-web-drop-in/pull/734/files#diff-0d0ab97f65c6ac07702445a897547e6abf9cf3a768bf656288deadde0d4030a6R896-R905

This change will present a better error for the merchant, clear out the consumed payment method, and refresh any vaulted payment methods (if the client token used was encoded with a customer id).

In the future, if there’s still interest in doing so, we can add an option when creating Drop-in to return the customer directly to the card form when authentication fails (when the card form is what initiated the 3ds flow).

For now, once this gets released, my recommendation is to utilize the card.clearFieldsAfterTokenization: false option when creating Drop-in so that the customer’s credit card info is persisted after tokenization completes. That way, they can simply choose the card option and see their previously entered card info pre-populated in the card form.

[crookedneighbor]

Hey, sorry for the delay.

I’m talking with our 3d secure team about what the right approach for this kind of error is. What we’re currently doing is definitely not right, since it leaves Drop-in in a state where it looks like the nonce can be used, when it has already been consumed and will error if you try to call requestPaymentMethod again.