Minimize PCI DSS scope using tokenization and determine the correct SAQ level

Verified steps

1. Use a hosted fields or embedded JS widget (e.g., Stripe Elements, Braintree Hosted Fields, Checkout.com Frames) so raw PAN data is entered directly into an iframe served from the PSP's domain — your page never touches card numbers, reducing scope to SAQ-A.
2. Ensure your checkout page is served over HTTPS with a valid certificate; even with hosted fields, an HTTP page that embeds the PSP iframe is ineligible for SAQ-A and may be disqualified by your acquirer.
3. Never log, store, or transmit raw card numbers, CVVs, or full magnetic stripe data through your own infrastructure — if your server receives a tokenized card reference (e.g., a Stripe token or vault ID), that is not in scope; only the PSP holds the PAN.
4. Assess your SAQ type: SAQ-A applies when all card capture is outsourced to a PCI-compliant third party and you never receive PANs; SAQ-A-EP applies if you control the redirect/JavaScript that loads the hosted fields; SAQ-D applies if your server ever receives or stores PANs.
5. For mobile apps, use the PSP's official mobile SDK which tokenizes on-device before data leaves the user's phone — do not build a custom card entry form that sends raw PANs to your server.
6. Complete an annual Self-Assessment Questionnaire and quarterly ASV scans if required for your SAQ level; store the signed SAQ and share it with your acquiring bank on request.