PCI DSS v4.0.1 applies to any app that stores, processes, or transmits cardholder data — including checkout flows built by Lovable, Bolt, Replit, v0, or any other AI app builder. As of March 31, 2025, all 51 previously future-dated requirements are fully enforceable. AI-generated checkout code has a repeated pattern of exposed secrets, missing database access controls, and homegrown payment forms that quietly disqualify a startup from the simple SAQ A questionnaire.
Get a Free Compliance Scan See Audit PricingPCI DSS applies to any entity that stores, processes, or transmits cardholder data — primarily the primary account number (PAN) — or that could impact the security of the cardholder data environment, including through third parties like Stripe or PayPal. It doesn't matter whether the checkout was hand-coded or generated by an AI app builder in an afternoon; the obligation is the same. Merchant level is set per card brand based on trailing-12-month transaction volume, and most early-stage AI-built apps land in Level 4.
| Merchant level | Annual volume (per brand) | Typical requirement |
|---|---|---|
| Level 1 | 6,000,000+ transactions/yr | Annual QSA-led Report on Compliance |
| Level 2 | 1,000,000–6,000,000/yr | Annual SAQ or RoC (varies by brand) |
| Level 3 | 20,000–1,000,000/yr (e-commerce) | Annual SAQ |
| Level 4 | Under 20,000/yr | Annual SAQ — where most AI-app startups sit |
Penalties are imposed by acquiring banks and card brands, not PCI SSC directly, and industry-reported ranges run from –nth in months 1–3 of non-compliance, up to –nth by month 7+. Beyond fines, the average cost of a data breach globally was .44M in 2025 (IBM), and historical card-data breaches at Target (.5M settlement, 41M+ accounts) and TJX (.9M, 94M+ accounts) show the scale of downstream liability when cardholder data leaks.
Sources: PCI Security Standards Council; Thoropass; Sprinto; IBM Cost of a Data Breach 2025.
The requirements below became fully mandatory on March 31, 2025 — and they are the ones AI checkout scaffolds skip most often.
| Requirement | What it means for your checkout |
|---|---|
| 6.4.3 | Inventory every script on the payment page, document why each is authorized, and verify integrity (e.g. Subresource Integrity) — mandatory since 2025-03-31. |
| 11.6.1 | A mechanism that detects and alerts on unauthorized changes to HTTP headers and payment-page content as delivered to the browser — the primary defense against Magecart-style e-skimming. |
| Requirement 8 | MFA is now required for ALL access into the cardholder data environment, not just admin/remote access. |
| Requirement 7 | Least-privilege access to any system component touching cardholder data. |
| Requirement 10 | Tamper-protected audit logging of all access to cardholder data, centrally reviewed, retained 12 months (3 immediately available). |
| 11.2.2 / 11.3.1 | Quarterly ASV + internal vulnerability scans, plus annual internal & external penetration testing (and after any significant change). |
| Requirements 3 & 4 | No storage of PAN without strong cryptography/tokenization; strong encryption for cardholder data in transit. |
Which SAQ you file depends entirely on how your checkout is architected: SAQ A (~22 controls) is only available for a fully outsourced payment page — a redirect or processor-hosted iframe with zero merchant-origin elements. SAQ A-EP (~139–191 controls) applies the moment your own site hosts or serves any script that affects the payment page — custom JS wrapping Stripe Elements, for example — even if card data itself never touches your server. SAQ D (~300+ controls) applies if your own systems store, process, or transmit PAN, or you use a non-compliant provider. PCI SSC is explicit: "if any element of a payment page originates from the merchant's website, the implementation is not eligible for SAQ A."
Sources: PCI Security Standards Council v4.0.1 documentation; PCI SSC information supplement, Payment Page Security and Preventing E-Skimming; Schellman; Foregenix.
Prompting an AI builder to "add a payment form" tends to produce the same handful of PCI failures, over and over:
Sources: Escape.tech methodology report (2025-10-29); NVD/SentinelOne CVE-2025-48757; The Register / Axios (Lovable, 2026-04-20); Bastion.tech; VentureBeat (RedAccess); CodeRabbit (Dec 2025).
Your processor's own PCI status never automatically covers how your app is wired — scope depends entirely on what your code does with card data.
| Platform | PCI posture |
|---|---|
| Stripe | PCI Service Provider Level 1. Dashboard analyzes your integration and recommends an SAQ, but you still submit your own SAQ/AOC to your acquirer. |
| Square | Card systems meet Level 1 PCI, plus SOC 1/2 and ISO 27001. Merchants using Square for all card handling generally don't need to separately validate — unless custom code touches raw card data. |
| PayPal / Braintree | Level 1 Service Provider (Visa CISP, Mastercard SDP, SOC 1). Merchants still complete their own annual SAQ based on integration method. |
| Vercel | Holds an SAQ-D AOC (as service provider) and an SAQ-A AOC under v4.0. Shared responsibility: keep a processor iframe to stay at SAQ A — POSTing card data through a Vercel API route pulls it into scope. |
| Netlify / Replit / Supabase | No dedicated PCI AOC found for any of the three (unverified). Supabase itself doesn't store card data and holds SOC 2 — not PCI — and any of your own tables storing PAN are your liability, not theirs. |
Rule of thumb: a static frontend that redirects to Stripe Checkout keeps your host largely out of scope (SAQ A). Any serverless function that receives, logs, or proxies raw card data pulls your host into the cardholder data environment.
Sources: docs.stripe.com/security; squareup.com; vistainfosec.com; vercel.com/docs/security/pci-dss (updated 2026-03-17); supabase.com/security.
Stripe is certified as a PCI Service Provider Level 1. That covers Stripe's own infrastructure, not how your app integrates it. If your site hosts or serves any script touching the payment page, you're likely SAQ A-EP, not SAQ A, and you must still complete and submit your own SAQ.
SAQ A (~22 controls) requires a fully outsourced payment page with zero merchant-origin elements — a true redirect or processor-hosted iframe. SAQ A-EP (~139–191 controls) applies the moment your own website hosts or serves any element or script affecting that payment page, even if card data itself goes straight to the processor.
No. Vercel holds its own SAQ-D and SAQ-A AOCs as a service provider, but a Vercel API route that receives raw card data still pulls you into scope. Netlify, Replit, and Supabase have no dedicated PCI AOC on record; Supabase holds SOC 2, which is not the same as PCI DSS.
No. CVE-2025-48757 let anonymous users read, modify, or delete data across 170+ Lovable apps because Supabase Row Level Security was left disabled — a direct PCI Requirement 7/8 failure. AI builders generate working checkout UI, not the access controls, logging, and script integrity PCI DSS requires.
Acquiring banks and card brands can levy escalating monthly fines — industry-reported ranges run –nth initially, rising to –nth for sustained non-compliance — on top of breach costs that averaged .44M globally in 2025.
Enable and correctly configure Row Level Security on every table, validate object ownership server-side to close BOLA gaps, rotate any service keys found in client bundles or git history, and add Requirement 10 audit logging on top — then re-scan before your next SAQ submission.
We audit AI-built checkout flows against PCI DSS v4.0.1 — script inventory, RLS, secrets, logging — and hand you a fix-it list before your acquirer finds the gap.
Get a Free Compliance ScanRelated searches: is Stripe PCI compliant · PCI compliance checklist for startups · SAQ A vs SAQ A-EP which one do I need · PCI compliance for small business website · is my Lovable or Bolt app secure · does Vercel or Netlify support PCI compliance · PCI DSS requirements for e-commerce checkout page · Supabase database exposed fix RLS
