Any issues with Address Validation?

[William Davis]

Any issues with Address Validation?

We disabled the feature back in 2022/03 due to the following issues:

1. Three times wrong address was not not flagged, fortunately our fulfillment software caught it.
2. Twice shoppers were not able to place orders.

Has these issues been resolved?

[delcorsets]

Following. I also had to disable validation for a couple different reasons.. we found that shoppers were unable to override the suggested correct address if necessary. We also had shoppers that were unable to place orders.

[William Davis]

Following. I also had to disable validation for a couple different reasons.. we found that shoppers were unable to override the suggested correct address if necessary. We also had shoppers that were unable to place orders.

delcorsets, what a shame. We often have to reach to customers when fulfillment solution identifies a discrepancy, which delays the entire process. The "Address Validation" avoids all the, when it works as it supposed to. Thanks!

[Kent Multer]

Any issues with Address Validation?

We disabled the feature back in 2022/03 due to the following issues:

1. Three times wrong address was not not flagged, fortunately our fulfillment software caught it.
2. Twice shoppers were not able to place orders.

Has these issues been resolved?

I'm curious: why were the shoppers unable to place orders? All the address validators that I've seen include a button marked "Use the address exactly as I entered it."

Thanks --

[captainboom]

Any issues with Address Validation?

We disabled the feature back in 2022/03 due to the following issues:

1. Three times wrong address was not not flagged, fortunately our fulfillment software caught it.
2. Twice shoppers were not able to place orders.

Has these issues been resolved?

We had a developer work on implementing Address Validation for us two years ago. It never worked properly, so we don't use it. Wish it worked.

[delcorsets]

I'm curious: why were the shoppers unable to place orders? All the address validators that I've seen include a button marked "Use the address exactly as I entered it."

That button existed, but it did not work - it forced the shopper to validate again and would not move on to next step unless they accepted the suggested address. This was several years ago - we were approaching holiday at the time so we had to disable it since it was actually a liability and not an improvement. I've not tested since then to see if any fixes have been put in place.

[William Davis]

Any issues with Address Validation?

We disabled the feature back in 2022/03 due to the following issues:

1. Three times wrong address was not not flagged, fortunately our fulfillment software caught it.
2. Twice shoppers were not able to place orders.

Has these issues been resolved?

UPDATE:

I did a little digging, we disabled Address Validation on our Shadows store on 2022/03, and the last Address Validation Miva update was performed with the release of Miva 10.00.05 on 12/20/2022 (#MM-10430, Module: usps - USPS Address Validation does not display the 4 digit section of zip codes), which does not appear to be related to our issue.

I checked the Miva Merchant 10.00.x Bug Reports forum and there is one post made by lesliekirk on 2022/04/14 "mentioning" a possible Address Validation issue. I suspect our issue may not even be on Miva's radar.

Therefore, it may be a good idea to post a new bug report with all of our issues lumped together.

captainboom, do you have a little more information I can include with my bug submission (problem, errors, scenarios and date feature was disabled)?

delcorsets, is there any way you can pinpoint more or less when you encountered the problem and date feature was disabled?

This might help the Miva pinpoint the problem faster. Otherwise, I will have to post the bug without it.

[delcorsets]

William Davis After digging it appears that my attempts to activate this feature were more recent than I thought. The last time I tried to use it was around 11/15/22. - that's when I received my new USPS Web Tools API credentials with address validation.

Our issue was that despite there being a button for the shopper to keep the address as they entered it, the option did not work. The shopper was forced to select a suggested validated address, even if it was actually incorrect or incomplete, before they could move forward with checkout.

Below are notes I found from that attempt:

(Firefox Browser on Mac)

On Address Information screen during checkout:

- I entered my correct address and got the address verification pop-up suggesting a slight change to case and zip-code +4
- I chose to use address as entered for both billing and shipping addresses.
- Keeping the address as entered seems to create a loop of verification modal popping up every time. Only if I agree to use the suggested “verified” address am I able to continue.

This is definitely a problem as there a circumstances when the “verified” address is not correct or does not include important “Line 2” information.

I enlisted the help of a developer who pointed out:

Unfortunately with the address validation, I believe the user has to pick a USPS valid address before continuing. I will reach out to Miva to see if they know of a simple workaround before attempting a solution of my own.

Here’s where it states that: https://docs.miva.com/miva10/referen...20If%20enabled,(or%20accept%20the%20original)

"Validate Addresses at Checkout – If enabled when the customer enters their address during checkout (OCST) and clicks continue, they will be required to pick a validated address before continuing to the next page.”

For now, feel free to turn the validation off if you think it will limit sales.

Both of our sties where we attempted are custom, not on Shadows (or other,) framework.

I disabled the feature quickly as it was already causing problems preventing customers from checking out - around 11/16 or 11/17 2022.

[Kent Multer]

Re-reading the above comments, it looks like users have only had problems with the USPS validation. Is that correct?

Miva also provides validation thru the UPS shipping module, right? Does that one work correctly?

Are there any other services that work well? One of my clients asked about this recently.

Thanks --

[delcorsets]

Re-reading the above comments, it looks like users have only had problems with the USPS validation. Is that correct?

Kent Multer In my case, yes that's correct - I had my validation set to use my USPS Web Tools account. I'm going through my notes and plan to reactivate briefly to do some more testing this morning.

[delcorsets]

I re-activated the Address Validation feature on one of my dev sites and I'm still having the same problem.

- I'm using USPS for validation.
- I'm attempting validation during checkout after entering the shipping/billing address
- I'm actually putting in a correct address
- When trying to proceed the validation pop-up asks me to choose a validated address (same address, just formatted in all CAPS) or use the Address as Entered
- If I select to "Use the Address as Entered" I cannot proceed - the validation modal pops up again and I'm stuck in a loop.

[Eric Foresman]

I re-activated the Address Validation feature on one of my dev sites and I'm still having the same problem.

- I'm using USPS for validation.
- I'm attempting validation during checkout after entering the shipping/billing address
- I'm actually putting in a correct address
- When trying to proceed the validation pop-up asks me to choose a validated address (same address, just formatted in all CAPS) or use the Address as Entered
- If I select to "Use the Address as Entered" I cannot proceed - the validation modal pops up again and I'm stuck in a loop.

Hi delcorsets

Thanks for the info, I think I have figured out the issue and the doc https://docs.miva.com/miva10/referen...20If%20enabled needs updating.

In the mm10.00.00 released version of Shadows and Cssui framework there is a pair of hidden fields present that are missing from the shadows code example in the doc.

<input type="hidden" name="ShipValidated" value="1" />
<input type="hidden" name="BillValidated" value="1" />

Without them what you are describing should be the case as you would never get past address validation when selecting the “use as entered” option.

I have alerted someone to this issue with that doc, but until it is updated it might be better to have a look at the customer fields section of OCST on the current version of shadows and copy the forms from there.

I know that in testing the cssui and shadows framework on 10.06.00, both UPS and U.S.P.S. address validation is working as expected.