1

Does anyone know of any implementation of an enhanced or augmented Luhn formula for checking modulus-10 “double-add-double” check digits on payment cards?

Enhancement was suggested in this paper: http://d.researchbib.com/f/6nnJcwp21wYzAioF9xo2AmY3OupTIlpl9XqJk5ZwNkZl9JZxx3ZwNkZmpmYaOxMt.pdf

Would an enhanced Luhn check be of practical use?

  • 2
    No, not really. The only way to validate a PAN beyond the trivial is to send it to the acquirer to attempt an authorisation - in the same way the only way to validate a phone number is to call it. I don't see the point of that paper or any valid proposal contained within it, the assumption the length of a pan is a fixed 16 digits is plain wrong for a start. – Alex K. Mar 28 '17 at 10:34

2 Answers2

2

It is a little odd that this paper was accepted into a peer-reviewed journal. The paper described what essentially were identified as issues with Fletcher's checksum in the 1970s; it length and data transposition can't be detected accurately.

But let's think about the practical aspects of this proposal. If you really dig into the details, it is really infeasible to implement for many reasons.

The Luhn algorithm was made as a simple, best-effort method to validate a card number. Back when credit cards were starting to be widely processed electronically (they had been done with paper imprints before), there were no always-on networks to call a service for validation. The Luhn can be implemented with no need for network connectivity to perform the validation. This is the first premise for establishing infeasibility: you must be able to perform the validation without the need to traverse the network.

This "no network traversal" premise makes the MII lookup infeasible. There are two ways to implement this:

  1. A web service where the MII lookup is performed. This means every data entry will require one network call to validate the card number before the network call to process the payment. There is a possibility that the validation call will take as long or longer than the transaction processing. In the case of the validation, it has to be synchronous - the user needs to wait for the result before they can continue the order. If the call can't be completed for some reason, the customer may just order somewhere else.

Processing the card authorization can be asynchronous. Amazon does this; they confirm receipt of your order and will often confirm payment processing later.

  1. A periodic distribution of the MII database to all devices. Every mobile phone app, payment terminal, website, ERP, and so on will constantly need to add new MII and delete old MII. Many of them may be outdated for a period of time causing denied transactions for some merchants but approved transactions for others when using the same card. Consumers would distrust using the cards.

Finally, the author made a false assumption about the length of the card. The Luhn algorithm works well for many lengths because the card number length can be longer or shorter than 16 digits. Consumer cards are 15 digits for Amex and 16 for other cards. Commercial cards can be longer than 16 digits; I have seen commercial air fuel cards up to 20 digits. Had the author looked at the IEC/ISO 7812 standard, this would have been understood. The standards committee is even proposing extending the length of the standard card number. The great thing is that when/if the card number length is extended, the Luhn algorithm will still validate the card.

Do yourself a favor, rely on the Luhn as your first step but then let the processor do the heavy lifting for you by validating that the card is undeniably correct via the existing card processing network.

2

I did a Google search and found an implementation in software of just the same two enhancements proposed by Hussein et al, in a Luhn check by a software developer, Pawel Decowski. It is his jQuery Credit Card Validator, (Decowski, 2015/2016). I would speculate that Decowski was influenced by Hussein et al.

Decowski, P. (2015/2016) jquery-creditcardvalidator [Online]. Available at https://github.com/PawelDecowski/jquery-creditcardvalidator (Accessed 11 April 2017).