Mitigate `Authentication Required (2099)` issues flagged as `lookup_error`s (optional field `ip_address`)

[glenn2223]

General information

• SDK/Library version: 5.15.0
• Environment: ALL
• Language, language version, and OS: .NET7, Windows server 2019

Issue description

This is linked to case 11979868 (email communication with Saravanakumar S over at technical support)

We've had a lot of Authentication Required (2099). After checking the transactions, there was a common error - a lookup_error.

It was highlighted that these were caused by users having multiple IPs, that are comma-separated (eg 1.1.1.10, 1.1.1.20).

~In my code, I do not pass any IP address info. After checking your source code I can not see anything to the same effect either. It must be something lying within the .NET code itself - when you start creating requests and whatnot. it seems like we need to either address the IP address issue within the code or...~

Can you update your expectations in the API itself (as to expect the possibility of multiple IPs)?

Edit: found the IP being passed - whoops. Turned out it was the 3DS request and I was checking the sale request 🤦‍♂️

[hollabaq86]

👋 @glenn2223 thanks for reaching out. Can I get a little more info to try and identify where any improvements can be made? Are you performing lookups via your client-side integration (i.e. using verifyCard in our JS SDK or its equivalent in our native SDKs), or are you performing lookups on your server-side and then supplying that info to your client?

[hollabaq86]

To be fully transparent, our support teams will need to partner with our MPI provider CardinalCommerce to confirm that your entries for this field are, indeed, the root of these lookup errors.

Once folks get confirmation of behavior on Cardinal's side they can forward that feedback on to the correct engineering teams to update our documentation (or update our API to reject 3DS verification requests if this field is misformatted).

I'm going to close this issue (but please still answer my earlier Q even though the issue is closed) since this feedback pertains to API behavior and not an issue with the SDK. I recommend you forward this public issue to Saravanakumar on Support so they are fully brought up to speed. We work with Support teams regularly, so please don't mistake my closing this issue to mean nothing is happening with your feedback!

[glenn2223]

Hey @hollabaq86, thanks for coming back to me.

The lookup is happening client side - I originally opened it here as I thought it was a .NET SDK issue. For full disclosure, the 3DS info is created using the .NET SDK classes and then serialized

JUST AN FYI: a summary of the TS code:

```TS hostedFields.create( { // My Options }, (hostedFieldsErr, hostedFieldsInstance) => { if (hostedFieldsErr || hostedFieldsInstance === undefined) { // Handle error return; } // ... more code // Listen for form post common.form.addEventListener( "submit", async function (event) { event.preventDefault(); //... more code // Ensure the deviceData request succeeded (3s max) if (firstPass && deviceData == undefined) { for (let i = 0; i < 3; i++) { if (deviceData) break; await new Promise((resolve) => { setTimeout(resolve, 1000);}); } if (deviceData == undefined) { // Show the "Do you have an AD Blocker?" message firstPass = false; return; } } // Get the 3DS info from the server const xhttpPost = new XMLHttpRequest(); xhttpPost.onreadystatechange = function () { if (this.readyState === 4) { if (this.status === 200) { // GET 3DS data from server const tds = JSON.parse(this.responseText); hostedFieldsInstance.tokenize((tokenizeErr, payload) => { if (tokenizeErr || payload === undefined) { tokeniseErrorHandler(common, tokenizeErr); return; } tds.nonce = payload.nonce; tds.bin = payload.details.bin; // DO threeDSecureData.verifyCard(tds, CALLBACK); }); } else { // ... more error handling } } }; xhttpPost.open("GET", `/Get-Some-ThreeDSecureInfo`, true); xhttpPost.send(); }, false ); } ); ```

[hollabaq86]

Thanks @glenn2223 wanted to give a quick update: we're updating our client SDK reference docs to be more clear about IP address input requirements, AND the engineering team that owns the part of our API that handles lookup requests is going to be adding a more clear validation error when folks submit IP addresses that don't match the format CardinalCommerce can accept.

This means you'll receive a more clear validation error message, that bubbles up earlier in the request chain. I don't have an ETA on when this validation error will be deployed to our public API, but it's actively being worked on.

Thanks again for the feedback!