Difference in drop in challenge behaviour between 3ds checks for instant payment methods and inline card numbers

[terrymccartan-toast]

Describe the bug

We have found that using the same card number 4917 6100 0000 0000 when entering in cards will display the challenge window inline. When this card is used from an instant payment method (the test card suite using a card with 3ds). It will force a full browser redirect vs displaying the challenge window within the drop in component.

To Reproduce Steps to reproduce the behavior:

1. Ensure you have the test suit of cards from google to have access to the 3ds card
2. Load a session in the drop in and enter in the card 4917 6100 0000 0000 - notice that the challenge window is displayed inline
3. Load a new session and this time select google pay and the 3ds card. This will force the browser to do a full redirect rather than display inline. (We have attempted to use authorization data native 3ds on the initial session but its does not work)

Expected behavior Challenge behavior for both should be handled within the iframe that is loaded

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Mac
• Browser: Chrome
• Version 124.0.6367.201

• Checkout api Version 70
• Drop in component Version - 5.53.3

Additional context We are attempting to handle all 3ds checks within the drop in component and prevent the full page redirect. We have tried the docs on providing native3ds as preffered but the instant paymentMethod (e.g. google) seem to always try the full page redirect

[sponglord]

@terrymccartan-toast - I'm referring this question to our Authentication team. I'll let you know when I know more.

In the meantime can you tell us what version of Dropin/Components you are using? And against which version of the CheckoutAPI?

[terrymccartan-toast]

Hi @sponglord - its checkout api version 70 and the drop in component 5.53.3

[sponglord]

Thanks, and can you just confirm that you are setting this:

authenticationData: {
  threeDSRequestData: {
    nativeThreeDS: 'preferred'
  }
}

? re. https://docs.adyen.com/api-explorer/Checkout/70/post/payments#request-authenticationData-threeDSRequestData-nativeThreeDS

[terrymccartan-toast]

Yep confirmed we are setting it on the /sessions request and it seems to have no affect when paying with the google pay instant payment button. The full redirect still occurs.

Our question is whether the redirect is valid or should the challenge window be displayed within the drop in component

Thanks!

[sponglord]

@terrymccartan-toast - do you have a pspReference?

[terrymccartan-toast]

Sure thing. We have a couple

HG6H5C9XXQDG96F6 HDVW438TTVBVDND3 HDVW438TTVBVDND3 P4VTD49RXNXLV3X3

All of these ended up in a full page redirect - where we have seen with cards the challenge window is displayed inline

heres one where we explicitly called out preferred on the initial session JHDQFKT92WNM9J65 - (session id CSDCDE56F1331F427F)

[sponglord]

@terrymccartan-toast - thanks for the refs

To answer your question the redirect is valid - it's a legitimate flow. I'm just trying to establish (from our Backend & Authentication teams) if there is anything you can do, via config props, to influence this flow for Instant payment methods, and bring it inline

[sponglord]

@terrymccartan-toast - turns out it was an issue on our side. The GooglePay component wasn't passing on a property necessary for our backend to decide whether to route the 3DS2 through a native or redirect flow. This has been fixed in #2690 and will be available in our next release

[terrymccartan-toast]

Fantastic - thanks @sponglord for seeing this through