> <i>But here’s how you can mess it up:</i><p>> <i>• Not having dynamic error validations before someone goes ahead with the payment. It is as simple as using the Luhn algorithm to make some basic checks.</i><p>On the other hand, someone that does validation of their own is <i>far</i> more likely to accidentally filter out valid values. This used to be rather common on email addresses. (I’ve been using almost exclusively @chrismorgan.info addresses since about 2010, and had one rejected exactly once, from a regular expression that thought TLDs were only two or three characters long; I was able to use my skills to bypass the check, and the backend accepted it.) Nowadays, people <i>normally</i> just leave client side validation to whatever <input type="email"> does.<p>So, payment card numbers. I’ve only ever had a 16-digit one, but they can actually be 10–19 characters long, and some people are <i>sure</i> to have hard-coded maxlength=16 and/or minlength=16 (or equivalent JavaScript checks).<p>There are also those ridiculous things that insist on splitting the card number into multiple fields (four groups of four characters), but that’s generally just painful to work with rather than actually preventing you from using it.