Hello
I have found an intermittent bug in online ordering for 1 of my 4 delivery routes, all of which are defined by postcodes. I raised this issue with Weebly Support during January as it came up while resolving another bug I'd reported. The engineer told me to lodge a new ticket.
I tried to do this with Chat but the issue was never escalated. I then lodged an email support request in February and have followed up 3 times by email but haven't yet had a response.
I am an ex-software developer so have performed basic troubleshooting and have provided a list of addresses that have experienced the error. I get 2-3 reports weekly of erroring from regular customers whose postcode is listed in the delivery route. I have had new customers tell me it's too hard so they won't order. It seems like an issue of integration with the Google Maps API under some very specific conditions that first level support can't replicate
I'd like to get this fixed as it's costing me money. Any suggestions about how I can get it looked at? My preference is to stick with Square but I'm at the stage where I will have to move elsewhere if no-one will assist.
Thanks for any advice.
I wanted to close the loop on this long-running thread now that our Application Support Engineering team has investigated the issue.
Our team reached out to @bakerlou at the end of June to confirm that the problem has been resolved. Customers should no longer experience any issues with address validation after refreshing the item page. No further action is required on your end, as the fix has been fully implemented on Square’s side.
To reiterate the team’s request: if you or your customers notice anything unexpected, please don’t hesitate to let us know, and we can reopen the issue if needed.
For now, I’m hopeful that reports from your customers have significantly decreased since the fix has been live for about a week.
Thanks again for your patience throughout!
I would post the full bug report here, as many details as possible including screen shots of the error and of the settings that should allow said error. Once we have a full report here in the forum we can help escalate, I have a list of mods I could tag for escalation etc. But before those steps we need to view all details.
Lets start there and see how I can help 🙂
Thanks for the response. Here is the email chain describing the issue. Probably best to start at the bottom and buckle in for a long read.
Essentially, I have 4 different delivery runs, each defined by a list of non-overlapping postcodes. A number of customers have repeatedly reported that they receive a message that we don't deliver to that address, despite being in the listed postcode range. These are customers who order regularly so I don't know the magnitude of the problem with new customers. More details are provided about these addresses below. The problem occurs on a range of Phones and iPads and can sometimes (but not always) be solved by using a desktop computer.
This webpage won't let me post the complete thread as "Message cannot exceed 20,0000 characters. I'll post it in chunks below.
[For the privacy and protection of our Sellers and their customers, we have redacted this content.]
[For the privacy and protection of our Sellers and their customers, we have redacted this content.]
Hi @bakerlou, I'm one of the Community Moderators and wanted to echo @JTPets sentiment here—we're always able to escalate a case or issue you're currently experiencing when you reach out to us here!
I was able to track down your most recent case, and while I can’t go into specifics on a public platform (I won’t be sharing any addresses), it appears the issue occurs intermittently for customers attempting to check out from their mobile devices. At the time the issue was reported, our team wasn't able to replicate the issue that customers had reported (testing on an Android mobile, tablet, and PC). However, this doesn’t mean we won’t continue investigating further, and I can see that a ticket has been filed.
Out of the 2-3 reports you’ve received, have you been able to confirm if those customers are using iOS devices?
While we await your response, I’ll reach out to the last team member assisting you to check if our engineers have made any progress on the investigation.
Hello
I have reports from customers using both Apple iPhone and iPad and Android computers. I also have reports from those using Chrome on Windows 11.
Thanks
Sas
I would like to add my own account to this report, while we use a different system here in the Canadian square we too have FREQUENT issues with squares address verificaiton system, while not exactly the same here - this is something that needs more investigation
@Laurie_ Forgot the link to my most recent thread about my issues https://community.squareup.com/t5/Square-Online-Discussion/Address-verification-preventing-orders-is...
Thanks also for sharing this thread. It's obviously a known issue around the world!!
Thanks for sharing this John. It's disappointing when the solutions that have come back are all for the customer to try a range of different fixes. It's just easier for them not to order and that affects my business.
I have a reported bug where my wife couldnt place a test order on our site without clicking marketing acceptance box. It refused her address until it was clicked. The problem with these specific bugs is replication, They struggle to figure out the root cause because we are often unable to reproduce it
Hi again @bakerlou and @JTPets – thank you both for including your use cases. I agree that this will require further investigation, as it’s clear there is an issue here.
@bakerlou, I understand you’re just trying to bring visibility to this, but I’ve removed the case notes from this platform to protect the privacy of your customers. Rest assured, I have the case details on my end, and I will refer to these when escalating the issue.
In the past, similar to the advice you’ve both received, when we’ve escalated these cases internally, the response we get is that the Square Online checkout page pulls data directly from Google Maps. Because of this, addresses need to be formatted exactly as Google Maps has them. However, this doesn’t explain why the error occurs even when selecting from the suggested list of addresses. I will also be raising the issue of previously accepted addresses no longer being recognised by the system.
I noticed that one of my colleagues has already escalated this issue internally, @JTPets. I’ll be merging both escalations but keeping the threads separate for easy access for Sellers in the Australian and Canadian Square Communities, respectively.
I’ll handle this from here – please bear with me while I escalate and await further updates from my team. Thanks again, both!
Thanks so much for clarifying the situation and I'll look forward to a solution being found!
Hi @bakerlou and @JTPets — just a quick update to let you know we’re still actively working on this!
The team has been able to replicate the behaviour with cached delivery addresses, and they're now digging into how we can prevent this error from being triggered, especially after a page refresh.
Specifically on your site, what we’re seeing is that an address is entered and verified correctly, but after the page is refreshed, it no longer shows as verified. This shouldn’t happen — once verified, the address should remain verified even after a refresh. So, the issue appears to lie with how cached address data is being handled, and that’s what we’re focused on resolving right now.
This may also explain why it’s not impacting every customer. It seems to depend on whether or not the page is refreshed after entering the address.
I’ve requested another update on this ticket today and will follow up here as soon as I have more to share.
Thanks so much for your continued patience!
Its monumental to hear them confirm a root cause!
It's only taken 4 months!!!!
For.you my friend! For me this is an issue ongoing a span of years...
Thanks so much for the update. I appreciate the detailed respone. I'm relieved that the issue has been replicated and that I persevered despite the difficulties in being taken seriously.
I realised early on it was a caching issue due to 20 years working as a software developer. In the olden days, we came across this issue often and would use the timestamp querystring trick to avoid the page being cached!
I'll look forward to an update!
I wanted to close the loop on this long-running thread now that our Application Support Engineering team has investigated the issue.
Our team reached out to @bakerlou at the end of June to confirm that the problem has been resolved. Customers should no longer experience any issues with address validation after refreshing the item page. No further action is required on your end, as the fix has been fully implemented on Square’s side.
To reiterate the team’s request: if you or your customers notice anything unexpected, please don’t hesitate to let us know, and we can reopen the issue if needed.
For now, I’m hopeful that reports from your customers have significantly decreased since the fix has been live for about a week.
Thanks again for your patience throughout!
Square Community
Square Products