Customer Able to 'Bypass' State Dropdown Box? ( USA )

[YnZs]

We're located in California here in the USA, for customers that live in California, we have to charge a 8% sales tax.

What it 'looks' like to me, is somewhere somehow, the customers are allowed to bypass the 'State' part of entering
their billing address, sometimes I get orders with the state abbreviations rather then written out like the drop down
box the Basket gives them (See example Images)

The only thing that I can figure, is that when they get to payment processing (Authorize.net) I don't think that all the
information entered isn't transferred over from the cart; By way that the payment processing page use to retrieve
all the customer information directly from what they entered in the Basket (Example 3)

So, if (in Example 3) I could understand if the "WA" was sent back to the cart after the transaction was complete and
changed it in the CC database, but that wouldn't account for WHY it doesn't tack on the tax BEFORE getting to
the Payment Processing Page

 

I just did a test with an account I created and bought something expensive (See cart total)

Then put Payment processor in "Test Mode" to see the results .... seems to be a problem
on the CC end.

[bsmither]

The information sent to Authorize.Net SIM is what the customer has entered for their Billing and Shipping addresses.

If possible, use an external utility such as phpMyAdmin to view the database table CubeCart_order_summary directly. View the 'state', 'country', 'state_d', and 'country_d'. For orders made under versions of CC5 and maybe some early versions of CC6, the values in these columns may have textual entries. Later versions of CC6 will only have numbers.

Choose a suspect order. Find that order in the database table CubeCart_order_summary and view the contents of the 'basket' column. You should find evidence that the state 'id' code (12). the full name (California), and the abbreviation (CA) are all there, of which Authorize gets the full name.

Early versions of CubeCart would have problems trying to find the 'id' of a State if the input was not a known abbreviation or full name. Later versions are very good at not allowing a freeform text entry of a state name when a country that has states/counties has been selected.

I am not certain of the source of your three examples above. I must question Customer ID; 123456789. This cannot be a legitimate value.

[YnZs]

12 hours ago, bsmither said:

I am not certain of the source of your three examples above. I must question Customer ID; 123456789. This cannot be a legitimate value.

In "Test Mode" through Authorize.net, all information is fake, like Jane Doe not being a real person

I'll start looking around in the database and report back

[YnZs]

Here is what I found...

I should note, this is an order from a week ago or so, I had to change his state to Kentucky
or the "Save and Reload" button wouldn't do anything until I chose one. So, originally the
Shipping Address also had a "0" in it and it was changed, of coarse, by me.

[bsmither]

Ok, the database shows '0' for some states.

If, for some reason, javascript in the browser is switched off or has crashed, almost all of the skin will still be functional. However, the javascript that should switch the free-entry State text box into a drop-down selector pre-populated with eligible options based on the Country selected would not have done so. Thus, a free-entry of a state name that is not a Full Name (i.e., entering an illegal abbreviation) will cause this sort of problem.

Making the skin show "You must enable javascript!" before proceeding may be a bit of work, especially if javascript crashes after the page is displayed in the browser. This is certainly important enough to have a a bug report filed.

On the other hand, I think having CC6 make sure to validate the State based on chosen Country is something that needs attention. That way, the customer will be forced to re-enter a proper Full Name.

On the third hand, this many customers with either javascript turned off or javascript having crashed is inconceivable. So, there may another explanation.

[YnZs]

BINGO!!! WE HAVE A WINNER!!!

Side note: I use Google Chrome for everything I do at work
So I went to Menu>Settings>Advanced Settings>Privacy>Content Settings and Changed
"Allow all sites to run Javascript" over to "Do not Allow and site to run JavaScript" and
this is what I get:

Notice how the "State" is not a drop-down box? But allows you to fill-in-the-blank?

[bsmither]

Yes, but note what I said about too many occurrences of this is inconceivable.

[YnZs]

I dunno, some people just hate JavaScript? How do we MAKE people use it?
Or, like you said,

1 hour ago, bsmither said:

This is certainly important enough to have a bug report filed.

 

[YnZs]

Update:

I'm starting to get A LOT of these now

[Dirty Butter]

I've seen the 0 state a few times, but the zip code makes it easy, but time consuming of course, to fill in from Admin. Perhaps it's from the Estimate Shipping tool, as they input the zip code there???

[YnZs]

I would think it needs to be submitted to the designers that the "State" box needs to be a drop-down box like "Country" outside of being a Java function

[YnZs]

The plot thick'ins ....
I turn off JavaScript on a test PC, made a "mock" customer, even added an extra tax class
labeled simply as CA to see if I could get it to react. Now, I am using the "Mauris" skin and
added the NEWish Google Are you Human/I am not a Robot single click verifier.

When I get to the portion where I add my address, putting CA for state does NOT add the tax
But also, the "Are You Human" box doesn't pop up! The cart WILL NOT proceed past this
because it's expecting a verification..... see image

So my theory of "customers must have Java off and they are bypassing the drop down box"
may be false if I can't get past the "Are you Human" verification to get to Payment!

[bsmither]

It may be in when they fill in an address book entry.

[YnZs]

With Javascript Off, I get the image below, If I turn it back on, it will allow me to register
and account, but yet again, I have to have Java on to be able to get past the verification

Then once I'm verified, I turned it back off, went into my "Account" and added a default
bill/shipping address, which allowed me to use a state abbreviation and bypass the
"Are you Human" on the check out screen.

I can't say that this is how 50% of my customers are going about this EVERY time,
it seems like such a particular set of steps... and not to mention very inconvenient
for the end user.

[Laurie Smith]

Did this get fixed? I am still trying to get a store functional and this is one of my issues. There is not a drop-down box that shows on either a laptop, notepad, or mobile. Trying to get customers to type the full proper name for their state would be problematic.

Update: I found on another thread where the geo_zone table had bad data. Mine was a new install of ver 6.1.8 and the bad data is in the data.sql. These names need to be fixed for the dropdown to function: Baden-Württemberg, Thüringen, NiederÖsterreich, OberÖsterreich, Kärnten, Zürich, A Coruña. Fix the databse, clear the cache and the dropdown functions.

Edited June 18, 2017 by Laurie Smith

[YnZs]

I actually haven't seen this issue happen recently, I am currently running Ver 6.1.0 and I'm not 100% sure if there was a fix between then and now.