# PCI Compliance Checklist for SaaS and Digital Products > A practical PCI compliance checklist for SaaS companies selling digital products. Understand SAQ types, scope reduction, and how a merchant of record simplifies compliance. - **Author**: Ayush Agarwal - **Published**: 2026-04-15 - **Category**: Compliance, Security - **URL**: https://dodopayments.com/blogs/pci-compliance-checklist-saas --- If you accept credit card payments, PCI DSS compliance is not optional. The Payment Card Industry Data Security Standard applies to every business that stores, processes, or transmits cardholder data - including SaaS companies and digital product sellers. The good news: most SaaS businesses do not need to become security experts. The level of compliance you need depends on how you handle card data, and the right payment architecture can reduce your compliance scope to a simple annual questionnaire. This checklist covers what SaaS companies actually need to do for PCI compliance, how to minimize your scope, and where a merchant of record eliminates the burden entirely. ## PCI DSS Compliance Levels PCI compliance requirements scale with your transaction volume: | Level | Annual Transactions | Requirements | | ------- | --------------------------- | ---------------------------------- | | Level 4 | Under 20,000 e-commerce | SAQ + quarterly vulnerability scan | | Level 3 | 20,000-1,000,000 e-commerce | SAQ + quarterly vulnerability scan | | Level 2 | 1,000,000-6,000,000 | SAQ + quarterly vulnerability scan | | Level 1 | Over 6,000,000 | Annual on-site audit by QSA | Most SaaS companies fall into Level 3 or 4, which means self-assessment questionnaires (SAQs) rather than expensive on-site audits. ## SAQ Types: Which One Do You Need? The SAQ type depends on how your checkout handles card data: ```mermaid flowchart TD A[How do you accept cards?] -->|"Redirect to payment provider"| B[SAQ A - 22 questions] A -->|"Embed provider's iframe"| C[SAQ A-EP - 139 questions] A -->|"Handle card data on your servers"| D[SAQ D - 329 questions] A -->|"Use a Merchant of Record"| E[No SAQ needed - MoR handles it] ``` - **SAQ A** (22 questions): You redirect customers to a hosted payment page. Your servers never see card data. Simplest compliance. - **SAQ A-EP** (139 questions): You embed a payment provider's iframe or JavaScript on your page. Card data passes through your domain but not your servers. - **SAQ D** (329 questions): You handle card data directly on your servers. Most complex compliance. Avoid this if possible. > The fastest way to reduce PCI scope is to never let card data touch your infrastructure. Use hosted checkouts, iframes, or a merchant of record. The moment raw card numbers hit your server, you inherit the full weight of PCI DSS compliance. > > - Ayush Agarwal, Co-founder & CPTO at Dodo Payments ## PCI Compliance Checklist ### Network Security - [ ] Install and maintain a firewall configuration to protect cardholder data - [ ] Do not use vendor-supplied defaults for system passwords and security parameters - [ ] Segment your network to isolate payment processing systems - [ ] Restrict inbound and outbound traffic to only what is necessary ### Data Protection - [ ] Never store CVV/CVC codes after authorization - [ ] Never store full magnetic stripe data - [ ] Encrypt cardholder data at rest using strong cryptography (AES-256) - [ ] Encrypt cardholder data in transit using TLS 1.2 or higher - [ ] Maintain a data inventory documenting where cardholder data flows - [ ] Implement data retention policies - do not store data longer than needed ### Access Control - [ ] Restrict access to cardholder data on a need-to-know basis - [ ] Assign unique IDs to each person with computer access - [ ] Implement multi-factor authentication for administrative access - [ ] Restrict physical access to systems containing cardholder data - [ ] Log and monitor all access to network resources and cardholder data ### Vulnerability Management - [ ] Use and regularly update antivirus software - [ ] Develop and maintain secure systems and applications - [ ] Run quarterly vulnerability scans by an Approved Scanning Vendor (ASV) - [ ] Conduct annual penetration testing - [ ] Keep all systems and software patched and updated ### Monitoring and Testing - [ ] Track and monitor all access to network resources and cardholder data - [ ] Implement audit trails for all system components - [ ] Review logs daily for security events - [ ] Test security systems and processes regularly - [ ] Maintain an incident response plan ### Policy and Documentation - [ ] Maintain a security policy that addresses information security for all personnel - [ ] Conduct annual security awareness training for staff - [ ] Document all security procedures and keep them updated - [ ] Perform annual risk assessments ## How to Minimize Your PCI Scope ### Use Hosted Checkout Pages When customers enter card details on a page hosted entirely by your payment provider, your servers never see card data. This qualifies you for SAQ A - the simplest compliance level. [Dodo Payments](https://dodopayments.com) offers hosted checkout via [overlay checkout](https://docs.dodopayments.com/developer-resources/overlay-checkout) and [inline checkout](https://docs.dodopayments.com/developer-resources/inline-checkout) widgets. Card data goes directly to Dodo's PCI-compliant servers without touching your infrastructure. ### Use Tokenization If you need to store payment information for recurring billing, use tokens instead of raw card numbers. Tokens are meaningless strings that reference the actual card data stored securely by your payment provider. All major processors including [Dodo Payments](https://dodopayments.com) handle tokenization automatically for [subscription billing](https://docs.dodopayments.com/features/subscription). ### Use a Merchant of Record A [merchant of record](https://dodopayments.com/blogs/what-is-a-merchant-of-record) is the legal entity processing the payment. When you use a MoR like Dodo Payments, the MoR handles all card data and owns the PCI compliance obligation. Your SaaS application never processes, stores, or transmits cardholder data. This is the maximum scope reduction possible - you effectively outsource PCI compliance entirely. ## PCI Compliance Costs | Approach | Annual Cost | Effort | | ------------------------ | -------------------------------- | ------------------------------------- | | SAQ A (hosted checkout) | $500-$2,000 | Low - annual questionnaire + ASV scan | | SAQ A-EP (iframe/JS) | $2,000-$10,000 | Medium - larger questionnaire + scans | | SAQ D (handle card data) | $20,000-$100,000+ | High - full assessment, pen testing | | Merchant of Record | $0 (included in processing fees) | None - MoR handles everything | For most SaaS companies, the cost difference between SAQ A and SAQ D is enormous. Architectural decisions you make at the start determine which category you fall into. ## Common PCI Compliance Mistakes ### Logging Card Data Even if you are just logging API requests for debugging, if those logs contain full card numbers, you are storing cardholder data and in scope for SAQ D. **Fix**: Configure your logging to mask or exclude card fields. Use tokens in your logs instead of raw card data. ### Storing Card Data in Your Database Some developers store card numbers directly in their database "for convenience." This immediately puts you in SAQ D scope. **Fix**: Use your payment provider's vault and tokenization. Reference tokens in your database, not card numbers. ### Not Segmenting Your Network If your payment processing system shares a network with your application servers, your entire infrastructure is in PCI scope. **Fix**: Isolate payment processing in a separate network segment with firewall rules restricting access. ### Ignoring Third-Party Risk If a third-party integration handles card data on your behalf, their PCI compliance status affects yours. **Fix**: Verify that all third-party payment integrations are PCI DSS compliant. Request their Attestation of Compliance (AOC). ## PCI DSS 4.0 Changes PCI DSS 4.0 introduced significant updates that affect SaaS companies: - **Customized approach**: More flexibility in how you meet requirements (alternative controls allowed) - **Multi-factor authentication**: Required for all access to cardholder data environments, not just remote access - **Automated security testing**: Increased emphasis on automated tools for vulnerability detection - **Third-party scripts**: Stronger requirements for managing JavaScript loaded on payment pages - **Targeted risk analysis**: Required for several controls where frequency was previously prescriptive These changes reinforce the value of reducing your PCI scope. The less card data you handle, the fewer new requirements apply to you. For related security topics, see our guides on [3D Secure authentication](https://dodopayments.com/blogs/3d-secure-3ds-payment-authentication), [fraud prevention](https://dodopayments.com/blogs/friendly-fraud-prevention), [chargeback prevention](https://dodopayments.com/blogs/chargeback-prevention-saas), and [merchant of record legal compliance](https://dodopayments.com/blogs/merchant-of-record-legal-compliance). ## FAQ ### Do SaaS companies need PCI compliance? Yes, if you accept credit card payments in any form. The scope of compliance depends on how you handle card data. If you use a hosted checkout or merchant of record and never touch card data, your compliance is minimal (SAQ A or no SAQ at all). If you handle card data directly, you need full PCI DSS compliance. ### How long does PCI compliance take? For SAQ A (hosted checkout), initial compliance takes 1-2 weeks including the questionnaire and first vulnerability scan. For SAQ D (handling card data), expect 3-6 months for initial compliance including infrastructure changes, documentation, and penetration testing. Using a merchant of record eliminates the timeline entirely. ### What happens if I am not PCI compliant? Non-compliance can result in fines from card networks ($5,000-$100,000 per month), increased processing fees, and ultimately losing the ability to accept credit cards. If a data breach occurs while non-compliant, you may face additional penalties, lawsuits, and brand damage. ### Can I use a merchant of record to avoid PCI compliance entirely? Effectively, yes. When a merchant of record like Dodo Payments processes payments, they handle all card data and own the PCI compliance obligation. Your application never sees cardholder data, so PCI DSS requirements do not apply to your systems. You should still follow general security best practices, but the formal PCI compliance burden shifts to the MoR. ### How often do I need to renew PCI compliance? PCI compliance requires annual renewal: completing the appropriate SAQ and passing a quarterly network vulnerability scan by an Approved Scanning Vendor. Some requirements (log reviews, access reviews) have daily or monthly frequencies. The annual SAQ submission is the formal compliance milestone. ## Final Thoughts PCI compliance does not need to be expensive or complex for SaaS companies. The key decision is architectural: keep card data off your servers and you qualify for the simplest compliance level. Use a merchant of record and you eliminate the compliance burden entirely. For payment processing that handles PCI compliance, tax, and chargebacks as part of the service, visit [Dodo Payments](https://dodopayments.com) and check the [pricing](https://dodopayments.com/pricing). --- - [More Compliance articles](https://dodopayments.com/blogs/category/compliance) - [All articles](https://dodopayments.com/blogs)