In this guide 7 sections
A hosted payment page or embedded hosted fields keep card numbers off your server, so a small store usually answers a shorter self assessment questionnaire. The provider carries the card data burden. You still patch the platform, control who logs in and watch every script that runs on your checkout page, because those jobs never move to the provider.
Why card data location sets your workload
PCI DSS is a standard from the card brands, and it applies to anyone who stores, processes or transmits cardholder data, in a business of any size. The question for a small store is simple. Do the card numbers ever touch your systems?
If a customer types a card number into a form served by your own server, that server is in scope. Every plugin, log file and database backup on it becomes something an assessor may ask about, which is a heavy load for a shop with two staff. It is rarely worth carrying.
Hosted payments change the answer. The number travels straight from the buyer’s browser to the provider’s servers, and your server only receives a token plus an approved or declined result.
Redirect, iframe and hosted fields are not the same
A full redirect sends the buyer to a page on the provider’s domain, so your site never renders a card field at all. That is the smallest scope and the plainest checkout. The page can feel detached from your brand.
Hosted fields keep the buyer on your page. Each card field is an iframe or script-built element served by the provider, so the look matches your theme while the typing lands on their side.
The two options often land on different questionnaires, because your page now delivers code that sits next to the card fields. Ask your provider which form applies to your exact integration, and keep their reply in an email you can find later.
- Full redirect: buyer leaves your domain to pay
- Iframe: provider page shown inside yours
- Hosted fields: provider elements in your layout
- Direct post or your own form: widest scope, most work
Which self assessment questionnaire you answer
Smaller merchants complete a Self Assessment Questionnaire. SAQ A is the short one. It suits stores that hand every payment step to a validated third party, and SAQ A-EP covers sites whose own pages influence how the card data is sent.
SAQ D is the long form for anyone who handles card data directly, and most small stores should aim never to see it. Your acquirer decides what you must complete. Ask before you pick a form.
This is software design, not legal advice. The standard is revised from time to time, so read the current version on the council’s site before you plan any checkout change.
What stays on your side after you go hosted
Going hosted does not make PCI disappear. Your platform, theme and plugins still need patches, because an outdated checkout plugin is how many small stores get a card skimmer injected. Patch on a schedule.
The standard now watches payment page scripts. A store should know every script that loads on checkout, who approved it and whether it has changed since the last review by a named person. Last spring’s agency tag counts.
Keep this list short. Every extra third-party script on the payment page is one more thing to defend and review, so ask the marketing team to justify each tag before it ships.
- Patch the platform, theme and plugins on a schedule
- Use unique admin logins with two-step sign-in
- Remove staff accounts the day someone leaves
- Keep an inventory of scripts loading on checkout
- Record the provider’s compliance status each year
Build the checkout so scope stays small
Early choices set your workload. Never write card numbers to order notes, support emails or chat transcripts, even when a customer pastes one into a message and asks you to process it. Mask what staff can see in the admin, and keep refund tools on the provider’s dashboard instead of copying data across.
Keep the token and last four digits only. Set a content security policy header on the checkout page, so that only approved domains may run code there and a stray tag stops working.
This week, open your checkout in a browser, view the network tab, and list every domain that loads, noting any domain that nobody can explain. Hand that list to whoever owns the site.
Checkout scope worksheet
The worksheet fits on one printed page. The top section records how card entry works today, whether redirect, iframe, hosted fields or own form, plus the provider and the integration date. Below it sits a table of every script on the payment page, with columns for domain, purpose, owner, approval date and last change. The last section lists patching, admin access and annual provider status checks, each assigned to a named person who signs and dates the line every year.
Open a blank worksheet to printQuestions owners ask
Does a hosted payment page remove PCI DSS duties completely?
No. It shrinks them. You still secure the platform, limit admin access and manage scripts on pages that lead to payment, and your acquirer tells you which questionnaire to complete.
Is Shopify or a hosted platform enough on its own?
A hosted platform handles much of the card flow, yet theme code, apps, staff accounts and any custom checkout scripts remain yours to keep patched and reviewed. Check what the platform covers. Ask what it leaves to you.
Why do payment page scripts matter?
Attackers inject code into checkout pages to copy what buyers type, and a script they add stays invisible when nobody keeps an approved list. A short, monitored list makes tampering easier to spot.
Who decides which questionnaire I fill in?
Your acquirer or payment provider sets the requirement, based on how your checkout is built, so describe your integration to them exactly as it runs today. Then keep their reply with your records.
Sources
- PCI Security Standards Council document library (PCI DSS and SAQs) — verified 17 Oct 2026