Submitting my online council tax payment last week, I made a mistake. Instead of specifying £X.00 in a freetext payment field, I missed the dot and accidentally entered by £X000!
I'm currently waiting for my refund request, but in the meanwhile, it has me thinking - is there a suitable solution for preventing this kind of thing happening to others?
Put the pence (the decimals) in a separate field and only accept whole numbers in the two edit fields (pounds and pence). If the user hits the decimal separator key in the pounds field, then move focus to the pence field.
In addition to preventing errors during editing, one should also let the user confirm the values in a different screen/layout. If you just ask a user to confirm the input he just entered, the chance for detecting errors is lower than if you present the values back to the user in a slightly different way.
Enter value:
Confirm value:
download bmml source – Wireframes created with Balsamiq Mockups
The simple solution is Radio buttons with a minimum/maximum payment. See this example from Chase.com's credit card payment form.
The only way I can over pay is if I intentionally choose other amount, I can just click one of the other payment options to either pay the minimum amount I can, my full statement balance, or my whole outstanding balance.
Another idea would be inline validation warning the user "You're payment is $X over what you currently owe!" This could be used in addition to the radio button scheme above.
Since this is dealing with money, and the common typos here (misplaced decimals, extra zeros or transposed numbers) can cost the user a lot of money, even if temporarily, I'd even say a modal dialog confirming "You are about to pay $X over the amount you owe, pay this amount?" wouldn't be excessive; alternately a red/error styled warning on the "confirm payment" screen (in addition to an inline warning) could be useful.
You should be very careful when letting a user enter payments, especially when it's likely they've made a mistake. The radio buttons are the simplest way, because the worst you can do is select the wrong bubble, and you can't accidentally select "Other Amount" unless you don't notice the other bubbles.
If you have any idea what the user should be putting into the box, then you could try to detect abnormal inputs. In your case, I suspect £6,300 is significantly more than the usual tax, so having a warning dialog informing them that their tax is 100x what you'd expect (although you'd have to factor in how it might annoy people who actually do pay 100x what everyone else does).
Another thing you could do is calculate the tax from other inputs. For example, if it's a property tax, you could have them enter the approximate value of their property (likely a number so large that keeping track of fractions of a pound is pointless), and then you calculate the tax for them.
Or, you could go the other direction -- if they put in £6,300 as their tax, then you could display on the confirmation screen that this is the appropriate tax for property value, and they could clearly see that they don't own tens of millions of pounds worth of property.
There are many options, the best is education. Let the participant know what they are doing, what they have done, and reduce assumption. Literal examples for this case: Append .00 and deal with whole amounts. Have a separate box for change. [00].[00](Adding a click or tab sucks... but safety when dealing with $$) Have the decimal point in the box so as they type the numbers move left leaving the . two from the end. More...
The solution is proper user experience design and testing. In my limited experience working in the .gov sector, there just isn't much money invested in that. In attempts to save money by outsourcing and/or investing in established existing solutions, UX is usually sacrificed, much to the frustration of many.
UPDATE:
So, yea, alas, the problem is more systematic than anything. But if I were to fix this one problem, in the least expensive/quickest way, I'd simply have some form of confirmation dialog.
You are about to pay $8723.00. Is this correct?
[ Yes, submit ] [ No, return to edit ]
I use my internet banking exclusively to pay bills and the bank has no idea of the amount on the bill, so the amount is always entered by the user. I think the root of the problem is missing the decimal point (. and , or a space depending on the country).
@Ben Brocka's solution is very nice, provided that the system knows the amount before hand or can do some analysis to determine if the amount being paid is way too large.
My suggestion is to force the user to enter the decimal part in countries where decimal currencies are used (for example, to pay a bill of $63, you will need to enter $63.00). My bank uses this and it works rather well. If the application is internationalized, you will need to allow people to use space or commas for the decimal point, depending on their locale.
The down side is that this is not of much use of countries without decimal currencies, for example the Japanese Yen, but I think it should help prevent problems for people in countries using decimal currencies.
I would probably add a special case for this particular situation. If the input is exactly 100 times the expected amount and the decimal point was left out, just "autocorrect" the mistake.
A more generalized solution could involve statistics to determine the probability that the input value is an error and use that to determine how forcefully to verify.
It may help to look at how similar problems are treated in the analog world.
Cheques require the payer to write out the amount in two forms: as a number and spelled out ("SIXTY-THREE POUNDS AND 00/100"). Maybe it would make sense to echo the input in words. You likely wouldn't have missed "SIX THOUSAND THREE HUNDRED POUNDS" on the confirmation screen.
At a restaurant, when we pay with a credit card, we're required to do a little arithmetic, adding the tip to the subtotal to fill in the total. If the application knows the amount of your tax bill, the confirmation screen should show your balance after payment. If that balance is negative, it should be clearly highlighted.
