How to store credit cards: Using PCI DSS Service Providers

Whether you’re looking to simply accept credit cards in-app or do something more complex, like split payments or multi-processor routing, understanding the level of effort to store your cardholder data (CHD) is the first step to picking which path—build or buy—is right for you.

In this blog series, we’ll provide a high-level overview of both.

What is a PCI DSS Service Provider?

Service Providers emerged early in the 2000s as a way to lessen the cost and impact that PCI DSS had on businesses, especially those hoping to conduct transactions online. Satisfying these compliance requirements without a Service Provider meant implementing and maintaining your own Cardholder Data Environment (CDE), as well as assessing its compliance annually. Merchants needed a way to satisfy these requirements and abstract themselves, so they could focus on their core competencies and what drove revenue for the company. 

PCI defined Service Providers as an entity “directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity.” That definition, however, casts a huge net. (There are thousands of Service Providers, each offering its own depth and breadth of solutions covering the 300+ PCI DSS requirements.)

When most people think of Service Providers today, they think of Payment Service Providers, like Stripe or Adyen, or an emerging new class called tokenization Service Providers, like Basis Theory. These companies sell the necessary compliant infrastructure, tokenization platforms, and developer or no-code tools companies require to conduct business, stay compliant, and reduce the burdens of PCI on doing both. As a result, millions of companies online are able to process payments, issue cards, and much more without exhaustive million-dollar PCI environments or programs.

Let’s take a closer look at when and where Service Providers help. 

How do Service Providers help?

In our previous blog, we broke down the activities required to stand up a compliant CDE for storing cardholder data. These were: implementation, maintenance, and attestation. Let’s look at how Service Providers help with each of these stages.

What’s the implementation effort with Service Providers?

Baked into their core offering is a compliant infrastructure, developer tools, and services that typically include, but are not limited to:

1. Hosted iframes for collecting or revealing card data within your website or application. The Service Provider generates and hosts these forms, keeping data collected and secured off your system and reducing scope. 
2. A cloud-hosted data warehouse (or vault) for storing and encrypting cardholder data at rest.
3. Tokenization service for generating tokens and utilizing cardholder data without exposing your systems (more on tokenization in the following section)
4. Data security measures, scans, and tests to prevent, identify, monitor, and remediate threats and vulnerabilities

As you can imagine, Service Providers offer the fastest path to setting up a PCI compliant environment. The actual effort can take as little as an hour but varies depending on the number of integration points, desired level of customization, and how sophisticated your implementation needs to be.

How do Service Providers help maintain a compliant environment?

Maintaining a compliant CDE is messy. Not only does it require purchasing monitoring software, auditing controls, and ongoing support, it is subject to day-to-day needs of the organization and your offering. New partnerships, products, or services often require cardholder data, which, if it is not centralized or has programmatic rules to limit access or enforce policies, can drastically increase your compliance scope and risk. 

To compound issues, zero-day threats constantly emerge and new compliance requirements are always around the bend. For example, the fourth version of PCI DSS (PCI v4.0) will come into force in early 2024. It contains over 60 new requirements to shore up existing data security gaps in the previous version. A vast majority of these new requirements will be satisfied by the Service Provider without the customer needing to lift a finger. Addressing these challenges can be difficult for an organization to prioritize against revenue-generating items on a roadmap.

Luckily, Service Providers get audited for a living and are incentivized to build products and services that: 

• Maintain a reduced compliance footprint through the use of its external, centralized, and tokenized data‍
• Improve adherence with developer-friendly documentation that engineers want to use‍
• Enforce compliance through the use of modern tools, developer patterns, and access controls‍
• Abstract and automate security best practices to assuage popular security challenges (e.g. key management and rotation services)‍
• Respond to emerging threats with timely patches, software updates, and key rotation

Key concept: Understanding tokenization

Central to these Service Providers is a method of abstraction called tokenization. Instead of capturing and storing cardholder data yourself, tokenization replaces the raw card value with a token, or irreversible value, that only your systems can use. The original value is then stored and encrypted in a secure and compliant vault. When you need to reuse the card, your system simply provides the token to the Service Provider, where it can be detokenized, and sent to a gateway, processor, or third party of your choosing.

By storing the token as opposed to the raw card value in your systems, tokenization helps organizations drastically reduce their system’s compliance scope without diminishing its value to you or the end user. When using a Service Provider, merchants can descope their PCI compliance requirements by upwards of 93%.

What’s the assessment effort with Service Providers?

Each year, PCI DSS merchants are required to validate, or “attest”, their controls. This is done via a Self-Assessment Questionnaire or, for large organizations processing over 6 million transactions, a Report on Compliance conducted by a Qualified Security Assessor. 

As we discussed prior, customers inherit their Service Provider’s compliant infrastructure. In doing so, they also inherit their Service Provider’s security assessment. Depending on your integration, this leaves a small percentage of controls, as little as around 7%, that PCI requires you to validate. 

