PCI: Merchant Requirements for PCI-DSS Compliance

Summary

Campus "merchants" are required to comply.

Body

Campus "merchants" are required to comply with the requirements that are set out in the Payment Card Industry - Data Security Standard (PCI-DSS) framework version 4.0. All merchants that utilize electronic payments in some way are subject to regulatory compliance. A vendor that says they are not subject to PCI and facilitates a transaction is not being truthful. All credit card transactions are covered by PCI in some way and trying to wade through it can be difficult. Please contact Accounting Services (715-425-3900) for assistance prior to commencing any work to take electronic payments. You can also visit their website.

Merchant = Any university entity that processes credit cards with any tool, regardless of what technology that tool uses. This includes fully outsourced third-party service providers, secure dial-up or network terminals, computers workstations at staff desks, mobile equipment including smart phones, and future technologies that permit processing financial data.

There will be some vendors who will process (or claim we can process) credit cards without requiring an attestation of compliance. The university's stance is that we will still observe proper credit card security practices in order to meet both the University's and UW-System's PCI policies. Merchants are still required to work with Accounting Services on implementation of any solution before acquiring that solution.

Self-Assessment Questionnaire (SAQ)

The SAQ is a tool that aids in assessing the "security posture" of the merchant that is provided by the PCI-DSS standards council. This includes looking at how staff handle (or do not handle) the card information and the technology that supports the processing of the card. There are several different SAQ formats and each are a sub-set of the largest which is the SAQ D format. Outsourcing to a third party does not abnegate your need to complete a SAQ; there is a SAQ format which is the most abbreviated format for that situation.

Attestation of Compliance (AOC)

The AOC may be a paper document or it may be a website that has to be completed for the processor or gateway that is handling the merchant ID. This attestation asserts that the university (or vendor) has completed the appropriate SAQ and that the hardware or application environment have complied with all of the requirements in the assessment in a truthful and complete manner. Only the university's controller, or designee, is permitted to complete attestation of compliance assertions for university entities. Third party vendors will need to supply attestations of their own in order for us to move forward with their implementation.

Merchant ID = The merchant ID is an industry term for the unique code issued to the merchant for processing their transactions through the financial systems. This is similar to, but very different from, a bank routing and account number used in checking.
Terminal ID = The terminal ID is a designated identification code assigned to a piece of hardware. This is equivalent to the device's unique Serial Number, but is NOT the same.

Approved Vendors

The university must use vendors that are conducting credit card transactions in an approved method. All vendors, regardless of the position their sales or marketing teams try to assert, are required to comply with PCI-DSS. The level and method to meeting compliance will depend on the type of software and the methods about which they reach compliance. Vendors that flat out say they do not have to comply with PCI-DSS are not good partners. Vendors that state they are compliant, but provide little to no documentation to support that claim are also not good partners. Vendors that say that they are not responsible for PCI but are aware that the university must comply are good partners. A partner that takes on all responsibilities and is transparent about PCI behind the scenes is a great partner. There are vendors that will assist the university in working with approved processors or gateways on your behalf by being in-tune with the PCI-DSS world. 

There are two different databases of checking for approved vendors: one that is run by the PCI-DSS Standards Council and another by Visa. It is often difficult to find your vendor in this database as they may be "doing business as" or d/b/a under a parent business name etc. They also might be processing their credit card transactions through another company or process that is not obvious without digging into the product. The presence of a vendor in or not in the database is only a small portion of the overall compliance puzzle; it does not qualify them or disqualify them. Please contact Accounting Services for assistance.

Contractual Language with Vendors

All potential university merchants must deal with the contracting phase of the software or service acquisition in conjunction with the university controller and the Division of Technology Services. The associated article on PCI Contractual Language will provide guidance to the university merchant. Accounting Services, Purchasing Services, and Technology Services must be involved prior to any contracts being signed by any potential merchants.

Goal of PCI-DSS

The goal of the PCI Data Security Standard (PCI DSS) is to protect cardholder data and sensitive authentication data wherever it is processed, stored or transmitted. The security controls and processes required by PCI DSS are vital for protecting all payment card account data, including the PAN – the primary account number printed on the front of a payment card. Merchants, service providers, and other entities involved with payment card processing must never store sensitive authentication data after authorization. This includes the 3- or 4- digit security code printed on the front or back of a card, the data stored on a card’s magnetic stripe or chip (also called “Full Track Data”) – and personal identification numbers (PIN) entered by the cardholder.

PAN = Primary Account Number, the 16 digit number that uniquely identifies the cardholder's account.
CHD = Cardholder Data is any information on the credit card that is considered highly sensitive information. This includes, but is not limited to, the full PAN, exp date, and the CVV code.

At no time will any university merchant permanently store the PAN and associated information. At no time will credit card information be transmitted through email, social media, text messaging or any other unapproved medium. Credit card information may NOT be accepted by telephone, fax, or email.

Polices & Procedures

The merchant is required to have several policies and procedures in place. This applies to all merchants regardless to what level of merchant they are identified as being. All merchants will work with the university controller and the Division of Technology Services to ensure they are meeting the compliance requirements for their merchant classification. Each merchant is required to have staff that are credit card security trained and that they are observing daily operating procedures to ensure compliance is maintained. Meanwhile, the university controller and Division of Technology Services will also maintain operations that meet the compliance for all university merchants.

The policies and procedures that are set forth in this article are required of all merchants and subject to change as necessary. Merchants should refer to this article frequently for updates. The policies and procedures required of merchants are in addition to the general information security policies as defined by Administrative Policy AP-05-301.

Details

Details

Article ID: 2818
Created
Fri 11/28/14 10:33 AM
Modified
Mon 5/13/24 2:34 PM

Related Articles

Related Articles (1)

Text that must appear in contracts with vendors relating to services that process credit cards.