Address fields can have a maximum length of 50 characters

@veidenbaums the validation is performed per field. The shippingAddress property is an object, it doesn’t have a length validation.

Can you explain what you mean when you say the full address is 64 characters? Are you referring to the combined length of the country code, street, city, state etc?

Thanks,

Yes by combining all the fields we get 64. Here is a sample

Xxxxxx Xxxxxxx
45 Xxxxxx St
Xxxxxxxx Xxx Xxxxx Xxxxx 4563
Xxxxxxxxx

And addresses like this get the error that they are too long.

Any news here?

I have the same problem. Looks like the address is validated against 50 characters limit as a sum of all address fields.

@mixey the sum of the address fields are not totaled and validated that way from what we can tell and based on our conversations with Braintree.

Braintree validates each individual field for a length of 50.

Can you please provide an example address that will trigger the error?

Thanks

Actually, after checking the code I found out that the error message

The address data passed to the 3D Secure provider was in an invalid format. Address fields can have a maximum length of 50 characters.

comes from the plugin.

The real error code is THREEDS_LOOKUP_VALIDATION_ERROR and in Braintree documentation, it says

Occurs when a validation error occurs during the 3D Secure lookup.

.

So the plugin message is misleading, and the real issue could be somewhere else.
Will open a ticket with Braintree to figure out what’s wrong.

So the plugin message is misleading, and the real issue could be somewhere else.

Ya, that’s because the error message is deeply nested in an object returned by Braintree. So, this message was our best attempt at alerting that there is an issue without adding additional complexity related to parsing message returned by Braintree in a different format.

Will open a ticket with Braintree to figure out what’s wrong.

Please keep this thread updated with their reason for the error code.

Thanks,

Looks like it will be hard to get an answer from their support for us as we don’t know the product structure.

Hi ???Edgar,

 

Thanks for reaching out! Mariana here with Braintree Technical Support – happy to assist.

 

I understand you have questions about additional data fields for 3D Secure authentication. To ensure you’re set up to handle the switch in October, it’s important to review your current 3DS integration to make sure 3DS 2.0 is properly configured. An incorrect implementation could result in a poor customer experience and impact the success of your transactions.

 

A common issue merchants may have with 3DS implementations is ensuring that the <a href="https://braintree.github.io/braintree-web/current/ThreeDSecure.html#~additionalInformation" rel="noopener" target="_blank">additional data fields</a> are correctly formatted. These fields need to be strictly formatted as per the length requirements and if applicable, the ISO requirements. Any issue with these fields would result in a fallback to 3DS 1.0, but with the deprecation, this will now result in direct errors for the customer or the 3DS challenge failing completely.

 

This limit you are seeing is for each field. You can check the <a href="https://braintree.github.io/braintree-web/current/ThreeDSecure.html#~additionalInformation" rel="noopener" target="_blank">complete list here</a> for field requirements.

 

I hope this information was helpful. Let us know if you have any other questions.

• This reply was modified 2 years ago by Edgars V.