threeDSecure flow stops if Init request to cardinal fails

[dav1d8]

General information

• SDK version: 3.97.3
• Environment: Production
• Browser and OS Chrome 119 windows 11

Issue description

We are using threeDSecure payment on our website, but in some cases the payment flow stops. I figured out that it happens if the request for the following url fails for any reason. You can reproduce using ModResponse Chrome extension and set failed as error reason for this url: https://centinelapistag.cardinalcommerce.com/V1/Order/JWT/Init

In this case initiateV1Fallback in songbird.js is called with errorType="cardinal-sdk-setup-error.number-10001" and nothing else happens. I'd like to know if v1 fallback happens and show an error message to the user. Would it be possible to emit a new event in initiateV1Fallback function, for example "v1-fallback"?

SongbirdFramework.prototype.initiateV1Fallback = function (errorType) {
  this._useV1Fallback = true;
  this._removeSongbirdListeners();
  analytics.sendEvent(
    this._createPromise,
    "three-d-secure.v1-fallback." + errorType
  );

  // emit an event here, like: this._emit("v1-fallback", errorType);

  if (this._songbirdPromise) {
    this._songbirdPromise.resolve();
  }
};

Then subscribing and showing an error message would look like this

threeDSecure.on('v1-fallback', (errorType) => {
  //throw new Error('threeDSecure v1-fallback: ' + errorType);
});

Also in songbird.js initiateV1Fallback is called in other cases as well, for example with errorType "cardinal-sdk-setup-timeout". It would be necessary to show error messsages in these cases too, adding a new event looks like a good solution. What do you think?

[hollabaq86]

👋 thanks for reaching out. This particular scenario raises some changes we should make to the SDK.

For background, 3DS v1 was deprecated late last year, and as a result any code we have that's opting to fallback to V1 (like when the songbird.js library fails to load) is ultimately going to result in a failed transaction. Even in scenarios where the v1fallback where to succeed on the client, later on when trying to submit a transaction, you'll get a processor decline code 2099. This happens because the card network rejected the 3DS v1 verification. So why even go through the fallback flow in the first place? I think this is a 🐛 that's only surfacing now that 3DS v1 is no longer accepted.

I think we may want to change this behavior so that instead of falling back to V1 we do the following:

• try to reload songbird.js, just in case this can save the client flow 😄
• if cardinal SDK fails to load after retry, surface the THREEDS_CARDINAL_SDK_SCRIPT_LOAD_FAILED network error that 3DS isn't available at the time

Based on the context I provided, do my proposed changes make sense?

[hollabaq86]

In regards to this particular issue with this error code you're seeing, please contact Technical Support with timestamps and the BIN of these failed requests that's resulting in these errors. Our Support teams will be able to use that information to escalate to our MPI provider CardinalCommerce and figure out what's going on

[hollabaq86]

for internal tracking, issue 29858

[dav1d8]

Thanks for the background of v1 fallback. I agree if v1 fallback is not needed anymore then better to solve this issue as you proposed.

[dav1d8]

Any news on this issue? Thanks