Nonce is already 3D Secure

[danielebart]

General information

• SDK/Library version: 4.4.1
• Environment: Sandbox and Production

Issue description

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

Steps to Reproduce:

• Enable Don't keep activities in the Android Dev Menu.
• Perform a payment with a saved payment method which requires a 3D Secure verification.
• Complete the 3DS verification.
• The result from the DropInActivity in the onActivityResult is ErrorWithResponse (422): Nonce is already 3D Secure.

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:

[danielebart]

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]

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

[sarahkoop]

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]

@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]

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.