A merchant recently ran into an issue when integrating with us. They were trying to eliminate credit card data from their environment and instead store that data in the Braintree vault. When a credit card is stored in the vault, we generate a random token that can be used to charge the credit card in the future. Merchants may also choose to specify the token. In modern systems, merchants can usually replace credit card numbers with tokens without a problem. However, this merchant was working with a legacy system, and due tothe way that the legacy system is designed, the only data field where themerchant can store the token is the field that formerly holds the creditcard number. The problem was that the system validates that credit card numberspass a Luhn-10 check, but the random tokens that we generate are short, randomstrings. The merchant could have generated their own Luhn-valid tokens, but there was an additional constraint: due to the way that their support team used the legacy system, they needed the last 4 digits of the token to match the last4 digits of the credit card. Shoehorning our vault into this application was not going to be as easy as we usually make things for merchants.
We decided to solve the problem by building a Luhn-10 token generator for this merchant and other merchants that might be in a similar situation. The token that we generate will start with the same number as the actual credit card number, and the last 4 digits of the token will match the last 4 digits of the actual credit card number. With this in place, the merchant has successfully integrated their legacy system with the Braintree vault. This entirely eliminated the handling, processing, and storage of credit card data from their environment, which has made it much simpler for them to achieve PCI compliance and improve security.
Legacy system owners, we feel your pain and we're here to help!