Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subsequent 3DS lookup failure #645

Open
NabilShahid opened this issue Oct 6, 2022 · 3 comments
Open

Subsequent 3DS lookup failure #645

NabilShahid opened this issue Oct 6, 2022 · 3 comments

Comments

@NabilShahid
Copy link

NabilShahid commented Oct 6, 2022

General information

  • SDK version: 3.85.3
  • Environment: Production
  • Browser and OS: All

Issue description

We have a payment form where user can pay either through hosted fields or a saved payment method.

When the user proceeds to payment screen, we fetch client token from backend to create braintree client on browser. We pass merchant account id while generating the token on backend. We have different merchant accounts for different currencies. The merchant account id we pass, depends upon a currency selection control we have on one of the forms that users have to fill before proceeding to payment screen.

After fetching the client token for a specific merchant account, we create braintee client using the token and then we initialize a 3DS client using the same token. We use braintree.threeDSecure.create function provided by the SDK and pass "2" as 3DS version value.

When we use the 3ds client to perform 3DS, it works fine the first time. However staying in the same browser session, when user places another order with a different currency selected(and hence different merchant account), we get a 3DS lookup error from the 3ds client's verifyCard function. If the browser page is reloaded before making the second order, then it works fine. Also, this happens for payment via hosted fields and for saved card where we generate nonce at backed from vaulted payment method.
This is the error message that we get from the verifyCard function:

 "code": "THREEDS_CARDINAL_SDK_ERROR",
        "details": {
          "originalError": {
            "code": 1355,
            "description": "Transaction Lookup Not Successful, Check Transaction Id"
          }
        },
 "message": "A general error has occurred with Cardinal. See description for more information.",

So it seems like, the 3DS lookup fails when we initialize another 3DS client with different merchant account having different currency in the same browser session. Please note that we are properly using the teardown methods provided on 3DS, braintree and hosted fields clients after performing each payment.

We found a workaround for this that seems to be working for us for now. We noticed that when initiate the 3DS client, the SDK loads a songbird.js script, and sets a global Cardinal object in browser's window i.e. window.Cardinal. Deleting this object after performing each payment is working for us.

We would really appreciate any guidance here. Is the workaround correct? Would it be a good idea to fix this at the sdk level?

@SancSalix
Copy link
Contributor

For clarification purposes, are you getting a new client token and creating a new braintree client when the currency is changed?

@NabilShahid
Copy link
Author

For clarification purposes, are you getting a new client token and creating a new braintree client when the currency is changed?

That is correct, we get new client token every time before generating the braintree client.

@SancSalix
Copy link
Contributor

So digging in, the window.Cardinal is setup and managed by the Cardinal SDK that is loaded at runtime. The client token from the first transaction is used in the initialization configuration.

There seems to be no way to forcibly teardown/destroy within the Cardinal SDK. I did update the documentation to point out that window.Cardinal will not be deleted using .teardown. We've reached out to Cardinal for a more official solution, and are still working on this. In the meantime, the workaround you have should be fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants