We’re using Square to handle payments for a business in London, where people from around the world come to take classes.
A significant number of customers are unable to complete the checkout process because Square considers their valid, working phone number to be invalid (either returning INVALID_PHONE_NUMBER from the API or displaying “A valid phone number must be provided” on the checkout page). This prevents them from paying for a class.
How does Square decide which phone numbers are valid?
For example, a number of the format +44 077xx xxx xxx is being rejected; it is a valid UK mobile number, but I suspect Square may be misidentifying it as a virtual number 070 xxxx xxxx or pager 076 xxxx xxxx.
If that’s not the reason, I would like a little more information on how Square validates numbers, because right now we’re unable to support our customers who want to know why they are being told their phone numbers aren’t valid.
If this documentation helped you find a solution, please check the box indicating that this reply solves the problem.
Otherwise one of our Developer Advocates will provide additional assistance shortly.
Square checks if the number is valid based on the country code and the length of the number. However, it doesn’t check if the number is actually in use or if it’s a virtual number or a pager.
In your example, the number +44 077xx xxx xxx should be a valid UK mobile number. If it’s being rejected, it might be due to an issue with the formatting. Can you try removing the leading zero after the country code, making it +44 77xx xxx xxx, and see if that resolves the issue.
You’re correct that the leading 0 should be omitted after the country code +44. However, in every case I have observed, the Square API treats the number with and without the leading 0 the same way.
Also, adding or removing a leading 0 is the first thing the users are trying when they are told their numbers are invalid.
Including or omitting a leading zero does not matter. Square responds to either variation the same way.
It is clearly doing more than checking the number of digits, as it rejects some fictitious numbers which are reserved for use in TV and movies.
The same validation rules appear to apply in sandbox and production (which is annoying, as I cannot use fake numbers for test purposes in the sandbox).
I wrote a small script to create a payment link with a specified number.
Treated as valid both in sandbox and production:
+440772431xxxx (actual customer number, redacted)
+44772431xxxx (actual customer number, redacted)
+440798105xxxx (actual customer number, redacted)
+44798105xxxx (actual customer number, redacted)
+441617151234 (fake area code used on Coronation Street)
Treated as invalid in both sandbox and production:
+447700900123 (fake UK mobile number)
+4407700900123 (fake UK mobile number)
+441154960004 (fake number in Nottingham)
+4401154960004 (fake number in Nottingham)
The good/strange news is that a number that is failing for a customer is working for me in my test script, so I’ve got more work to do to figure out what the difference is.
It would be helpful to know if Square is using an open source library for phone number validation, like Google’s libphonenumber. Then I wouldn’t have to experiment with the API to discover what the validation rules are.