Without a Service Provider, most would be required to answer 339 questions in the Self-Assessment Questionnaire D, or SAQ D. Regardless of your path, make sure you're always using the right PCI DSS SAQ for you.

Types of third-party Service Providers

Today, there are three types of Service Providers: 

• Payments Service Providers* (PSP)  bundle a core offering with payment processing services, allowing merchants to quickly and easily accept payments.
• Card issuing platforms* use their core offering and card issuers (i.e., banks) to generate cards for their customers' end users. 
• Tokenization platforms provide a core infrastructure without card processing or issuing services. 

Pros and cons of a Card or Payment Service Provider

Card and Payment Service Provider offerings range dramatically. The following table identifies a handful of well-established benefits and drawbacks associated with the model. Take these with a grain of salt and use them as a discussion guide as you evaluate your Card and Payment Service Provider.

Pros

• Reduced compliance scope: Inherit the PCI compliance posture of your Payment Service Provider
• Reduced system complexity: Mature PSPs offer some of the simplest implementations and marginal system footprints, reducing the time-to-market and maintenance
• Hands-off compliance and security updates: Updates made by PSP to its infrastructure address gaps caused by new compliance requirements and security threats.
• Time-to-implementation: PSPs provide several prebuilt tools, integrations, and interfaces that streamline the time to go live from 6-9 months to hours or days. 
• Customizable iframes: Stylize UI components, so forms look and feel like your site.
• Time-to-remediation: Threats come fast and furious. Using a Service Provider ensures timely patching of systems and other vulnerabilities that otherwise may take weeks or months for an organization to prioritize.
• Processing and/or card issuing included: Services come with the existing banking relationships required to accept and issue cards

Cons

• Limited usability: Unable to access and use cardholder data outside the bounds of provided services.
• Lock-in: Merchants can only use their Payment Service Provider's tokens with that Payment Service Provider, meaning they’re locked into their PSP’s authorization rate, pricing, and capabilities. Moving providers may require customers to re-provide their card details to continue processing.
• Limited third-party sharing: A token is unique to the merchant and their Card or Payment Service Provider. Without the environment and ability to detokenize and forward the raw cardholder data, it’s impossible to use a token to share card details with a trusted third party.
• Transaction costs: What PSPs provide in terms of convenience and simplicity, they make up for it with fixed transaction fees. While this has been a non-issue for many small businesses that just want to accept payments; it can be quite costly to scale as you get bigger.

Pros and cons of a Tokenization Service Provider

Tokenization Service Providers, or tokenization platforms, have been described as “Stripe without the payment processing.” These entities provide the same level of abstraction as Card and Payment Service Providers but with the added benefit (or drawback) of not being tied to a PSP or Card Issuing Platform. 

The idea is that by decoupling the token from the payment processor and providing additional capabilities—like a serverless environment to run custom code against your data, the ability to search data without decrypting it, and routing services to deliver payloads to any third-party endpoint—you have the desired control, flexibility, and independence of an in-house system without the costs to implement, maintain and assess one. 

That kind of independence has made tokenization one of the fastest-growing methods among fintech for collecting, securing, and using their cardholder data, but it’s not for everyone.  

Pros

• Includes the same Pros from Service Providers (Reduced system complexity, Hands-off compliance and security updates, Time-to-implementation, Customizable iframes, Time-to-remediation)
• Usability of data: Tokenization platform allows customers to process, share, search, dedupe, and permission their data, broadening its usability to an organization.
• Avoiding lock-in with payment providers: Decouple cardholder data from your payment gateway or processor to enable switching between vendors. 
• Use multiple processors and third parties: Provides the secure environment and capabilities to route detokenized cardholder data without exposing your system to the plaintext value and ensuing scope.
• Systems impact: Can tokenize and detokenize data within existing workflows, allowing existing operations to persist without downstream impacts. 

Cons

• Cost: While marginal, adding another set of operations inherently adds cost to your bottom line. These costs may be offset by savings from using multiple processors to get lower rates or improved authorization rates, or by additional functionality from using cardholder data with third-parties.
• Latency: Adding another operation may marginally increase latency but this is only in the card capture and is generally not noticeable by users

Who uses a Tokenization Service Provider?

Simple use cases rarely need a tokenization provider; however, they can be exceptionally beneficial in situations where you need or want to:

• Route payments to multiple processors to improve authorization rates, better negotiate costs, or conduct least-cost routing. 
• Receive plaintext card numbers from a third party, like a card issuer
• Provide a third-party partner access to cardholder data to enables other services around cards such as updating card-on-file info
• Run card analytics, search, or deduplication against your cardholder data
• Create a flexible environment as you scale up
• Have a low-cost, low-effort way to maintain PCI Level 1 compliance

What to read next?

Continue reading the series to learn more. 

• A helpful guide on Cardholder Data Environments (CDE) for 2023
• How to store credit cards: Using PCI DSS Service Providers
• How to store credit cards: Building in-house
• How to store credit cards: Buy vs. build

Interested in learning more about storing credit card information? We’d love to hear from you! Take a look at our developer docs or talk to one of our payments experts. Good luck!