Your website provider handles payments. Are you off the hook for PCI DSS?
If your website provider told you not to worry about PCI DSS because “we handle the payments”… and you haven’t asked for proof …you might need to start worrying.
It’s one of the most common things we hear from businesses: “Our provider takes care of everything: the website, the bookings, the payments. They said PCI DSS isn’t something we need to think about.” But often times, that advice is wrong. Not a little bit wrong. Quite wrong.
This post (part 1 of a 2-part advisory) is for any Australian business that accepts card payments through a website, booking system, or app that was set up and is managed by a third party. If that’s you, read on, because PCI DSS compliance doesn’t go away just because someone else built and manages your website.
But they handle the payments!
Here’s how it typically plays out.
You run a business. Could be a medical practice, a café, a professional services firm, a retailer. You’ve engaged a provider to build and manage your online presence. They’ve done a good job. The website looks professional, customers can book appointments or place orders online, and payments just work. The provider might even manage a phone-based booking system that takes card details on the spot.
At some point, you’ve asked whether you need to worry about PCI DSS.
And your provider has said something along the lines of: “Don’t worry, we use payment gateway X. It’s all secure. You don’t need to do anything.”
That answer felt reassuring. It sounded like the advice came from someone who knows what they’re doing. But there’s a problem: The advice often conflates two very different things. And if that’s the case, then the advice is often wrong.
This and that: they're not the same
Here’s how this part of the PCI DSS works.
The payment gateway, the company that actually authorises and processes the card transaction (e.g. Bambora, Stripe, Square, or similar) is almost certainly PCI DSS compliant. They have to be. The card brands require it. That part is fine.
You may have seen Square, Stripe, or similar gateways say they handle PCI compliance for their sellers. And they do, under certain conditions, such as when a merchant integrates directly with the gateway using the gateway’s own hosted payment forms, SDKs, or hardware. But if your website provider has built their own payment form or booking system that collects card details and passes them through to the gateway, the data is flowing through the provider’s systems first. The gateway’s compliance covers the gateway. It does not cover the web-service provider that sitting in front of it.
Why? Because the provider that built your website and integrated that payment gateway into your booking system, your phone payments, or your app; that provider’s service is sitting between your customer’s card details and the gateway. The service provider may be storing, processing, or transmitting cardholder data across multiple channels. And if they are, they are almost certainly a third-party service provider (TPSP) under PCI DSS, with their own compliance obligations. Specifically, SAQ D for Service Providers, which is the most comprehensive self-assessment questionnaire the PCI SSC publishes.
Here’s the critical distinction: the payment gateway being compliant does not make your website provider compliant. They are different organisations with different systems and different obligations. If your provider’s platform is handling cardholder data, even briefly, even if they’re passing it straight through to the gateway, they are in scope. And if they don’t have a current Attestation of Compliance (AOC) supported by either a completed SAQ D for Service Providers or a Report on Compliance (ROC), they are not PCI DSS compliant.
And if that’s the case then you, as the merchant:
- Are relying on a non-compliant service provider.
- Are implicitly accepting the risk of the service provider’s non-compliance.
When "we handle the payments" falls apart
To illustrate the problem, consider the following scenario. The details are hypothetical, but the pattern is one we see regularly.
A small Australian café chain (let’s call them “Bean & Counter”) has grown from a single shopfront to four locations with a growing catering and online ordering business. They engage a platform provider to bring everything under one roof: the website, the ordering system, the phone system, and the payments. The platform handles:
- Online ordering via the provider’s website, where customers enter their card number, expiry, and CVV to pay for pickup or delivery orders. The payment form is embedded in the provider’s platform, which passes the transaction to a well-known payment gateway.
- Phone orders for catering, where staff take card details over the phone and enter them into the provider’s system to process payment. The provider also supplies and manages the business’s PABX phone system, meaning the telephony infrastructure through which those card details are communicated is itself part of the provider’s service.
- A subscription and loyalty program where regular customers store their card details in the platform for automatic weekly billing (say, a standing coffee order or a recurring catering arrangement).
That is at least three distinct channels through which cardholder data flows through the provider’s systems on its way to the payment gateway. The provider’s platform is collecting, transmitting, and in some cases likely storing card details across web forms, phone entries, and stored-card subscriptions.
By any reading of PCI DSS, this provider is a textbook third-party service provider, squarely in scope, and obligated to demonstrate compliance via an Attestation of Compliance (AOC) supported by either a completed SAQ D for Service Providers or, for Level 1 service providers, a full Report on Compliance assessed by a QSA.
When the café owner asks about PCI DSS, the provider’s response is: “Don’t worry about that. We use payment gateway X. It’s all secure. You don’t need to do anything.”
Sound familiar?
Yes, it does sound familiar
If that scenario does sound familiar, then we’re not surprised. This pattern is one we see more frequently than any other:
- The payment gateway is a reputable, PCI DSS compliant processor, and is indeed compliant. No issue there.
- But the provider itself, the one that said there was nothing to worry about? Well, in the scenario we commonly see, they may have no published Attestation of Compliance. No evidence of a completed SAQ D for Service Providers. And no listing on the PCI SSC’s registry of compliant service providers. Nothing.
In that scenario, Bean & Counter finds themselves in a difficult position: They have relied on a service provider that handles cardholder data across multiple channels but that cannot evidence PCI DSS compliance. If something goes wrong (a data breach, an acquirer audit, a card brand inquiry) then Bean & Counter is left holding the risk, not the provider. Why? Because Bean & Counter signed the merchant agreement stating that they would be responsible for their own PCI DSS compliance and reporting, and that agreement remains enforceable no matter what the service provider says.
This is what happens when a business takes “we handle the payments” at face value without asking the follow-up question: “Can you prove it?”. This is not an unlikely scenario. This happens all the time!
What to do, right now!
This is part one of this article and part two is coming soon. But you don’t need to (and you should not!) wait until part two before taking action.
If any of the above sounds familiar, here are three things you should do immediately.
1. Ask your provider for their Attestation of Compliance (AOC).
This is the single most important step. If your website provider, booking platform, or any other third party handles card data on your behalf, ask them for evidence of their PCI DSS compliance. A compliant service provider will have a current AOC, supported by either a completed SAQ D for Service Providers (for Level 2 service providers) or a Report on Compliance (ROC) from a QSA-led assessment (for Level 1 service providers). If they can produce it quickly, that’s a good sign. If they can’t, or if they respond with confusion, deflection, or “we use payment gateway X so we’re covered”, that tells you everything you need to know. That is, they actually don’t know!
2. Map your cardholder data flow.
Understand where card data enters your environment, who touches it, and where it goes. Does your provider collect card details via a web form? Do they take card details over the phone on your behalf? Do they store card details for recurring billing or subscriptions? Every channel where cardholder data is captured, transmitted, or stored is in scope, and every organisation that participates in that flow has PCI DSS obligations.
3. Don’t confuse the payment gateway with the provider.
This is the mistake at the heart of the problem. Your provider telling you “we use Stripe” or “we use Bambora” is not evidence that the provider is compliant. All it means is that the gateway at the end of the chain is compliant. Everything between your customer’s card and that gateway (your provider’s web forms, their phone systems, their servers, their subscription platforms) is a separate compliance question, and it’s a question you should be asking.
These three steps will tell you whether you have a problem. If you do, our part-two follow-up post will cover what PCI DSS actually requires, how to determine which SAQ applies to you, and why the Australian regulatory environment makes this more urgent than it used to be.
dotSec and PCI DSS compliance in Australia
dotSec is a PCI DSS-compliant service provider with a current Attestation of Compliance (AOC). We don’t just advise on compliance; we’ve been through the process, we maintain it, and we know first-hand what it takes to implement and sustain a compliant service.
If you’re wondering whether your website provider’s assurances actually hold up, or if you’ve asked for an AOC and been met with a blank stare, we can help you work out where you stand and what to do next.
Premier australian cyber security specialists
