Blog

There are a couple of changes coming in the credit card space that are "small" to consumers, but probably have a big impact to merchants, particularly if you're running your own billing platform.

1) MasterCard is adding new BINs. Starting October 1, 2016, MasterCard issuers will have new card numbers. In addition to the old 510000-55999 series cards, they'll be issuing cards in the 222100-272099 BIN range.

2) Expanded use of 19-digit PANs. While technically there have been several card types that support 19-digit Payment Account Numbers, Visa is now issuing some cards with 19-digit PANs. This is expected to increase over time.

What does this mean to merchants? At the risk of dating myself, this change is likely to be similar to the old "Y2K exercise." It's a system-wide change that can be easily absorbed if managed correctly.

For those who may not have been working professionally in 1999, there was a massive exercise to audit and repair systems prior to Dec 31, 1999. The shift from two-digit year fields (1980 was originally stored as just 80) to a 4-digit field isn't a huge effort, but it does require a complete check of the entire system. I ran this effort for my employer at  the time. Even though we were developing in C+ and Java, we still had to certify for all of our clients. It isn't hard to do, but it does require a very thorough QA process to confirm there won't be any unintended problems.

Some key areas to consider and questions to ask your team:

Input validation: Does your input form validate card length? If you're performing a Luhn Check to validate the card type, make sure it will also handle the longer PAN field.

Display Fields: While modern screens are a lot easier to update compared to old fixed-width fields, you'll still want to ensure the fields are long enough to display correctly, and that it doesn't upset an otherwise attractive user interface. Likewise, displaying "last 4" needs to truly be a right-to-left reading of the card number, not just "skip the first 12 digits." It's a little thing, but I promise that there are developers who have written code this way, and they'll need to make appropriate updates.

Internal Field Length and Storage: This will require a systematic review of the underlying platform to ensure that all storage is adequate for the longer card fields. Note that this also applies to the encrypted field – a longer input generally creates a longer encrypted output.

Internal Logic: Those who get deeper into the technical aspects of card processing may have logic built in that handles different card brands differently. Those folks will need to undertake a complete review or internal logic, including chargeback rules and retry logic, as well as any data warehouse feeds to ensure a complete and accurate picture of card activity. For example, when reviewing all MasterCard transactions through a data warehouse, it would be important to consider the new BIN range so that cards.

This shift is not wildly dramatic, but it also can't be ignored. It makes sense to catch both of these changes in the same code updates, and to update the complete QA suite so that all releases going forward are properly regression tested for these use cases.