Card Data Security

We help our developer partners stay current on emerging card data security compliance requirements. We provide continuous card data security education and assistance in developing payment applications that are compliant with the Payment Card Industry Data Security Standard (PCI DSS).

Through our partnership with an independent, qualified security assessor, we provide discounted payment application evaluation and audit services to meet the requirements for PABP (PA DSS) validation

Our developer support experts are experienced and knowledgeable about security compliance. We help developers identify areas that need remedial work and help them complete it prior to requesting an independent audit. This can save our developers time and up to thousands of dollars.

We provide easy access to information, tools and resources on our customized MercuryView™ partner portal.

Visa’s top five data security vulnerabilities

  1. Storage of sensitive cardholder data, including track data, Card Verification Value 2 (CVV2), and Personal Identification Numbers (PINs) or PIN blocks
  2. Missing or outdated security patches
  3. Using vendor-supplied default settings and passwords
  4. Insecure website code
  5. Unnecessary and vulnerable services on servers

Merchant levels and compliance requirements

What do they mean by level 1, 2, 3, 4 merchants? These are the levels assigned to merchants based on Visa transaction volume over a 12-month period.

Merchant levels defined

Compliance requirements by level

Level 1

Annual onsite PCI DSS assessment by merchant’s internal auditor or qualified security assessor, or an internal audit, signed by an officer of the company, in addition to a quarterly network security scan done by an approved scanning vendor.

Level 2

Completion of PCI DSS self-assessment questionnaire annually, and a quarterly network security scan done by an approved scanning vendor.

Level 3

Completion of the PCI DSS self-assessment questionnaire annually and a quarterly network security scan done by an approved scanning vendor. As of 10/01/08, all newly boarded merchants must use a PABP compliant application.

Level 4

Completion of the PCI DSS self-assessment questionnaire annually and a quarterly network security scan done by an approved scanning vendor. As of 10/01/08, all newly boarded merchants must use a PABP compliant application.

Remote access software safety

Many of our partners use remote access programs to enable prompt customer service for their merchants. We offer a few reminders about the safe use of remote access software. If not configured and managed correctly, it can provide an easy entry point for unauthorized intruders to gain access to the POS system, and potentially to private customer data.

  1. Limit the number of people that can access the system remotely. Only allow and provide remote access to those who have a strong business need. This typically includes the POS system vendor/reseller for remote service and may also include owners, management and administrators of the merchant location.
  2. Do not share remote access credentials. Ensure that each user with remote access has a unique username and password.
  3. Disable remote access user accounts when no longer needed.
  4. Never leave remote access software on and "listening" for incoming connections. It is always best to select a remote access package that requires a user at the merchant site to start or log on to initiate a remote access session.

What are all those acronyms?

PCI DSS (Payment Card Industry Data Security Standards) – A security standard, implemented by the PCI Security Standards Council for all card brands, to protect cardholder data. It includes requirements for security management, policies, procedures, network architecture, software design, and other protective measures to help facilitate the broad adoption of consistent data security measures. www.pcisecuritystandards.org

PCI Security Standards Council – A council founded by American Express, Discover, JCB, MasterCard Worldwide, and Visa International to enhance payment account data security by fostering broad adoption of the PCI Security Standards. www.pcisecuritystandards.org

*PABP (Payment Application Best Practices) – A set of requirements a developer’s point-of-sale payment application must comply with to be considered secure. A list of POS system developers who have gone the extra mile to become validated by an independent, Visa-certified security assessor is available on Visa’s website.

*PA DSS (Payment Application Data Security Standard) – PABP is evolving to PA DSS with the PCI Security Council’s adoption and management of Visa’s PABP program, making it industry wide.

PCI PED (Payment Card Industry PIN Entry Device) – This standard complements the PCI-DSS. It outlines the rules and regulations governing the approval of security for PIN Entry Devices (PED). It’s designed for PIN Pad manufacturing, setup, and use. It can be considered complementary to the PCI-DSS. By following this document, those companies and entities that focus primarily on PEDs can more easily and effectively validate the security of their products. Some card associations such as Visa require the use of PED approved devices. However, there’s a matrix of PED certification versions and corresponding dates governing their deployment and use. The PCI PED is periodically updated and with each revision, gets a new version number (i.e. PCI PED v 1).

Note – Originally, the PED security standard was created by Visa and approved devices were referred to as “Visa PED Approved Devices.” Later, it was adopted by the PCI Council and named “PCI PED.”

PIN Entry Device (PED) security compliance

We help our POS partners stay current with emerging PCI compliance standards. There are now security requirements that apply to devices that accept personal identification number (PIN)-based transactions. As with other security standards, the PCI Security Standards Council is responsible for managing PED security requirements. The current version of the PED standard is PCI PED v2.

Summary

  • PED devices sold prior to 2004 are “Non-Approved,” meaning minimal testing and certification was performed. They must be removed from service by the “sunset date” of July 10, 2010.
  • Devices sold as of 2004 were considered “Visa PED Approved.” Visa PED Approved devices cannot be sold after December 31, 2007. There is currently no sunset date requiring removal from service.
  • Devices sold as of January 1, 2008 must be “PCI PED Approved.”

PCI approvals for PCI evaluated devices will expire six years past the effective date of a subsequent update of security requirements. Since PCI PED v2 went into effect April 1, 2008, PCI PED v1 approved devices will have to recertify before expiration in 2014. There is currently no sunset date requiring removal of expired devices from service.

Complete information is available on the PCI Security Standards Council website.

Watch a video about a merchant card data compromise

Produced by the Retail Solutions Providers Association (RSPA), this video, Payment Card Industry: Security Compliance Are You at Risk? provides a candid, 12-minute look at the facts surrounding PCI compliance and the impacts of card data compromise.

Promote PABP (PA DSS) compliant systems

We help our developer partners promote their PABP-compliant systems to their resellers and merchants. Co-branded new product releases energize sales channels and provide merchants with secure, leading edge payment processing solutions. We provide our channel partners with free, co-branded marketing materials and educational resources to use with merchants.

Testimonial

Mercury's PCI compliance leadership benefits developers and dealers so they can educate their customers.