Nate Hughes
CRO / Co-Founder

Nate Hughes is a veteran in the payments industry with over 23 years experience. Nate began his career in payments at Authorize.net, now owned by Visa and a leading payment gateway. He currently serves as the Chief Revenue Officer and Co-Founder of Zift. 
Read more

Marc Roberts
COO / Co-Founder

Marc Roberts is the COO and Co-Founder at Zift. Marc has over 15 years of experience in the payments industry helping businesses optimize payments and software companies embed payments into their platforms.
Read more

Are You Leaking Cardholder Data?

PCI Security

PCI Compliance: Unveiling Risks

Every day thousands of companies receive credit card data from many sources and store it in a variety of locations. Are you aware of every location credit card data is being stored within your organization?

It’s surprising how many companies are unaware where they are storing credit card and other sensitive data and their resulting non-compliance.

If you are a merchant processing credit cards you are required to comply with all 12 of the PCI requirements. This applies to merchants who maintain their own systems or use third party systems and gateways for payment facilitation.

It’s important to be aware of some of the overlooked areas where card data may be stored. It’s widely understood by most merchants and service providers that card data stored in a database should be encrypted and protected. However, there may be some unexpected card data storage locations within your organization.

This is usually because of missing policies and procedures or insufficient technology controls. Here are some of the more common locations where unexpected card data storage occurs.

Application & Error Logs

While most companies understand that application logs should not contain cardholder data, there are some circumstances where this happens unexpectedly. This is frequently seen during release cycles or troubleshooting system issues. One of the most common culprits is changing log levels. Some log levels such as ‘Debug’ contain more information than others. In some cases, this may unexpectedly cause the logging of cardholder data. Companies should review their log levels and establish policies and procedures to safeguard sensitive data.

Log Archives

As companies collect and store log data from various sources, they may be creating a permanent unprotected record of cardholder data. For example, if an application server from the above example is logging cardholder data, that information may be replicated to a log archive. Companies should use utilities that scan log files and other archives for the possible presence of cardholder data.


This is our favorite. Some companies store cardholder data for later use in mediums such as spreadsheets and then rely on passwords as the security control mechanism. This is not sufficient to protect cardholder data and does not meet PCI requirements. If you are using spreadsheets you are creating a self-contained database that is easily stolen or misused. Companies using this method should immediately review their business justifications and need to find an approved payment facilitator that can handle their cardholder data storage needs.

Phone Agents

Many companies have departments such as customer service and sales that require the agent to handle cardholder data. In some cases, the sensitive data is written down for transfer to another department or for reference and storage. These methods of credit card storage are easily targeted for theft or misuse. Companies should adjust their policies and procedures and possibly their technology to remove any physical/hardcopy storage of cardholder data.

Here’s How We Can Help

Mitigation of these issues is vital to keeping cardholder data secure. Depending on your systems and business requirements one of the best ways to close the gap on these vulnerabilities is to offload the cardholder handling responsibility to a certified payment facilitator like Zift. Below are some of the services offered by Zift that help companies secure their cardholder data and achieve and maintain PCI compliance.

Hosted Payment Pages

HPPs allow merchants to push a customer to customizable payment pages hosted on Zift’s systems. Once the transaction has been completed on the Zift Payment Platform the customer is returned to the merchant’s site. The merchant can receive callback notifications of the transaction, or query Zift for any information about the transaction. HPP’s can also be used by sales and service departments to conduct transactions for customers over the phone. Using this method reduces PCI scope and increase data security since the merchant systems are no longer hosting the transaction process.


This is like the HPP solution except the merchant can leave the payment page on their system. Using Zift’s Proxynization Javascripts, the merchant can offload cardholder data directly to Zift prior to form submission to their system. Like the HPP solution this method also eliminates the possibility of any sensitive cardholder data being logged to files on the merchant’s systems. Other advantages to this solution include reduced PCI scope and increased control over the user experience.


This method allows merchants and service providers to directly handle cardholder data but offload the long-term storage to a certified service provider. Using Zift’s Tokenization services, a merchant or service provider can offload protected cardholder data to Zift and receive back a token. The token can then be used for later transactions instead of using the cardholder data directly.

The Zift Ecosystem

Zift is a Level 1 PCI compliant Payment Service Platform offering these and many other services to software platforms and merchants. If you have a new project or an established system come visit Zift and learn more about our Payments as a Service and how we can simplify your payment integration.

Seraphinite AcceleratorOptimized by Seraphinite Accelerator
Turns on site high speed to be attractive for people and search engines.