Payment Systems, Tokens, and You

So as some of you may know I work for a medium size third party payments solutions provider. What is that you may ask? Well what we do as a company is we take your billing and communiqué data transform it into mail able information in the form of pdf’s, print, stuff, mail, and in some cases handle the payments from mail for the customers. After that we allow you to view, pay, and manage your bills online that you receive from us.  This entails some very detailed processes and the ability to be mindful of any security implications anything you write may cause (we have to be HIPPA, PCI, and HITRUST compliant). This is no small task and is much larger than the scope of this article but we will get into more of that later. I am in my essence a Secure Web Applications Architect it is what I derived my skills from… reverse engineering and though I love the latter I enjoy more making sure that people are safe and secure as I possibly can make them when using items I design/architect it makes me feel good knowing that I do everything I can to build a good secure yet agile application.

                So to the meat this article is about tokens and why they are a positive thing for you to use in your systems as you implement them and some key things to do when your building any application that takes payment information over the internet and/or public communication lines.

So first let’s start off with some key principles of things you should do with any web application you design:

1. Approach everything from the standpoint that someone is trying to steal your information. Just because they aren’t right now doesn’t mean they  aren’t going to be trying in the future.
2. SSL encryption is your best friend WHEN IMPLEMENTED CORRECTLY. The key to using ssl to simplify your over the wire transmissions is making sure you    do not use weak ciphers or transmission protocols. You should not use any CBC based cipher nor any SSL below version 3.  Use strong encryption meaning 128 bits or more.  Also avoid using TLS 1.1 and 1.0 if you can. Also do not use deflate compression. There are many reasons for what I just said but to name 2 very good reason’s they one  violate PCI standards and two make you susceptible to BEAST/CRIME attacks.
3. Transmit as little sensitive information as possible. If you don’t need to collect it and/or transmit it then don’t it’s that simple take a little overhead on your server side and look up information that you already have if possible after properly verifying the provided information from the user.
4. Log the IP address and the time stamp of the transmission of any users submitting a payment to your web site the reason for this is so you have at least one way to identify the location/point of initiation so that you can ban/monitor/provide the source of the offending transaction.
5. NEVER store credit card data in your database NEVER meaning the credit card number, cvv2, and/or stripe data again this is in keeping with PCI standards and even without those is still good practice even if those industry standards did not exist . It is ok to keep the last 4 and star out the rest of the main card number, to keep the expiration date, and card type in the case of creating a wallet but more on that later.

This will be continued in part 2 which will come tomorrow where I will continue to go through best practices and after that I will go through creating a API for tokenization with paymentsgateway.com and the code of how to do it :).  Till then don’t let your code have a meltdown.