Payment Data Security and Compliance

Payment data includes multiple sensitivity levels. High sensitivity (PCI scope): card numbers (PAN), CVV, magnetic stripe data—Stripe handles these, so you shouldn't store them. Medium sensitivity: customer names, email, billing addresses, last-4 digits, transaction amounts. Low sensitivity: aggregated metrics, anonymized analytics. Most analytics needs can be met with medium and low sensitivity data. Design systems to use the minimum data necessary for each use case.

Payment data attracts sophisticated attackers. Threats include: external attacks (SQL injection, API abuse, credential stuffing), insider threats (malicious employees, compromised accounts), third-party risks (vendor breaches, supply chain attacks), and accidental exposure (misconfigured storage, logging sensitive data). Attack vectors evolve constantly—security requires ongoing attention, not one-time implementation. SaaS companies are increasingly targeted as they scale and accumulate valuable customer data.

Using Stripe as your payment processor provides significant security benefits. Stripe is PCI DSS Level 1 certified (highest level). Card numbers never touch your servers when using Stripe.js or Elements. Stripe handles encryption, tokenization, and secure storage. Your PCI scope reduces to SAQ A or SAQ A-EP (minimal requirements). However, you're still responsible for securing Stripe API keys, customer metadata, and analytics data derived from payments.

Security is shared between Stripe and you. Stripe handles: card data storage, payment processing security, PCI compliance for card handling. You handle: API key security, webhook endpoint security, access controls to Stripe Dashboard, security of data you extract (customer info, transaction data), and compliance with privacy regulations (GDPR, CCPA). Don't assume "Stripe handles security"—you own significant security responsibilities.

PCI compliance requirements vary by transaction volume. Level 1: >6 million transactions/year—requires annual on-site audit. Level 2: 1-6 million transactions—annual SAQ, quarterly network scans. Level 3: 20K-1 million e-commerce—annual SAQ, quarterly scans. Level 4: <20K e-commerce—annual SAQ. Most SaaS companies start at Level 4 or 3. Using Stripe with proper integration qualifies you for SAQ A (simplest) or SAQ A-EP, which have minimal requirements.

If you use Stripe.js/Elements exclusively, SAQ A applies. Requirements: maintain secure systems, restrict physical access to systems, maintain information security policy. You never handle card data—it goes directly from customer browser to Stripe. This is the easiest compliance path. Verify: no card data in your logs, no card fields in your forms, all payment handled through Stripe-hosted components.

If you host the payment page but card data goes to Stripe (redirect after form submission), SAQ A-EP applies. Additional requirements: secure your website, implement TLS everywhere, regular vulnerability scanning. More requirements than SAQ A but still manageable. Applies if you have any involvement in serving pages where card data is entered, even if you don't receive the data.

PCI compliance is ongoing, not one-time. Annual: complete applicable SAQ, review security policies. Quarterly: network vulnerability scans (if required). Ongoing: maintain security controls, train employees, monitor for breaches. Document everything—auditors want evidence. Compliance validation depends on your merchant bank's requirements. Stripe provides compliance documentation and guidance for their customers.

GDPR applies if you have EU customers or process EU residents' data. Requirements: lawful basis for processing (contract, consent, legitimate interest), data minimization, right to access/deletion, data breach notification (72 hours), Data Processing Agreements with vendors. Payment data processing usually falls under "contract" basis—you need it to fulfill the subscription. Ensure clear privacy policy explaining payment data use.

California privacy laws apply if you do business with California residents and meet thresholds. Requirements: disclose data collection practices, honor opt-out requests, don't discriminate against exercising rights, data deletion requests. Payment data retention must be documented. Unlike GDPR, legitimate interest isn't sufficient basis—explicit consent or contract needed. Similar laws spreading to other US states.

Both regulations grant data subjects rights. Access: provide copy of their data (including payment history) upon request. Deletion: delete their data when requested (subject to legal retention requirements). Portability: provide data in machine-readable format. Build processes to handle these requests efficiently—manual handling doesn't scale. Consider: payment history retention for tax/legal purposes may override deletion requests for certain data.

