In this guide · 8 sections
- 01What PCI DSS is and who has to comply
- 02SAQ A vs SAQ A-EP vs SAQ D explained
- 03The 2025 SAQ A change: scripts on your payment page
- 04What Stripe, HitPay or Shopify do for you
- 05The website security items you still own
- 06How to complete your PCI self-assessment
- 07Do it yourself or get help?
- 08Frequently asked questions
Short answer
Most small merchants using a hosted checkout or Stripe Elements qualify for SAQ A, the shortest self-assessment. A card form you host yourself points to SAQ A-EP; card numbers passing through your servers means SAQ D. You still attest yearly and protect your site from malicious scripts.
What PCI DSS is and who has to comply
PCI DSS (Payment Card Industry Data Security Standard) is set by the PCI Security Standards Council, founded by the major card brands. It is not a Singapore law, but your payment provider's terms require it. Stripe's integration security guide puts it plainly: PCI compliance is a shared responsibility. Stripe is assessed every year as a PCI Level 1 Service Provider, and as a business accepting payments you must also accept them in a compliant way and attest to that every year.
Small merchants do not usually need an auditor. They validate by completing a Self-Assessment Questionnaire (SAQ). Which SAQ depends almost entirely on how card details get from your customer to the payment provider.
SAQ A vs SAQ A-EP vs SAQ D explained
Stripe's PCI compliance guide maps its integrations to SAQ types for merchants at levels 2 to 4. Other providers follow the same logic.
| How you take card payments | Typical SAQ | What it means |
|---|---|---|
| Hosted checkout or payment links (Stripe Checkout, HitPay checkout, Shopify checkout) | SAQ A | Card form is entirely the provider's; shortest questionnaire |
| Provider's embedded fields in an iframe (Stripe Elements) | SAQ A | Card fields come from Stripe's domain; extra script-attack criterion applies |
| Your own card form posting to the provider (Stripe.js v2 pattern) | SAQ A-EP | Your page controls the form, so your website security is in scope |
| Card numbers sent through your server to an API | SAQ D | Full assessment; Stripe says more than 300 controls |
| Staff keying cards into a dashboard (phone orders) | SAQ C-VT | For occasional manual payments only |
| Card terminal in store (Stripe Terminal) | SAQ C | Separate in-person channel |
Stripe also notes that it can determine the right SAQ for you: its dashboard includes a PCI wizard that works out which documentation applies to your integration.
The 2025 SAQ A change: scripts on your payment page
In January 2025 the PCI SSC revised SAQ A for PCI DSS v4.0.1. It removed requirements 6.4.3 and 11.6.1 (inventory and monitoring of scripts on payment pages) from the questionnaire and replaced them with an eligibility criterion: the merchant must confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce systems.
The Council's FAQ announcement explains two ways to meet it: use techniques like those in 6.4.3 and 11.6.1 (yourself or via a third party), or get confirmation from your PCI-compliant payment provider that its embedded form, used as instructed, protects your page from script attacks. It also clarifies that this criterion applies to pages that embed the provider's form, such as an iframe, not to sites that redirect customers to the provider's hosted page.
What Stripe, HitPay or Shopify do for you
When you use a hosted checkout or embedded fields, the provider stores, processes and transmits the card numbers. That removes the hardest PCI requirements from your scope. Stripe says you can safely store the non-sensitive details it returns, such as card brand, last four digits and expiry date, because they are not subject to PCI.
What the provider cannot do is secure your website, your admin logins or the people who handle customer queries. Picking an integration that keeps you on SAQ A is the single biggest decision; our payment gateway comparison for Singapore and HitPay vs Stripe guide cover the options and fees.
The website security items you still own
Even on SAQ A, your website is the front door to the checkout. These items are worth doing whatever the questionnaire says.
PCI basics for small merchants
If your site has ever been compromised, assume payment pages may have been tampered with. Our guide on what to do when a website is hacked covers clean-up.
How to complete your PCI self-assessment
Find your merchant level
Stripe's guide sets levels by annual transactions. Most small merchants are Level 4 (fewer than 20,000 online transactions a year) or Level 3.
List every way you take card payments
Website checkout, payment links, invoices, in-store terminal and phone orders each count as a channel.
Match each channel to an SAQ
Use the table above or your provider's PCI wizard. Different channels can mean more than one SAQ.
Check the eligibility criteria
Read the eligibility section of the SAQ from the PCI SSC document library and confirm every statement is true.
Answer the questions and sign the attestation
Fix any 'no' answers first. Keep evidence such as your update log and provider confirmations.
Submit through your provider and set a reminder
Upload or confirm in your payment dashboard, and repeat every year or when your checkout changes.
Stripe notes that Mastercard expects Level 4 merchants to comply with PCI DSS even where formal validation is not required. Doing the questionnaire anyway is the easiest way to prove it if something goes wrong.
Do it yourself or get help?
On a hosted checkout with a tidy website, the SAQ A is an afternoon's work. It is worth help if you run WooCommerce or a custom checkout, embed card fields, or are not sure whether any card data touches your systems.
Our Online Payment Setup (S$290) connects Stripe or HitPay using a hosted checkout or payment links, which keeps most merchants in SAQ A. Website Security Hardening (S$290) handles updates, plugin clean-up, admin two-step login, a firewall and HTTPS on the site around your checkout. Card fees are covered in our Stripe fees guide.
Frequently asked questions
Yes. Stripe says PCI compliance is a shared responsibility: Stripe is certified as a Level 1 Service Provider, and your business must accept payments in a compliant way and attest annually. Using Stripe Checkout or Elements usually means you only need the short SAQ A, and Stripe's dashboard can work out which documentation applies.
Stripe's PCI guide lists Checkout and Elements as SAQ A, because the card inputs are iframes served from Stripe's domain. Since the 2025 revision, merchants embedding a provider's form must also confirm their page is protected from script attacks, either with their own controls or a confirmation from the provider. The older Stripe.js v2 pattern is SAQ A-EP.
Recording card numbers on paper notes, email, WhatsApp or spreadsheets brings those systems into PCI scope, and SAQ A only fits merchants that retain account data on paper reports or receipts at most. Stop the practice, delete what you have securely, and use payment links or a virtual terminal for phone orders instead.
PCI DSS is an industry standard set by the PCI Security Standards Council, not a Singapore statute. It is required by your card acquirer and payment provider terms. Separately, the PDPA requires reasonable security for personal data, and a card data breach could also raise PDPA issues.
Every year, and again whenever you change how you take card payments, for example moving from a hosted checkout to an embedded or custom form. Stripe's guide says businesses must attest to compliance annually. Keep a copy of each completed SAQ and the evidence behind your answers.