PCI Compliance

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards designed to ensure that ALL companies that accept, process, store or transmit credit card information maintain a secure environment.

The Payment Card Industry Security Standards Council (PCI SSC) was launched on September 7, 2006 to manage the ongoing evolution of the Payment Card Industry (PCI) security standards with a focus on improving payment account security throughout the transaction process.

The PCI DSS is administered and managed by the PCI SSC (www.pcisecuritystandards.org), an independent body that was created by the major payment card brands (Visa, MasterCard, American Express, Discover, Union Pay, and JCB.).

It is important to note that the payment brands and acquirers are responsible for enforcing compliance, not the PCI council.

All merchants will fall into one of the four merchant levels based on Visa transaction volume over a 12-month period. Transaction volume is based on the aggregate number of Visa transactions (inclusive of credit, debit and prepaid) from a merchant Doing Business As (‘DBA’).

In cases where a merchant corporation has more than one DBA, Visa acquirers must consider the aggregate volume of transactions stored, processed or transmitted by the corporate entity to determine the validation level.

If data is not aggregated, such that the corporate entity does not store, process or transmit cardholder data on behalf of multiple DBAs, acquirers will continue to consider the DBA’s individual transaction volume to determine the validation level.

Merchant levels as defined by Visa:

Merchant Level # 1: Any merchant — regardless of acceptance channel — processing over 6M Visa transactions per year. Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the Visa system.

Merchant Level #2: Any merchant — regardless of acceptance channel — processing 1M to 6M Visa transactions per year.

Merchant Level #3: Any merchant processing 20,000 to 1M Visa e-commerce transactions per year.

Merchant Level #4: Any merchant processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants — regardless of acceptance channel — processing up to 1M Visa transactions per year.

To satisfy the requirements of PCI, a merchant must complete the following steps:

• Determine which Self-assessment Questionnaire (SAQ) your business should use to validate compliance.
• Complete the Self-assessment Questionnaire according to the instructions provided.
• Complete and obtain evidence of a passing vulnerability scan with a PCI SSC Approved Scanning Vendor (ASV). Note scanning does not apply to all merchants. It is required for SAQ A-EP, SAQ B-IP, SAQ C, SAQ D-Merchant and SAQ D-Service Provider.
• Complete the relevant Attestation of Compliance (AOC) in its entirety (located in the SAQ tool).
• Submit the SAQ, evidence of a passing scan (if applicable), and the Attestation of compliance, along with any other requested documentation, to your acquirer.

The following post, “How Does Taking Credit Cards by Phone Work with PCI?” explains your PCI compliance responsibilities when taking credit card information over the phone (e.g., in a call center). Note that while this post was published in 2014, it is still relevant with the current version of the PCI DSS.

Yes. Merely using a third-party company does not exclude a company from PCI DSS compliance. It may cut down on their risk exposure and consequently reduce the effort to validate compliance. However, it does not mean they can ignore the PCI DSS.

If your business locations process under the same Tax ID, then typically you are only required to validate once annually for all locations. And, submit quarterly passing network scans by a PCI SSC Approved Scanning Vendor (ASV) for each location, if applicable.

The university strongly discourages storing credit card data. Prior to proceeding with the storage of credit card data, please contact the Universities PCI Compliance area for direction at eilist@ualberta.ca.

Most merchants that need to store credit card data are doing it for recurring billing. The best way to store credit card data for recurring billing is by utilizing a third party credit card vault and tokenization provider. By utilizing a vault, the card data is removed from your possession and you are given back a “token” that can be used for the purpose of recurring billing. By using a third party, you move the risk of storing card data to someone who specializes in doing that and has all of the security controls in place to keep the card data safe.

The payment brands may, at their discretion, fine an acquiring bank $5,000 to $100,000 per month for PCI compliance violations. The banks will most likely pass this fine along until it eventually hits the merchant.

The bank could terminate your relationship or increase transaction fees. Penalties are not openly discussed nor widely publicized, but they can be catastrophic to an organization.

The PCI Security Standards Council (SSC) defines ‘cardholder data’ as the full Primary Account Number (PAN) or the full PAN along with any of the following elements:

• Cardholder name
• Expiration date
• Service code

Sensitive Authentication Data, which must also be protected, includes full magnetic stripe data, CAV2, CVC2, CVV2, CID, PINs, PIN blocks and more.

For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, Union Pay, JCB, MasterCard or Visa) as payment for goods and/or services.

The PCI SSC defines a Service Provider this way:

“Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data. This also includes companies that provide services that control or could impact the security of cardholder data.” (Source: www.pcisecuritystandards.org)

The “merchant as a service provider” role is further specified by the PCI SSC as “a merchant that accepts payment cards as payment for goods and/or services…if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers.” Learn more about how to achieve compliance as a Service Provider. See our blog post, “PCI Compliance and the Service Provider.”

The term payment application has a very broad meaning in PCI. A payment application is anything that stores, processes, or transmits card data electronically. This means that anything from a Point of Sale system in a restaurant to a website e-commerce shopping cart are all classified as payment applications.

Any software that has been designed to touch credit card data is considered a payment application.

PA-DSS refers to Payment Application Data Security Standard maintained by the PCI Security Standards Council (SSC) to address the critical issue of payment application security. The requirements within the PA-DSS are designed to ensure that vendors provide products which support merchants’ efforts to maintain PCI DSS compliance and eliminate the storage of sensitive cardholder data.

PCI DSS requirement 3.3 states:

Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).

While the requirement does not prohibit printing of the full card number or expiry date on receipts (either the merchant copy or the consumer copy), please note that PCI DSS does not override any other laws that legislate what can be printed on receipts

A vulnerability scan involves an automated tool that checks a merchant or service provider’s systems for vulnerabilities. The tool will conduct a non-intrusive scan to remotely review networks and web applications based on the external-facing Internet protocol (IP) addresses provided by the merchant or service provider.

The scan identifies vulnerabilities in operating systems, services and devices that could be used by hackers to target the company’s private network. Learn more about vulnerability scans here.