labels - Users entering the wrong decimal separators for US$ amounts

I have an application that accepts a dollar amount in $USD. Unfortunately, some people are foreign/visitors to the US and type in amounts with commas instead of periods: they format the number as XXX.XXX,00 instead of the US format of XXX,XXX.00. The different expected formats are causing issues. Even though the text input field is showing the "$" as a field prefix and I have a placeholder of "USD", people are still typing the wrong format.

Example:

Expected US: 345.60
User Enters: 345,6
accounting.js translates to: 3456.00

The user then pays $3456.00! This is obviously not good and a huge mistake. At this point, I'm thinking it's very bad for me to even try to modify the text entered. Instead, I should force the user to type in the format correctly (exact). I can easily add a format/error message below the text field which describes the correct format in more detail with examples.

If I force them to type the correct format:

• Should I allow commas?


• Should I remove commas automatically from input?


• Should I throw an error when a comma is used?


• Should I throw an error when a decimal is not used?

Note: I'm forced into the USD $ format only at this time. Decimals are 99% common, but not required for the transaction to take place. I'm looking at using a regular expression to give the warning, such as /^\d*(\.\d{2}$)?$/.

Answer

Let's talk for a minute about user expectations and magic.

A user comes to your tool with certain expectations, and not every user's expectations are the same. You're seeing this first-hand. Culture, up-bringing and life experience all shape how a user will interact with a tool, opening a vast array of expectations to potentially meet.

One expectation almost every user has, however, is that when an illusionist or magician does a trick -- say, picking a card from a card deck -- the illusionist is always going to guess their card correctly.

Put another way, if your tool is going to automate something, and going to guess what the user meant to type, it needs to get that guess correct, or the user will end up disappointed or frustrated.

As you stated as well, they may end up overcharged which, if your system changed what they entered without their express desire and increased the amount, could make you legally responsible for the overcharge and get you in trouble.

To guess or not to guess; that is the question. So, we have two courses of action to choose from:

Option 1: Analyze what's typed in and fix it

In this case, you may need to look for a solution that can better accommodate all of the edge cases you're seeing. If accounting.js isn't correctly reformatting the text, you may need to do something more custom.

Enter the regular expression.

What you'll need to do is figure out all of the patterns you might encounter, which are correct, and which need to be changed. When we start looking at common cases,

 - ###.###,## > ###,###.##?
 - ###,###,## > ###,###.##?
 - ######,## > ###,###.## or ##,###,###? 

It starts getting tricky pretty quick. To do this you'll need to do enough testing to know if your test and replacement patterns are getting it all right, and you'll need to watch out that new patterns don't emerge.

As well, if one of your patterns incorrectly changes the content, the user might not notice you've updated the amount (or, when you ask them to confirm the updated value is what they meant, they could miss an important change) and end up paying the wrong amount. What's more, if you did it for them, you might be legally on the hook.

Option 2: Guide them to the right formatting

This option will take a little less work and be safer from a number of standpoints. It's probably also more likely to end up in a pleasant user experience.

Here, still look for a strangely formatted string. Too many periods, too many digits between commas, a comma delimiting the final two strings of numbers, things like this.

What'd I'd suggest is using some implementation of live field validation to confirm that they're formatting their input correctly. When they type something strange, click out of the box, or try and submit the form, make sure to process the string to flag any of the tests you're looking for. If it fails a test, display a message next to or below the field (have a look at some of these images for ideas of how to display the messages) that explains specifically what looks strange.

Don't change anything automatically -- ask them to do that themselves.

Check again as soon as you can whether they've made correct changes. Ideally do this before they have to hit the submit button again, when they focus-off from the field for example. If it's all good, display a message (in a friendly success color like green or blue) that tells them they successfully fixed the error. If they need to try and fix it again, re-display an error message, and indicate that you checked and they still have more to do.

Oops, looks like it's still not quite right. 

This way, they know they still have work to do and the form is explicitly asking for follow-up action.

Edit: In conclusion...

Consider the use cases in front of you and which option (or mix of the two) you feel you can implement to make the experience predictable and understandable for the user.

An interesting option that combines the two is the masking that @jjwdesign brought up in the comments. The form could either guide the user from the beginning how do do the conventions, displaying a subtle ___,___.__ in the field, or it might add/convert the punctuation as the user types a value in. We just need to be careful not to do this in a confusing way; as some point out throughout the comments on the page here, overriding a user's inputs can be disorienting.

Good luck!