Merchant PCI Basics
Merchant, Retailer, and Charity PCI DSS Basics
Almost everyone accepts credit or debit cards for transactions. More stores are moving online or supplementing their brick-and-mortar stores with online stores. We often think that PCI only applies to one of these (most often people expect PCI DSS only applies to e-commerce). The reality is that PCI DSS applies to every channel that accepts payment cards. Furthermore, you agreed to follow these requirements when you signed up with your merchant bank.
Protecting your customers’ data is vital to retaining the goodwill and trust you have built up with your customers over the years.
On this page, we cover some of the key things that merchants, retailers, not-for-profits, and charities need to be aware of.
Are You a Merchant?
A merchant is any entity that accepts payments for goods and services where those payments are made using a card that bears the logo of one of the participating card schemes. This includes both credit and debit cards as a method of payment.
You can be both a merchant and a service provider, but on this page, we focus on the PCI requirements for online, instore, over the phone, and via mail.
Merchant PCI Basics
The most common questions we get asked by people at the start of the PCI DSS compliance journey are:
- What do I have to comply with?
- What is my scope?
- What are my reporting requirements?
What’s My Scope?
Scope is all of the systems, people, and processes that are part of your PCI DSS compliance. Your scope depends on a number of things including how you accept payments. But it also depends on how you make sure that your “in-scope systems” have been secured so that they cannot have their security negatively affected by “out-of-scope” systems.
The PCI Information Supplement “Guidance for PCI DSS Scoping and Segmentation” sets out three different categories for scope:
- Cardholder Data Environment (in-scope)
- Security Impacting or Connected To (in-scope)
- Out-of-Scope
If you accept payments, you’ll never be able to reduce your scope to zero. You will always have a minimum number of PCI compliance requirements that you need to do. However, understanding these categories will make it easier for you to understand how to ringfence your compliance.
Read more about what each of these scope categories means for your PCI compliance and what you might need to do to take other systems out of scope.
What Are My Reporting Requirements
The PCI standards have a number of different reporting options for merchants that depend on:
- How many transactions you have per year (determines your “level”)
- How you accept payments (determines your SAQ)
If you have more than 6 million transactions per year, you will need to do a Report on Compliance (ROC). Most merchants will be able to use a Self Assessment Questionnaire (SAQ). There are 7 different reduced scope SAQs that might apply to your environment, each with a different set of requirements and applicability criteria that need to be met in order to use them.
| Ways of Accepting Payments (Merchants) | Potential SAQ |
|---|---|
| Online (e-commerce) |
SAQ A SAQ A-EP SAQ D |
| MOTO (mail / phone orders) |
SAQ A SAQ B SAQ B-IP SAQ C SAQ C-VT |
| Card-Present (EFTPOS) |
SAQ B SAQ B-IP SAQ P2PE |
Protecting Your Customers’ Data
You want to make sure that you protect your customers’ (or as a charity, your donors’) payment card data. There’s nothing more devastating than finding out you’ve been a point of compromise. Depending on how you accept customer payments, there are a few recommendations we have to help you ensure the transaction is secure.
Secure Your Website
Almost everyone has a website for their store. And the demand for onsite shopping continues to grow. But just because it’s easy to make an online store doesn’t mean it’s secure. Consider things like:
- How to secure your login
- What to ask your hosting provider
- Other ways you can secure your site
Secure Your EFTPOS
Merchants with EFTPOS terminals have a specific set of requirements they have to follow to secure their in-store transactions. “Card-skimming” is a common tactic used to capture card data at the point of sale. Key things you can do to minimise this risk are:
- Know your devices
- Check your devices
- Train Your staff
Secure Your Phone Payments
It’s not uncommon to take payments over the phone. But if you do, you need to make sure you’re doing the right things to keep those payments secure. This means making sure:
- Your computers are secure (patch them, run antivirus)
- Your phone calls are secure (don’t record payment information in call recordings)
- Your staff are trained on how to protect payment information
Secure Your Mail Payments
Not everyone shops online. Whether it is your customers who want to be able to pay by mail or that paying by mail is ht way you’ve always done things, making sure you keep your payments secure is still important. Make sure you:
- Protect mail-in forms with card data on them before you process the order
- Securely destroy that card data once it has been processed
- Never store sensitive data after authorisation
- Train your staff on how to securely handle payments
Managing Your Service Providers
Almost every organisation, large or small, has at least one service provider. It could be your:
- Payment gateway
- EFTPOS provider
- Data centre
- Web host or shopping cart provider
- Managed security services
Regardless of the type of service provider (or TPSP), it’s important to be aware of how the services they provide could affect your PCI DSS compliance and what you need to do to manage your vendors in a PCI compliant way.
Why You Need a Responsibility Matrix
One of the worst things you can hear during your PCI assessment (aside from maybe finding out that you’re storing unprotected cardholder data) is when your service provider says “that’s not my responsibility”. Suddenly you find yourself pushing your service provider to do things that are not in their contract, facing unforeseen costs, and potentially even having to work through an extended remediation period where you aren’t PCI DSS compliant.
Every single Self Assessment Questionnaire (SAQ) and Report on Compliance (ROC) has requirements for how you need to manage your service providers. A big part of this is making sure that you understand:
- Which requirements you are responsible for
- Which requirements your TPSP is responsible for
- Which requirements you and your TPSP share responsibility for
In v3.2.1 you might have expected to see information about which requirements were met by your service provider in the Attestation of Compliance (AOC). If you were lucky, your service provider provided you with a responsibility matrix alongside their AOC.
But in Version 4.0 of PCI DSS, the AOC is changing. You won’t be able to see which specific requirements were excluded from your service provider’s scope – you’ll only be able to tell if a high level (1-12) requirement was fully or partially in place.
However, service providers who are assessing against v4.0 are now required to provide you with information about:
- The PCI compliance status for any service performed on behalf of customers – this helps you meet Req. 12.8.4
- Information about which requirements are the TPSP’s responsibility, which are the responsibility of the customer, and which are shared – helping you meet your 12.8.5 requirements.
So if your service provider gives you a v4.0 AOC but no information about responsibilities, make sure you request the document they use to meet their 12.9.2 requirements.
Read more about how responsibility matrixes can make your PCI DSS compliance easier and help your QSA understand your real scope of requirements.
My Service Provider Isn’t Compliant, Now What?
There is no requirement that your service provider has to be PCI DSS compliant. However, you need to be aware of how this affects your PCI DSS compliance. If the services they provide are not done in a compliant way, this could cause you to become non-compliant. As a result, if your service provider can’t provide an AOC for the service they provide then they might need to be included within your compliance scope and may increase the number of requirements that you have to comply with.
Read more about how service providers can affect your PCI DSS compliance, how they can demonstrate their PCI compliance, and the steps that you can take to minimise your risk.
Back to Basics
If you want to learn more about some of the specific requirements and go into more depth, we recommend you check out our posts or head back to our PCI Basics page.
And if you need some help with your PCI DSS compliance, Confide is here to help you.
Common Merchant Questions
Levels are determined by the card schemes individually but calculated by your acquiring bank.
The tables below summarises the levels and the reporting requirements for each card scheme. What’s important to note is that normally if you’re considered as a level 1 merchant by one brand, all the other brands will consider that as your designation even if you don’t meet that threshold.
You may also require a higher level of assurance if you’ve had an account data compromise or you’re considered as a high-risk merchant.
American Express
| Merchant Level | # Annual Transactions | Payment Channel | Reporting |
|---|---|---|---|
| Level 1 | > 2.5 Million | All | Onsite Assessment (ROC) |
| Level 2 | 50k to 2.5 Million | All | Self-Assessment (SAQ) |
| Level 3 | 10k to 50k | All | Self-Assessment (SAQ) |
| Level 4 | < 10k | All | Self-Assessment (SAQ) |
Discover
| Merchant Level | # Annual Transactions | Payment Channel | Reporting |
|---|---|---|---|
| Level 1 | > 6 Million | All | Onsite Assessment (ROC) |
| Level 2 | 1 Million to 6 Million | All | Self-Assessment (SAQ) |
| Level 2 | < 1 Million | All | Self-Assessment (SAQ) |
JCB
| Merchant Level | # Annual Transactions | Payment Channel | Reporting |
|---|---|---|---|
| Level 1 | > 1 Million | All | Onsite Assessment (ROC) |
| Level 2 | < 1 Million | All | Self-Assessment (SAQ) |
Mastercard
| Merchant Level | # Annual Transactions | Payment Channel | Reporting |
|---|---|---|---|
| Level 1 | > 6 Million | All | Onsite Assessment (ROC) |
| Level 2 | 1 Million to 6 Million | All | Onsite Assessment (ROC) or SAQ completed by ISA |
| Level 3 | 20k to 1 Million AND < 20k e-comm |
All | Self-Assessment (SAQ) |
| Level 4 | < 20k | All | Self-Assessment (SAQ) |
Visa
| Merchant Level | # Annual Transactions | Payment Channel | Reporting |
|---|---|---|---|
| Level 1 | > 6 Million | All | Onsite Assessment (ROC) |
| Level 2 | 1 Million to 2.5 Million | All | Self-Assessment (SAQ) |
| Level 3 | 20k to 1Million | e-commerce | Self-Assessment (SAQ) |
| Level 4 | < 20k e-comm up to 1 Million | All | Self-Assessment (SAQ) |
If you’ve ever heard the term SAQ (sometimes pronounced like “sack”), they are referring to a Self-Assessment Questionnaire.
PCI allows merchants who only process a certain number of transactions annually to complete a SAQ.
If you are a service provider and are able to self-assess, the only SAQ you are allowed to use is SAQ D (Service Provider).
Merchants are required to submit one or more SAQs based on the payment channel or channels that you support. You should always get confirmation from your acquiring bank on which SAQ or SAQs they need you to submit. Especially if you have multiple payment channels.
Each SAQ has a set of criteria that you must meet in order to use that SAQ. If you do not meet these criteria, you will need to use a different SAQ. If you aren’t sure, please contact your bank. For every SAQ except D, you must confirm that you do not store any cardholder data. A data discovery tool (for example, card scanning) can be used to demonstrate that you do not store cardholder data.
The table below provides a quick summary of each of the SAQs.
| SAQ | Summary of Applicable Channel | Allows Storage of CHD |
|---|---|---|
| A | Card-not-present merchants that have fully outsourced all cardholder data functions to PCI DSS validated third-party service providers. No storage, processing, or transmission of cardholder data on the merchant systems or premises. | No |
| A-EP | E-commerce merchants who outsource all payment processing to PCI DSS validated third parties and who have one or more websites that don’t directly receive cardholder data but can impact the security of the payment transaction. No storage, processing, or transmission of cardholder data on the merchant systems or premises. | No |
| B | Merchants using either imprint machines and/or standalone, dial out terminals. No electronic storage of cardholder data. No e-commerce. | No |
| B-IP | Merchants using standalone PTS-approved payment terminals with an IP connection to the payment processor. No electronic storage of cardholder data. No e-commerce. | No |
| P2PE | Merchants using only hardware payment terminals included in and managed via a PCI SSC listed P2PE solution. No electronic storage of cardholder data. No e-commerce. | No |
| C | Merchants with payment application systems connected to the internet. No electronic storage of cardholder data. No e-commerce. | No |
| C-VT | Merchants who manually enter a single transaction at a time via a keyboard into an internet-based virtual terminal solution provided and hosted by a PCI compliant third party service provider. No electronic storage of cardholder data. No e-commerce. | No |
| D | All other merchants not included in the descriptions above. Merchants with multiple payment channels. Merchants that store cardholder data. | If Protected |
Yes – if you accept credit or debit cards for the purchase of goods or services and you signed up with a merchant agreement with your bank, you are probably required to be compliant as a merchant.
If you perform a service for other businesses and you are involved in their transactional activities or look after a service that affects their PCI compliance, you’re probably required to be compliant as a service provider (or be involved in every customer’s PCI assessment who needs one).
