The Payment Card Industry Data Security Standard is the set of security requirements that applies to any organisation storing, processing or transmitting cardholder data. It is not law. It is a contractual obligation that reaches you through your agreement with your acquiring bank, which in turn is bound by the card networks.
Compliance obligations should be confirmed with the organisation accepting your compliance validation, such as your acquirer or payment brand. PCI DSS is an industry standard; separate legal and contractual obligations can also apply. This article describes engineering choices, not a legal determination of your obligations.
Scope is about data flow, not company size
The most common misunderstanding is that PCI DSS applies proportionally to revenue. It does not. Transaction volume determines your merchant level, and your merchant level determines how you validate compliance, but the requirements themselves apply to whatever systems touch cardholder data.
Compare a merchant that receives card details through its own forms with one that redirects customers to a processor. Their transaction counts alone do not describe their exposure. The systems handling account data, the security of the integration and the applicable validation criteria need to be examined separately.
The primary account number is central to identifying cardholder data. Sensitive authentication data includes card verification codes, full track data and PIN data. A merchant must not retain sensitive authentication data after authorisation, even if encrypted. Do not collect these values in support tickets, application logs or troubleshooting screenshots.
The architecture decision that removes most of your scope
There are three broad ways to collect a card online, and they produce very different obligations.
The card posts to your server. Your page has its own card fields, the browser submits them to your backend, and your backend calls the processor. Your web server, your application, your logs and anything they touch are now in scope. This is the expensive route and there is almost never a reason to choose it.
Processor hosted fields. The card fields are rendered by the processor inside an iframe served from the processor domain, embedded in your page. Your JavaScript cannot read them. The browser sends the card directly to the processor and your server receives a token. Your systems never see the card.
Processor hosted checkout. The customer is redirected to a page the processor serves entirely. Your server never sees the card and your page never even renders a field.
These hosted options can keep card details outside the merchant application and reduce PCI scope when correctly implemented. They do not remove all merchant responsibilities. The PCI Security Standards Council explains the responsibilities that remain when payment processing is outsourced, including provider oversight and compliance validation.
What a token changes, and what it does not
A processor can return a payment method reference instead of exposing the card number. Its permitted uses depend on the provider, account and integration. That reference is not a general substitute for protecting data: compromised application credentials may allow an attacker to use saved payment methods within the account. Restrict access to both references and API credentials.
Tokens support the things people assume require storing a card number. Charging a customer again later. Saving a payment method. Running a subscription. Taking a deposit now and a balance in three weeks. All of it works on a reference, which is why there is no legitimate reason for a modern application to store a card number.
Validation: what you actually have to do
Merchants validate compliance by completing a self assessment questionnaire, and there are several versions. Which one applies depends on how you accept payment.
A questionnaire is not selected by counting fields or assuming that all embedded checkouts share the same eligibility. Document the integration, check its current eligibility criteria with the relevant compliance accepting entity, and record which responsibilities belong to the merchant and which belong to the provider. Do not claim that a particular questionnaire automatically applies to every hosted payment integration.
Your acquirer tells you which one applies. Not your developer, not your processor, and not a blog post. What your developer controls is which one you are eligible for, and that is decided by the integration.
The obligations that remain regardless
Even with the card entirely out of your systems, some requirements still apply.
A hostile script cannot simply read a correctly isolated cross origin frame. It can still tamper with the surrounding page, replace the intended payment interface or redirect a customer to a fraudulent form. Review the integrity of the checkout journey, limit unnecessary scripts and investigate unexpected changes rather than treating an iframe as a complete security boundary for the whole website.
You still need managed access and a clear account ownership model. Protect the payment method to customer mapping, review permissions on processor credentials, and avoid putting payment references into public URLs or analytics events.
Inspect logging configuration as part of integration review. Verbose debugging can capture fields that do not belong in a log. Use explicitly allowed diagnostic fields rather than recording every incoming request, and apply the same review to support tools and error reporting services.
What we do and do not do
Sawhorse integrates with processors. We are not a payment processor, we hold no PCI certification, and we do not build card processing infrastructure. What we build is the integration, and we build it so the card goes from the browser to the processor and your systems only ever handle a token.
That boundary keeps our application work focused on orders, payment states, verified notifications and reconciliation. It does not make Sawhorse a compliance assessor or transfer the merchant’s responsibilities to us.
Before changing an existing integration, inventory every payment channel. A new hosted website checkout does not automatically change the obligations attached to telephone orders, physical terminals or another legacy application. Agree the migration and validation approach with the relevant providers before removing existing controls.