An Introduction to PCI Compliance

[ColeCallahan]

There are plenty of reasons for enterprises that work with cardholder data to care about payment card industry (PCI) compliance. For starters, maintaining PCI compliance is an essential part of protecting credit and debit cardholders, reducing fraud, and avoiding damage to your reputation. Additionally, if your organization is found not to be PCI compliant, it will be subject to financial penalties and, ultimately, not allowed to process or handle card transactions. 

Achieving PCI compliance can be complex and time-consuming. For businesses that want to launch and scale quickly, the burden is onerous. To help you navigate the challenges of PCI compliance, here we’ll provide a crash course on the topic. We’ll also take a look at how enterprises can meet PCI Data Security Standard (DSS) requirements and go to market quickly.

What is PCI compliance? 

PCI compliance is the process of adhering to PCI DSS requirements and security assessment procedures when processing, transmitting, or storing cardholder data (CHD) or sensitive authentication data (SAD). We don’t address PCI 3DS and other PCI programs in this article.

Understanding PCI DSS

Let’s run through a quick Q&A to get up to speed on PCI DSS. 

What is PCI DSS?

PCI DSS is a payment card industry standard. Compliance is mandatory for companies that process, store, or transmit cardholder data (CHD) or sensitive authentication data (SAD) to comply with PCI DSS requirements. PCI DSS details specific technical and operational requirements applicable to any organization that works with CHD or SAD. PCI DSS version 3.2.1, was published in 2018 and version 4 was recently published in March 2022. For now, an organization can get certified for either v3.2.1 or v4, however, version 3.2.1 will be sunsetted in March 2024 (thus, there is a 2 year transition period before v4 has to be adopted). Both versions are available for download in the PCI document library.

Who created PCI DSS?

The PCI Security Standard Council (PCI SSC) is an organization created in 2006 by Visa, MasterCard, American Express, Discover Financial Services, and JCB International. The PCI SSC sets the requirements for PCI compliance. 

What’s the purpose of PCI DSS?

PCI DSS aims to improve cardholders’ data security and facilitate consistency in the processes used to secure card transactions globally.

What is CHD?

Cardholder data (CHD) includes primary account number (PAN), cardholder name, expiration date, and service code. If there is proper business justification to do so, PCI DSS allows the storage of CHD if necessary.

What is SAD?

Sensitive authentication data (SAD) includes full magnetic stripe data (or an equivalent such as EMV chip data), CVV2/CVC2/CID number, PIN, or PIN block. In most cases, PCI DSS does NOT permit storage of SAD after authorization, however, per PCI Req. 3.2:

 "...It is permissible for issuers and companies that support issuing services to store sensitive authentication data if:

• There is a business justification and
• The data is stored securely." 

Do I need to comply with PCI DSS?

If you store, process, or transmit CHD or SAD, or have an application or system connected to another application or system that stores, processes, or transmits CHD or SAD, then, you are required to comply with PCI DSS.

What is account data?

CHD and SAD are collectively referred to as account data. 

What is CDE?

A cardholder data environment (CDE) consists of all the people, processes, and technologies that store, process, or transmit account data in a network. 

What are the 12 requirements to achieve PCI compliance?

The PCI SSC outlines 12 high-level requirements that businesses must meet in order to be PCI compliant. The requirements are grouped under larger categories (or goals) and take a holistic, end-to-end view of CDEs, covering items such as firewall configuration, default passwords, encryption, and even physical access. At first glance, that can be intimidating. For many digital businesses, however, the steps are either consistent with best practices they should follow anyway. By leveraging Marqeta’s platform, an organization can offload some of its compliance burden to Marqeta. However, that does not exempt the organization from meeting remaining requirements.

For example, Requirement #8 is “Assign a unique ID to each person with computer access.” A company may build its payment card program with the Marqeta platform, but that company still needs to provide unique IDs to its users.

What are the PCI compliance types and levels?

Merchants (organizations that accept payment cards) and service providers (organizations that process payments or provide services to acquiring banks and merchants) meet different requirements to achieve PCI compliance depending on their “level” or “tier”. Typically, an organization’s level is tied to the number of transactions that it processes annually, with Level 1 being the highest volume.

