search

braintree / braintree-android-drop-in

Braintree Drop-In SDK for Android
https://developers.braintreepayments.com/guides/drop-in/android/v2
MIT License
124 stars 79 forks source link

Nonce is already 3D Secure #165

Open danielebart opened 4 years ago

danielebart commented 4 years ago

General information

Issue description

The result of the DropInActivity is ErrorWithResponse (422): Nonce is already 3D Secure when the activity is destroyed.

Steps to Reproduce:

This is an old related issue in the braintree_android repo: https://github.com/braintree/braintree_android/issues/181

I was able to reproduce this issue also on the Demo app in the repo:

Screenshot_1575384256

danielebart commented 4 years ago

After digging a bit into the Dropin code, it's quite clear that ThreeDSecure#performVerification it's called again after retuning from the 3DSecure verification when the DropInActivity is destroyed.

sestevens commented 4 years ago

@danielebart Thanks for opening this issue. We'll take a closer look and post updates here.

sarahkoop commented 3 years ago

Hi @danielebart - We've released version 6.0.0-beta2 of the Drop-in SDK that should resolve this issue. We will post an update here when it has reached general availability.

soarb commented 2 years ago

@sarahkoop @danielebart I can confirm that this still appears to be in issue with drop-in:6.2.0.

This is in our Sandbox environment with test cards: 4000000000001091 and 4000000000001109. Seemingly anything that actually triggers the 3DS Flow.

On entering the OTP code in the challenge UI, once the browser switch returns to our App, I can see in our logs the expected liability shifted and possible flags are correct, based on the test card's scenario as described here

We're able to mitigate this, as the first successful lookup and verification is returned to our App and we don't process the duplicate, which causes the "nonce is already consumed" error to be logged in the background.

Can anyone please confirm that there's a fix for this?

soarb commented 2 years ago

Also the same occurs when choosing Google Pay as the payment method (for a non network tokenized card).

Again, I only take the first response as all associated Activities (should!) have been disposed of, so the second call doesn't make it back to my App

In this case the second lookup which gets triggered (I honestly have no idea how!) and subsequently handed off to the ThreeDSecureClient's continuePerformVerification method results in the following error:-

{"error":{"message":"Record not found"},"fieldErrors":[]}

Whereas the first call works fine.