1

For card payments we accept a security code of 3 digits.

In some instances on some browsers (likely to be older IE versions) we have had occurences of a code with a 0 at the start (example 012) having the first 0 removed thus only allowing the input of 12. This therefore invalidates the security code.

We have this as a number input to allow number input only on mobile devices, I've a feeling this is the cause. However, is there anything we can do to stop this from happening?

The current input code is:

<input type="number" pattern="[0-9]*" size="4" value="$securitycode" name="securitycode">

Many thanks in advance.

Daffy
  • 89
  • 1
  • 7
  • 2
    Well technically, although it consists only of numbers, I see it as a string input as you need 3 characters and don't actually care about the numeric value of the field. So you should validate it as a string that should contain numbers only digits, not as a number... and therefore change your input type. – Laurent S. Jun 02 '14 at 12:49

2 Answers2

1

This behavior is according to the spec, so I don't think you can directly do something to prevent it.

If the user agent provides a user interface for selecting a number, then the value must be set to the best representation of the number representing the user's selection as a floating-point number.

Specifically, the smoking gun in the definition of "best representation" is

(11). Collect a sequence of characters that are ASCII digits, and interpret the resulting sequence as a base-ten integer. Multiply value by that integer.

I am assuming that you want to keep the input type so that mobile user agents present to the user a UI better suited to the task of inputting a numeric code. So what you can do is, since you now know what the spec says, anticipate this behavior on the server side: pad the incoming value with zeroes.

Jon
  • 428,835
  • 81
  • 738
  • 806
  • Jon, thanks for your answer. The issue with padding with zeroes is that not every security code will begin with a 0. I'm not technically gifted enough to wizard together a bit of code that will magically add a 0 if there is meant to be a zero. I've found this potential fix: http://stackoverflow.com/questions/7833257/input-type-number-new-validation-removes-leading-zeros-and-formats-number-in-s – Daffy Jun 02 '14 at 12:57
  • @Daffy: I 'm not sure what the problem is. Security codes are 3 digits or 4 if AMEX. You can tell if the card is AMEX from its number, so pad to either 3 or 4 digits as appropriate with zeroes. If there are already as many digits then padding will be a no-op. Using `type="tel"` is an excellent idea *provided that the spec guarantees the behavior you want* (I haven't cheked). – Jon Jun 02 '14 at 13:02
0

It seems changing the input type to "text" might resolve this issue.

Tanel Eero
  • 642
  • 3
  • 8