What Are the Merchant Levels

Alastair Stewart
|
Senior Consultant at URM
|
PUBLISHED on
5 Aug
2022

We are often asked, both by those new to PCI DSS and those who have been involved for a while, what is the difference between a merchant and a service provider, what are the ‘levels’ and what do they really mean? Are the levels based on individual transactions, overall value or by card brand?  And the list goes on. In the next two blogs, we will look at the levels, provide some clarity and highlight the differences between the major card brands.

The number of organisations that accept card payments, and the variety of methods they utilise to accept those payments, has grown exponentially in the last few years.  The number and complexity of services and systems to support those organisations has also multiplied at an overwhelming pace.  In line with this, the risks have also increased, which has been demonstrated by the torrent of breach activity that has recently made the news.  It is therefore vital to understand how PCI DSS applies to you, or those organisations you work with, and what requirements apply to you so that you can achieve and maintain compliance.

So, let’s start with merchants.  A merchant is defined as ‘any entity that accepts payment cards bearing the logos of any of the 6 members of PCI SSC (American Express, Discover, JCB, MasterCard, UnionPay, or Visa) as payment for goods and/or services.  This is relatively simple for merchants, as they have a merchant agreement with an acquiring bank.  A merchant identification number (MID) is a unique code given to a business by the payment processors before the merchant begins processing card payments.  The MID is attached to the merchant account and transmitted, along with the cardholder’s information, to facilitate reconciliation.

Having said it is relatively simple, we have just introduced two new terms – acquiring bank and payment processors.  Let’s step back and make sure we understand those.  The terms ‘acquirer’ and ‘payment processor’ are sometimes used interchangeably (and an organisation can be both), but they actually refer to two different functions.

  • An acquirer is the financial institution that processes credit and/or debit card transactions
  • A payment processor is a company that communicates with the issuing banks.

After the customer has used their card, received confirmation from your website, or hung up the phone, both the acquirer and the payment processor each service a unique function.  A payment processor effectively acts as the mediator between you and the financial institutions involved in payment transactions.  Processors authorise transactions and ensure you get paid on time by facilitating the transfer of funds from your customers’ accounts to your own.  Examples of well- known payment processors are Worldpay (that said, Worldpay is an example of an organisation that is both an acquirer and a payment processor) and First Data.  The acquirer is most often the merchant’s or retailer’s bank.  The acquirer is responsible for taking the approved transaction (that was approved by the payment processor) and settling the transaction.

At first glance, the PCI DSS merchant levels are as follows:

  • Level 1 – Over 6 million transactions annually
  • Level 2 – Between 1 and 6 million transactions annually
  • Level 3 – Between 20 000 and 1 million transactions annually
  • Level 4 – Less than 20 000 transactions annually

However, it is important to note that this transaction volume is actually per card brand.  Therefore, if you process 500,000 Visa card numbers and 500,000 Mastercard numbers, you’re likely to be classified as a Level 3 merchant.  It’s also important to note that the card brands have their own slightly different interpretations of merchant levels, but generally, if the merchant is classified Level 1 for a particular card brand, it’s likely this classification will be considered the same for all brands.

So, what do these levels mean?  Well, each level has different validation requirements for proving compliance the PCI DSS.  Equally, each brand may have different requirements based on a number of factors, such as whether your organisation has suffered a breach recently, or if you are new to PCI DSS.

Level Validation Requirements
Level 1
  • Annual Report on Compliance (RoC) by a Qualified Security Assessor (QSA) (or ISA-accredited staff member for Mastercard)
  • Quarterly network scan by an approved scanning vendor (ASV)
  • Attestation of Compliance (AoC) form
Level 2
  • Annual Self-Assessment Questionnaire (SAQ) (Mastercard requires merchant staff to be ISA certified or use a QSA for an onsite assessment)
  • Quarterly network scan by an ASV
  • AoC form
Level 3
  • Annual Self-Assessment Questionnaire (SAQ)
  • Quarterly network scan by an ASV
  • AoC form
Level 4
  • These largely depend on the requirements of the merchant’s acquiring bank
  • Typically include an SAQ and quarterly network scan by an ASV


However, a key point to remember; it is important that you don’t just look at the volume of transactions you are doing today.  What are your growth plans?  Do you expect to fall into the next bracket next year?  If yes, focus your compliance programme on the next level up.

Alastair Stewart
Senior Consultant at URM
Alastair is one of the most experienced and proficient Payment Card Industry Qualified Security Assessors (PCI QSAs) in the UK. He has completed in excess of one hundred successful reports on compliance (RoCs) against different PCI DSS versions along with supporting the completion of self-assessment questionnaires (SAQs).
Read more

Are you looking for help preparing for a PCI DSS assessment?

As a PCI QSA, URM can assist you with a range of services, including conducting gap analyses, helping you reduce your CDE scope and conducting penetration tests.
Thumbnail of the Blog Illustration
Information Security
Published on
3/6/2024
PCI DSS v4.0: Forced Password Changes and Zero Trust Architecture

URM’s blog drills down into the PCI DSS v4.0 requirements around forced password changes, with a particular focus on the addition of zero-trust architecture.

Read more
Thumbnail of the Blog Illustration
Information Security
Published on
15/2/2023
PCI DSS v4.0 and Multi-Factor Authentication

After the recent changes to PCI DSS v4.0 we're examining factors behind the greater utilisation of MFA, and what the key changes are in requirements.

Read more
Thumbnail of the Blog Illustration
Information Security
Published on
5/8/2022
PCI DSS compliance as BAU (business as usual)

For an organisation to achieve and maintain compliance to the Payment Card Industry Data Security Standard (PCI DSS)....

Read more
Thank you for a very informative overview of the components in the revised Standard.
Webinar 'ISO 27001:2022 – What’s new?'
contact US

Let us help you

Let us help you in your compliance journey by completing the form and letting us know how we can best support you.