With the latest version of the Hosted Fields, I can't trigger _THREEDS_LOOKUP_VALIDATION_ error. I don't want to accept accented characters in the Billing Address. This feature worked in the v3.52.0.
threeDSecure.verifyCard({
challengeRequested: true,
amount: '6.00',
nonce: payload.nonce,
bin: payload.bin,
email: '[email protected]',
billingAddress: {
givenName: $("#BillingAddress_FirstName").val(),
surname: $("#BillingAddress_LastName").val(),
streetAddress: $("#BillingAddress_StreetAddress").val(),
locality: $("BillingAddress_Locality").val(),
region: $("BillingAddress_Region").val(),
postalCode: $("BillingAddress_PostalCode").val(),
},
//additionalInformation: {
// shippingGivenName: $("#BillingAddress_FirstName").val(),
// shippingSurname: $("#BillingAddress_LastName").val(),
// shippingAddress: {
// streetAddress: $("#BillingAddress_StreetAddress").val(),
// locality: $("BillingAddress_Locality").val(),
// region: $("BillingAddress_Region").val(),
// postalCode: $("BillingAddress_PostalCode").val()
// }
//}
}, function (err, response) {
if (err) {
logError(err);
if (err.code.indexOf("THREEDS_LOOKUP_VALIDATION") === 0) {
If I'm uncommenting the _additionalInformation_ part, it will work and I get the proper error.
This has nothing to do with the SDK version, but with the API that the SDK calls out to. I've let our Fraud Tools team know about the change and we're looking into it.
After more looking, you're right that this was a bug that was introduced in the latest version. (it corresponded with an API change that I thought was related to this, but turned out to be a red herring)
We'll get a release out for this to fix it soon.
This is fixed in 3.54.0, thanks for alerting us!
Thank you for the release!
Could you please check one more thing for me: I have upgraded to the latest and it's working, but the cardholder name validation is still broken for me. Based on the example it has the same rules:
a validation error occurred
likely some non-ascii characters were included in the billing
address given name or surname fields, or the cardholdername field
I think I'm using it properly. It's included in the options object of the tokenize call.
The cardholder name field is not used by the 3ds lookup when tokenized in hosted fields. (we're looking into pulling the cardholder name off of the nonce if it is not provided to the 3ds verifyCard call, but it's not available yet)
So, you are saying that we can use non-ascii characters in the cardholder name field and the comment is outdated?
I assume you're talking about this comment:
// a validation error occurred
// likely some non-ascii characters were included in the billing
// address given name or surname fields, or the cardholdername field
You are right, that comment is a little misleading. It shouldn't say "or the cardholdername field" (though we're looking into adding an additional field to the billing address options which is the cardholder name, and that would be subject to the same rules)