Skip to content

    How to Store Credit Cards: Building in-house

    Blog image title

    Get a high-level overview of the effort and trade-offs required to build your own cardholder data environment (CDE).

    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.

    Should you store your own cardholder data?

    The Payment Card Industry Data Security Standard (PCI DSS) is one of the world's most prescriptive and thorough compliance frameworks. Nested underneath these 12 requirements are over 300 sub-requirements, each requiring safeguards, called “controls,” that must be implemented, maintained, and assessed to be considered compliant. These controls range from employee screening to network security to physical access controls and are scoped to every person, process, or system that CHD touches.

    It’s no surprise that extremes mark hand-rolling your PCI environment and the program. Compared to Service Providers, it gives you complete flexibility and control over your CHD. Unfortunately, it does so at the cost of time, effort, and risk, which compound exponentially if a larger pattern for compliance isn’t developed (more on this later). 

    But all that work and risk may be able to be offset if done right. Hosting your compliant cardholder data environment (CDE) can provide efficiencies in terms of costs, system transparency, and integrations that some service providers, especially payment and card issuing providers, cannot. You could also have improved the latency and the comfort of a “single throat to choke,” compared to Service Providers.

    The answer depends on whether or not the juice is worth the squeeze. To help, let’s take a high-level look at the effort involved.

    What does it take to store credit card data?

    Unlike those that host their cardholder data with their Service Providers’ environment, you’ll be responsible for implementing, maintaining, and assessing 100% of your organization’s infrastructure and program.

    The modern PCI Compliance stack is comprised of hardware, applications, cloud storage, and the underlying payment systems that operate it.

    Efforts to implement a cardholder data environment

    Setting up a cardholder data environment to store credit cards isn’t rocket science. Still, getting something valuable and compliant requires a significant amount of knob-turning, socializing, documentation, decisions, and configuration. This includes, but is not limited to: 

    • identifying and implementing solutions and vendors, 
    • segmenting and setting up infrastructure and firewalls, 
    • developing and administering training and policies, and more.
    These efforts, typically see median estimates somewhere between $125,000 to $300,000 and 3-7 months. 

    TIP: PCI DSS offers hundreds of assets and resources that can help streamline and simplify your implementation, like the PCI SSC’s prioritized approach to implementation (v3.2.1). 

    Efforts to assess a cardholder data environment for PCI DSS compliance

    Once you’ve built your cardholder data environment, but before you can process live transactions, your acquiring bank will need to see a copy of your Attestation of Compliance. The PCI DSS provides this upon successful receipt and completion of a PCI assessment. 

    The scope mostly determines these assessments and the number of transactions processed. Given that you’ll be storing 

    Generically speaking, if you’re:

    1. Storing cardholder data without the use of one of the Service Providers mentioned above, then you’ll either be required to complete the SAQ D, system scan and penetration test. 
    2. Processing over 6 million transactions each year, you’ll be required to engage a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA) to complete an assessment and issue a Report on Compliance. 

    Assessing PCI compliance with an Self-assessment Questionnaire D (SAQ D)

    The SAQ D is a far cry from the SAQ A and SAQ A-EP completed by those using Service Providers. For starters, companies that qualify for SAQ A need only complete 22 questions (33 questions in PCI 4.), while SAQ D companies need to answer over 339 questions. Having your SAQ on hand during your first implementation can help accelerate this part of the process.

    Learn more SAQs and which one is right for you.

    Assessing PCI compliance with a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA)

    Gathering evidence and preparing for an assessment can take months; however, the audit itself may take anywhere from 3 to 9 weeks, depending on your familiarity with the process and your assessor's familiarity with your implementation. 

    Efforts to maintain a PCI DSS-compliant cardholder data environment 

    While there are predictable “spot-in-time” requirements, like ongoing security training, penetration tests, and quarterly network scans that must be completed at certain intervals, PCI compliance requires constant vigilance, adherence, and remediation.

    The "compliancy curve" is used to demonstrate compliance anti-patterns related to PCI DSS. It market by period of compliance leading up to an assessment and a noticeable lack of adherence afterwards. This cycles continues.

    Without it, you’re missing the intent of the “data security” in PCI DSS and opening yourself to additional costs due and security threats. In its annual data breach investigation report, Verizon found that the human element was directly or indirectly responsible for 82% of all breaches in 2021. Worse, the number of records caused by internal actors outnumber external actors by 10-to-1.  

    TIP: Developer-friendly platforms and tokenization, which can abstract or enforce certain behaviors, access, and permissions, have emerged as one of the best ways to maintain security and compliance posture. By investing in and supporting developer docs, SDKs, APIs, and tokenization services, organizations reduce the cognitive load on developers, improve adherence, and ensure compliant operations (#compdevops) at the code level. This "compliant-by-default" strategy can also increase team velocity.

    There's also the cost to update systems to new compliance requirements. For example, the Payment Card Industry Security Standards Council, the governing body for PCI DSS, recently released the new PCI DSS v4.0 in early 2022. The new requirement outlines 60 additional controls required to be enforced by March 2024. The time and effort it takes to understand and satisfy these requirements vary based on your implementation and use of your cardholder environment. 

    Pros and cons of an in-house system

    Let’s review and summarize some of the trade-offs of storing your own cardholder data.

    Pros

    • Usability of data: It’s your data, your systems, and your call on what you want to do with your data.
    • Avoid lock-in: Unsure if your partner or payment processor is “the one”? 
    • Use multiple processors: By owning the cardholder data, you can route payments to processors of your choice. This can help improve authorization rates, aid in pricing negotiations, and reduce transaction fees through least-cost routing.
    • Send cardholder data to third parties: Transform and route payloads to partners for to enable their downstream processing.

    Note: Many of these benefits can also be provided by tokenization service providers, like Basis Theory.

    Cons

    • Costs: Investments in personnel, systems, tools, assessors, policies and more can cost hundreds of thousands of dollars. Annual assessments, operational expenses, training, and scans can cost five to six figures. Investing in a non-differentiating support feature may detract and distract from your core product.
    • Developer platform sold separately: Having and keeping a modern and compliant environment are two different challenges. Creating tools, introducing services, and enforcing compliant engineering patterns should be considered.
    • Time-to-market: Building a validated PCI-compliant environment and program typically takes around 3-7 months. 
    • Compliance and security updates: As threats and compliance requirements change, so must your cardholder data environment. These updates can range from small configuration changes to possible re-architecture of systems. 

    Who builds their own PCI-compliant environment and program?

    With the advent of tokenization, payment, and card-issuing providers, the economics and requirements forcing companies to store their CHD have changed dramatically. We've found that most companies pursuing their own internal environments in programs are large retailers processing more than 6 million transactions per year or other Service Providers. 

    What to read next?

    Continue reading the series to learn more. 

    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 payment experts. Good luck!

    Subscribe to the Blog

    Receive the latest updates straight to your inbox