An online store and a marketing site often run on the same hosting, the same CMS, even the same design system — the visible parts barely change. What does change the moment a site starts taking card payments is compliance scope and how often the site needs attention. Route the checkout through a hosted, redirect-style payment page and a store can stay inside PCI DSS's shortest tier, SAQ A — a 22-question self-assessment, not the full standard's several hundred controls — but only if the integration genuinely stays outside the site's own code.
Nothing on this covers what a maintenance plan should generally include or a marketing site's usual concerns — this is specifically about the one decision that changes once money starts moving through the site, which is worth understanding before it gets built, not after.
What actually shrinks the compliance burden
PCI DSS applies to any business that accepts card payments, full stop — there's no small-store exemption. What varies enormously is how much of it a given business has to personally attest to, and that comes down to one build decision: does cardholder data ever touch the merchant's own server, even briefly? Redirect a customer to the processor's own checkout page, or load it in an iframe so the card fields are rendered and submitted entirely by the processor, and the answer is no — that qualifies for SAQ A, the shortest questionnaire, at 22 questions. Build a payment form into the site's own pages instead — even one that calls the same processor's API underneath — and the merchant is pulled into a longer questionnaire (SAQ A-EP or SAQ D) with substantially more to review and attest to, because card data did pass through code the merchant controls, if only for a moment.
This is why a hosted or redirect checkout is the default we build to rather than a custom payment form: it's not a cosmetic choice, it's the difference between a compliance checklist a store owner can realistically keep current themselves and one that needs a security review to even understand.
Why a store needs a tighter maintenance rhythm than a brochure site
A five-page marketing site can go months untouched and nothing about it goes stale in a way that costs money. A store can't — prices and stock change constantly, and the payment integration itself is a live dependency on someone else's schedule, not the store's. Processors version and eventually retire their APIs and SDKs on their own timeline; an integration that worked perfectly at launch can start silently failing at checkout months later because a deprecation notice went to an inbox nobody was reading. That's a different failure mode from a stale About page — a broken checkout costs revenue the moment it happens, not just search ranking. It belongs in the same recurring maintenance discipline covered in how often a website should actually be updated, just with a shorter interval for anything payment-related than for the rest of the site.
Frequently asked questions
Does a small online store need to worry about PCI DSS?
Yes — any site accepting card payments falls under PCI DSS, even a one-product store. Routing payment entirely through a hosted or redirect checkout (Stripe Checkout, PayPal, and similar) is what qualifies a merchant for SAQ A, the shortest self-assessment questionnaire at 22 questions, because cardholder data never reaches the merchant's own server.
What's the difference between a hosted checkout and an embedded payment form?
A hosted or redirect checkout sends the customer to the processor's own page, or loads it in an iframe, so nothing card-related ever touches the merchant's server — that is what qualifies for SAQ A. Building a payment form directly into the site's own pages, even while calling the same processor's API underneath, pulls the merchant into a larger questionnaire (SAQ A-EP or SAQ D) with far more to attest to.
Does using Stripe or PayPal automatically make a store PCI compliant?
No. The processor itself is PCI DSS compliant, but the merchant still has to complete and keep on file the applicable self-assessment questionnaire for their own integration. Using a compliant processor narrows which questionnaire applies — it does not remove the requirement to complete one.
How often should a store's payment integration actually be checked?
As part of regular maintenance, not a one-off setup step. Payment processors version and eventually deprecate their APIs and SDKs on their own schedule, independent of anything the store owner changes — an integration that worked fine at launch can silently start failing months later if nobody is watching for a deprecation notice.