Payment data often crosses borders—US company with EU customers, data warehouses in different regions. GDPR restricts EU data transfers to countries without adequacy decisions. Solutions: Standard Contractual Clauses (SCCs), binding corporate rules, or keep EU data in EU. Stripe handles transfers for data they process. For analytics data you extract, ensure your infrastructure complies with transfer requirements.

Stripe API keys grant access to payment operations—protect them rigorously. Store in environment variables or secret managers (AWS Secrets Manager, HashiCorp Vault)—never in code. Rotate keys periodically and after any potential compromise. Use restricted keys with minimal permissions for each use case. Monitor API usage for anomalies. Implement key management procedures: who can access, rotation schedule, incident response for compromised keys.

Stripe webhooks deliver sensitive event data—verify authenticity. Always verify webhook signatures using your endpoint's signing secret. Use HTTPS exclusively—Stripe won't send webhooks to HTTP. Implement idempotency to handle duplicate deliveries safely. Log webhook events for audit trail. Rate limit webhook endpoint to prevent denial-of-service. Consider IP allowlisting as additional layer (Stripe publishes their IP ranges).

Limit who can access payment data and systems. Implement least-privilege: each role gets minimum access needed. Use role-based access control (RBAC) for Stripe Dashboard and analytics. Require MFA for all payment-related access. Review access quarterly—remove departed employees, verify appropriateness. Log access for audit purposes. Stripe Dashboard supports team permissions—use them rather than sharing credentials.

Encrypt payment data at rest and in transit. Transit: TLS 1.2+ for all API calls and webhooks (Stripe requires this). Rest: encrypt databases and storage containing customer data. Use managed encryption where possible (AWS KMS, Google Cloud KMS). Encrypt backups—they're often overlooked. Consider field-level encryption for highly sensitive fields in your database. Key management is critical—secure keys as carefully as data.

Extract only data needed for specific analytical purposes. Don't copy entire Stripe database "just in case." For most analytics: customer ID, subscription status, amounts, dates suffice. Exclude: full card numbers (shouldn't be accessible anyway), billing addresses (unless needed), sensitive metadata. Review extracted data periodically—remove what's no longer needed. Less data means smaller breach impact.

Reduce re-identification risk for analytics data. Pseudonymization: replace identifying fields with tokens that map back to identity. Anonymization: remove identifiers entirely so individuals can't be identified. Aggregation: use aggregate metrics rather than individual records where possible. Consider: cohort analysis needs customer identifiers, trend analysis doesn't. Design analytics to use the least identifiable data possible.

ETL pipelines are attack vectors—secure them. Encrypt data in transit between systems. Use service accounts with minimal permissions for pipeline processes. Audit pipeline access and changes. Implement data quality checks that detect anomalies (potential tampering). Monitor pipeline runs for failures that might indicate attacks. Separate development/testing from production pipelines—don't use real payment data for testing.

Analytics tools (Looker, Tableau, Metabase) need security configuration. Implement authentication (SSO preferred) and authorization (role-based access). Encrypt connections to data sources. Review shared dashboards—ensure they don't expose sensitive data inappropriately. Audit who accesses what data. Consider row-level security for multi-tenant analytics.

Detect incidents through active monitoring. Monitor: failed authentication attempts, unusual API usage patterns, data export volumes, access to sensitive systems. Use SIEM tools (Splunk, Datadog, Sumo Logic) to aggregate and analyze security logs. Set alerts for suspicious patterns. Stripe provides webhook events for sensitive account changes. Regular log review catches incidents that automated detection misses.

Document how to respond before incidents occur. Plan includes: incident classification (severity levels), response team roles, communication procedures, containment steps, evidence preservation, notification requirements. Test the plan with tabletop exercises. GDPR requires breach notification within 72 hours—you can't develop a plan during an incident. Review and update plan annually.

Multiple regulations require breach notification. GDPR: notify supervisory authority within 72 hours, notify affected individuals if high risk. PCI: notify payment brands and acquiring bank. CCPA: notify affected California residents. State laws: various requirements by state. Document notification procedures and templates in advance. Consider cyber insurance that includes breach response services.

After containing incidents, conduct thorough analysis. Questions: how did the breach occur, what data was affected, how was it detected, how effective was response? Document lessons learned. Implement improvements to prevent recurrence. Consider third-party forensic analysis for significant breaches. Update threat model based on actual attack patterns. Share learnings (appropriately) with security community.