Get a high-level overview of the effort and trade-offs required to build your own cardholder data...
How to store credit cards: Buy vs. Build
Learn the core concepts, efforts, and trade-offs between building vs. buying a cardholder data environment (CDE).
Whether you’re looking to simply accept or issue credit cards in-app or do something more complex, like split payments and multi-processor routing, understanding the level of effort to store your cardholder data (CHD) is a critical step to picking which path—build or buy—is right for you. In this blog series, we’ll provide a side-by-side comparison of both.
This post provides a high-level overview of the two solutions, but you can find more detail on the two solutions in the follow-up pieces:
- How to Store Credit Cards: Using PCI DSS Service Providers
- How to Store Credit Cards: Building a Solution In-house
Build or Buy a Solution: Key Concepts
In previous posts, we defined a cardholder data environment (CDE) and its purpose. We then went in-depth on the two primary options for collecting and securing these credit and debit card details: building and maintaining a PCI CDE and program vs. using third-party CDE Service Providers. In this blog, we’ll tie it all together to offer a top-line view of each, as well as some tips to guide internal discussions at your organization.
Before we jump in, it’s probably helpful to revisit some key terms used in this document.
- Payment Card Industry Data Security Standard (PCI DSS) is a set of over 300 controls that protect cardholder data and the larger payments ecosystem. You must comply with these standards if you’re processing or issuing payments. Learn more about PCI DSS and its requirements.
- Tokenization platforms provide the core infrastructure to secure, collect, and use cardholder data without card acquiring or issuing services. Organizations use this approach to receive more flexibility without increasing their PCI compliance scope (e.g., process or issue cards with multiple providers, share cardholder data with partners, and more). Learn more about tokenization.
- Scope refers to the collection of people, processes, and systems used by organizations to secure, transmit, or process cardholder data. Items “in scope” must comply with the 300+ PCI DSS requirements.
- Attestation refers to validating the controls required by PCI DSS. Generally speaking, these audits are conducted annually as a Self-Assessment Questionnaire (SAQ) for organizations processing less than 6 million transactions. Merchants processing over 6 million must use an independent Qualified Security Assessor (QSA) or Internal Security Assessor (ISA).
Build or Buy: PCI Compliance Considerations
The following comparison is meant to aid internal discussions with your team. As always, PCI is very nuanced and specific to your implementation, so be sure to reach out to us in our Slack Community or another trusted expert if you have any questions.
|
SERVICE PROVIDERS |
BUILD YOUR OWN |
FINAL THOUGHT |
||
|---|---|---|---|---|
| Card or Payment Service Provider | Tokenization Service Provider |
|||
| Compliance scope and system impact | Offloads up to 93% of compliance requirements; may use SAQ A or SAQ A-EP to audit | Same as card issuer or payment service provider | Assumes 100% burden of implementing, maintaining, and proving compliance; Must assess using an SAQ D or ROC (over 300 questions) | Service Providers offer tools, services, and infrastructure so that most organizations may use the smallest Self-Assessment Questionnaire (SAQ A, 22 questions). |
| Data portability and usability | Token works only with card issuer or payment service provider; Cannot share cardholder data with third parties | Send data to third parties; Search, transform, and control access to cardholder data; Minimize threat of vendor lock-in; Unlock or maintain existing downstream processes; Useful with other data types | Complete control over cardholder environment and data; Risk of decentralizing data | Building your own gives you complete control over your cardholder data, but Tokenization Service Providers can provide similar capabilities with less complexity, cost, and overhead. |
| Time-to-go live | Deploys compliant solutions in hours; SAQ A assessment takes hours | Same as card issuer or payment service provider | 4-9 months to implement and assess | Service Providers offer existing PCI-compliant infrastructure and out-of-the-box tools that accelerate development. |
| Cost | Costs are lumped into usage-based transaction fees; Volume-based discounts are available | Costs range from per interaction to monthly active tokens; Does not include processing fees | Costs to implement, assess, and maintain range CDE and PCI program range from $145,000-$500,000; Does not include processing fees | Card issuers and service providers are cost-effective for straightforward SMB card acceptance; use Tokenization Service Providers if you expect to switch vendors, optimize payments, or send data to third parties. |
| Compliance and security management | Maintains continuous security and compliance infrastructure on behalf of customers | Same as card issuer or payment service provider | Requires prioritization of security and compliance updates | Service Providers manage infrastructure, allowing teams to focus roadmaps on differentiating their core products or services. |
| Developer experience | Offers clean developer docs, modern SDKs, and guides; Built-in guardrails for building compliant payment workflows | Same as card issuer or payment service provider; Provide guardrails for other types of sensitive data (e.g., PII and PHI) | Must create docs, guides, and SDKs to support developer adoption and use | Service Providers provide modern developer patterns, tools, and services that streamline development, eliminate compliance bottlenecks, and promote adherence. |
Tips for choosing which PCI compliance approach is best for you?
To help put these perspectives to work, here are a few lightweight exercises we’ve seen help customers evaluate which option is right for them.
-
Map your system. How is card data collected (or will it be collected)? How is it used by other processes and users in the organization? Map a typical use case end-to-end. Socialize the diagram to add details where gaps exist and build buy-in with stakeholders.
-
Identify needs. Label internal and external pain and gains along the diagram. Separately, track new use cases and their requisite capabilities.
-
Identify your objectives. Bucket your pains, gains, and desired capabilities by their business impact, like improving auth rates, eliminating compliance bottlenecks, or driving revenues from partnerships. Split these into timeline horizons (i.e., now, next, later) to help drive priority and alignment internally.
-
Estimate ROI. Estimate or assume ROI requirements for each horizon. Use existing data and industry benchmarks. Don’t perfect this. Instead, get lose cost-benefit model and a list of assumptions that you can use to drive clarity with stakeholders and service providers. (Fastest way to get an answer is to throw out the wrong one!)
-
Get perspective. Use your map and business objectives to engage your network or investors to find individuals who have done something similar. Get their opinion.
-
Timebox proof of concept. Scope a narrow use case with limited acceptance criteria and build a low-fi working prototype to assess effort. For example, we created a PCI Blueprint that will allow you to collect, store, and transmit cardholder details in less than 5 minutes.
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
Are you 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 solution engineers. Good luck!
