Why Scope Depends on Where Card Data Travels
PCI DSS (the Payment Card Industry Data Security Standard) exists to protect cardholder data wherever it is stored, processed, or transmitted. For a merchant, the practical weight of that standard is not the same for every business. It depends on which of your systems actually come into contact with a card number, an expiry date, or a CVV during a transaction. The more of your own infrastructure sits in that path, the more of it falls inside PCI DSS scope.
When You Never See the Card Number
Some merchants never have the raw card number pass through their own servers at all. The shopper enters card details on a page served and secured by a payment provider, and the merchant's systems only ever receive a result (approved, declined) and a reference to the transaction. In this model, the merchant's own environment is largely outside the part of PCI DSS that deals with storing or transmitting card data, because that data genuinely never arrives there.
Redirects and Hosted Checkout Pages
A common way merchants achieve this is by sending the shopper to a hosted checkout page, such as the one offered through omwio, instead of building a card entry form themselves. The shopper is redirected to the hosted page, completes payment there, and is sent back to the merchant's site once the transaction is done. Because the merchant's own site never collects or touches the card fields, this pattern keeps a large share of PCI DSS requirements outside the merchant's own systems.
When Your Systems Process or Store Card Data Directly
Other merchants build their own card entry forms, route card data through their own servers before it reaches a processor, or store card details for later use. Any of these choices brings the merchant's own systems into the part of card data that PCI DSS cares about most directly: storage, processing, and transmission. In that setup, the people, processes, and systems that touch card data during a transaction, and any place that data is stored, need to be accounted for as part of the merchant's compliance picture.
Keeping Your Compliance Footprint Small
Regardless of size, the general pattern holds: the fewer of your own systems that see raw card data, and the shorter the time any system holds it, the smaller the part of your business that PCI DSS requirements apply to in full. Using tokenization, hosted payment pages, or a provider's own checkout flow are all ways merchants reduce how much of their own environment is directly involved with card numbers, rather than building and maintaining that handling themselves.
Talk to Your Acquirer and Payment Partner
PCI DSS obligations, validation requirements, and how they apply to a specific business are ultimately determined between a merchant, their acquirer, and where relevant a qualified assessor. This article is a general orientation to how card data flow changes the shape of the question, not a substitute for that conversation. Before deciding how your checkout handles card data, it is worth asking your acquirer or payment provider directly what that choice means for your specific compliance obligations.
- Card data never reaches your servers: your own PCI DSS footprint is smaller.
- Shoppers are redirected to a hosted checkout page: your site stays out of the card data path.
- Your own systems capture, route, or store card numbers: those systems are part of your compliance scope.
- Always confirm specific obligations with your acquirer or a qualified assessor.
