Open source contamination is the bane of many independent software vendors (ISVs). If even a tiny snippet of open source code makes it into your build, the entire application might legally be reclassified as “open source.”
To avoid this, developers must invest a lot of time creating bespoke code entirely from scratch. As an ISV, there’s another type of “contamination” of which you need to be aware — one that has to do with payment security. Or more specifically, PCI compliance.
If the applications you build ever capture, process or store credit card information of any kind, those platforms must adhere to the data security guidelines of the Payment Card Industry (PCI) Security Standards Council. Otherwise, your end-users may be subject to:
- Payment fraud
- Punitive fines
- Costly litigation
Programming around this adds many layers of complexity, which is why ISVs often avoid payment integration altogether. However, clients increasingly expect this type of functionality in the tools they choose. If you’re unable to provide turn-key solutions that work out of the box, those clients will find an ISV that can.
Designing your applications around payment security isn’t necessarily easy, but there are many best practices you can adopt to make the process a little simpler.
Below are some of our favorite tips.
Payment Security Tip 1: Password Management
When a user first logs into your platform, he or she should be required to create an entirely unique password. Sticking with default credentials should be impossible.
Moreover, all newly created passwords should be of a certain length (i.e., 16 to 20 characters). Ideally, they should use a mix of letters, numbers, special symbols and/or “pass phrases.” Any password that doesn’t meet these criteria should be automatically rejected.
In addition, the programs you design should never store passwords as plain text. Instead, use encrypted ones stored as salted hashes.
Finally, consider requiring (or at least offering) two-factor authentication (2FA). This extra layer of security may annoy some users, but 2FA is one of the most effective methods for preventing unauthorized access to accounts.
Payment Security Tip 2: Principle of Least Privilege
Lower-level personnel should never have access to higher-level information. In other words, access should be granted on a “need-to-know” basis.
Also known as the “principle of least privilege,” this concept doesn’t apply just to people. It also applies to hardware and software. All information should be walled off unless that information is vital to that individual’s or system’s duties.
This restricted access is a good idea no matter what types of tools your team is building, but it is absolutely necessary if those applications handle credit card data of any kind. After all, people (and machines) can’t steal what they can’t see.
Payment Security Tip 3: Build for the Cloud
The larger IT industry is moving away from on-site applications, in favor of cloud-based platforms. As an ISV, there are compelling reasons why you should also embrace this trend.
One of the biggest reasons: Patching bugs and releasing updates becomes easier when your programs live in the cloud. In fact, you can push those updates and patches without requiring specific action from busy or uninformed end-users.
Payment Security Tip 4: PCI Compliance
You can’t control what payment processors your clients use, but you can design your platforms to work seamlessly with PCI-compliant processors you trust.
If you provide easy-to-follow documentation to help end-users get up and running as quickly as possible, many of them will use those hand-picked payment providers you’ve already selected. Using the default option is simply easier for them.
Payment Security Tip 5: Data Encryption
True payment security means encrypting any payment data that enters, is stored on or leaves your system. You should always encrypt all information — not just credit card numbers — as much as possible.
- Tokenization allows you to replace sensitive information with one-off tokens.
- Point-to-point encryption (P2PE) allows you to transmit encoded information across unsecured networks.
- Hosted payment pages remove the need to capture, store or process customer data within the systems you build.
Although none of these will automatically make your platforms “PCI-compliant,” they can help to limit your client’s fraud exposure.
Payment Security Tip 6: Fraud Filters
Another common strategy is to limit the number of login attempts, IP requests and credit card sales over a certain period of time.
For example, imagine that most of your clients work in the restaurant industry. It’s very unlikely any of them will make more than 500 new sales per hour. Therefore, you can hardcode reasonable limitations into your applications.
Alternatively, you can work with payment processors that offer fraud management filters. That way, end-users can set their own rules for flagging suspicious activity.
Payment Security as a Competitive Advantage
Adding extra safeguards to your platforms requires additional work. This is why many ISVs regard payment security as an inconvenience. For the team at CardConnect, we view it as a competitive advantage.
Cyberattacks, payment fraud and data breaches have become the new normal. ISVs that specialize in secure payment integration will win the lion’s share of new business, today and tomorrow. Although payment security isn’t always easy to manage, we have a department dedicated to helping ISVs design PCI-compliant applications and tools.
If you'd like to learn more about our unique approach to payment security, schedule a free consultation by filling out the sign-up form here.