07.06.Payment Compliance Analysis

07.06. Payment Compliance Analysis

1. Executive Summary

CPT processes payments via Stripe and PayPal. To be compliant with PCI DSS, we must ensure the application never touches, stores, or processes raw credit card numbers.

2. Current Status

Stripe: Currently uses the "Stripe Checkout" (redirect flow) which is the most secure method. The user is redirected to stripe.com to enter their payment details, and CPT only receives a payment_id (cs_) or payment_intent_id (pi_).
PayPal: Uses the standard redirect flow. The user pays on paypal.com, and CPT receives an order_id.
Backend Storage: PaymentService and the OrderSession in Redis only store metadata (amount, plan, status, provider_id). NO CARD DATA is currently logged or stored.

3. Gap Analysis

PCI Scope: By using only redirect flows, CPT qualifies for the simplest PCI self-assessment (SAQ-A).
The "Data Leak" Risk: If the application adds "direct" payment methods (where users type card numbers into a form on carpulsetracker.com), the PCI compliance requirements become 100x more complex (SAQ-A-EP or SAQ-D).
Receipts: Invoices generated by PDFService do not contain any sensitive payment data, only the payment method name (e.g., "Stripe") and the provider's transaction ID.

4. Recommendations

Strict Redirect Flow Only: Maintain the current redirect-only model for Stripe and PayPal.
Do Not Store PII in Redis: While customer_email is sometimes used for receipts, it should be encrypted at rest in Redis (same as Tesla tokens).
Audit Logging: Maintain a clear audit trail of all payment.verify calls to reconcile with provider dashboards.