[ape4]

What if a real users mistypes their credit card number... your order was successful.

[extrapickles]

The last digit of a credit card number is a checksum, so it can catch most of those errors.

See https://en.wikipedia.org/wiki/Luhn_algorithm for details

[devicenull]

You check the card number via the Luhn algorithm, and tell them about it? That's not giving any data to fraudsters.

[ape4]

Luhn doesn't catch everything. (It will not detect transposition of the two-digit sequence 09 to 90 (or vice versa) - Wikipedia).

But, ok, what about an innocent CCV typo.

You need to give real users errors when they make mistakes.

[mrweasel]

If you at any point have access to the customers credit card number, then your doing something horribly wrong. Unless you're the payment processor.

[ThrustVectoring]

Luhn algorithm can be done client-side - all it needs is the number.

[mrweasel]

Letting a customer enter a credit card and then parsing it on to the credit card processor means that you would need to be some level PCI complainant. You really really don't want to be close enough to the credit card numbers to do something with them, especially client side.

Having the credit card field, where you can access it, means that you become a target for people wanting to inject javascript into your site. Perhaps you're safe, but what about all the third party javascript libraries or tracking/remarketing/tracking script most sites have?

Sorry, it's a really bad idea. Let you credit card processor deal with the that hassle.

[nanofortnight]

You can do that client-side, easy.

[dean]

Typing the wrong credit card number would be a legitimate error, not evidence of fraud. You can show that error. It won't affect how you deal with the actual fraud.