Visa’s requirements are a good general reference to understand levels.

What’s the difference between PCI compliance and PCI certification?

The simple way to think about PCI compliance versus PCI certification is: PCI compliance is your company’s adherence to the 12 PCI DSS requirements. PCI certification, on the other hand, is the verification and attestation that a company is PCI compliant.

Any organization that accepts or processes payment cards must be PCI compliant and provide verification. On the surface, this may sound intimidating and complicated. However, the complexity of the PCI verification or certification process depends on each organization’s PCI type and level.

Many companies that leverage the Marqeta platform to build payment card programs are considered to be service providers. A Level 1 Service Provider is required to usea Qualified Security Assessor (QSA) to verify their PCI controls and produce an Attestation of Compliance report. Level 2 Service providers can complete a self-attestation questionnaire (SAQ). Every company, however, should determine their own type and level certification requirements by becoming familiar with the PCI DSS.

Are card issuers subject to PCI DSS compliance? 

In many cases, the answer is “yes, card issuers are subject to PCI DSS.”

There is a common misconception that card issuers are exempt from PCI DSS because they have no choice but to store SAD. However, PCI DSS allows card issuers with a legitimate business need to store SAD. Issuers are also subject to all other relevant PCI DSS requirements. 

Simplifying PCI compliance

Achieving PCI compliance can be a complex and time-consuming process for organizations standing up new card programs. Ensuring account data is securely transmitted, stored, and processed across your CDE can be a nuanced process. This is particularly true for card programs with cash withdrawals and multi-use cards that require PCI Level 1 compliance. 

One solution, the Marqeta platform, helps organizations offload a significant portion—though not the entirety—of the PCI compliance burden. In addition to maintaining strict security controls and a PCI DSS Level 1 certification, Marqeta provides companies with access to a PCI-compliant JavaScript library and multiple PCI-compliant widgets. Let’s take a closer look at those resources and their benefits.

Marqeta.js: A PCI-compliant JavaScript library

Marqeta.js is a JavaScript framework that enables you to display sensitive card data in your apps while offloading this aspect of the compliance burden to Marqeta. Marqeta.js injects configurable iframes into HTML. For mobile applications, this requires using WebView. As a result, you can display a virtual card without processing, storing, or transmitting the data on your servers and your PCI requirements would be reduced

Additionally, even though you’re offloading the data handling to Marqeta, you can control the styling of the HTML pages to match colors and fonts to your app. To get started with Marqeta.js, see Using Marqeta.js.

PCI-compliant widgets 

Some of the most common use cases that make card issuers subject to PCI DSS involve transmitting account data in card and PIN activation workflows. Marqeta offers customizable “Activate Card” and “Set PIN” widgets for these scenarios. These widgets are designed to comply with PCI DSS as it pertains to the storage, transmission, and processing of CHD, so your PCI requirements would be reduced.

To use these widgets, you simply embed the iframe within a parent page in your application and configure it by passing query parameters in the source URL. All the processing is performed on Marqeta’s servers. For mobile applications, native widgets aren’t available yet, but developers can still use embedded iframes in WebView. 

Check out Using Activate Card and Set PIN Widgets to get started using these widgets. To get a feel for how you can customize the widgets, see the Marqeta Widget Style Preview.

In addition to the “Activate Card” and “Set PIN” widgets, Marqeta has an Add Payment Card Widget in beta. This widget’s push-to-card disbursements feature allows users to push funds from a reserve balance to a payment card that was not issued by Marqeta..

Conclusion

Ensuring that your organization is PCI compliant is no small task. It requires a strong understanding of what is required of your organization to be compliant and what is required to attest that you are compliant. However, the risks of being non-compliant are too great to ignore.

Fortunately, organizations who do their homework and seek help from experts will have a smoother and faster time getting to compliance. One case study discusses how Marqeta helped Ramp to begin transacting over the Visa network within two months. By offloading some of the complexity of PCI compliance to Marqeta, businesses can go to market quickly without compromising security.

Have questions or comments about PCI Compliance? Let us know by responding to this post.