2820 PR.01 Payment (Credit & Debit) Card

1. Overview

2. Requesting a New Merchant Number

3. Merchant Types

NOTE: There are additional PCI DSS requirements for Internet-based Merchants.  The use of an Application Program Interface (API), which requires Yale to collect and store credit card data prior to transmission, is not permitted.

C. Cash Register Merchants

A department may decide it best suits their business operations to use a cash register with an internet-connected point of sale (POS) system.  POS systems are subject to stringent PCI DSS requiring a rigorous compliance program, but are also the most robust payment processing systems.  These are primarily used at retail and dining locations around campus.  Departments selecting this method of credit card payment processing will need to perform the following:

• Before entering into a contract with a service provider, the service contract must be reviewed by Yale’s Procurement Department and by Yale PCI Administration.
• The cash registers must be installed by the vendor and its security system must be reviewed by YALE PCI ADMINISTRATION prior to implementation.
• You will also have to comply by Yale PCI Administration standards and complete a Security Planning Assessment (SPA).  This will include providing the IP address of your system and the name of a technical contact.  Information about completing an SPA can be found on the Security Planning Assessment page.
• Contact Yale PCI Administration at information.security@yale.edu.

An example of this type of merchant:

• Your organization has a cash register connected via Ethernet to the internet.  Cashiers log in either by swiping their university ID badge or by entering a user ID and password.  The cashier can then ring up items the customer is purchasing and swipe their credit card.  Then the register prints a receipt for the customer.

The credit card associations (American Express, MasterCard, Visa and Discover) have established the Payment Card Industry Data Security Standard (PCI-DSS) for all merchants.  Compliance with these standards increases consumer confidence, reduces fraud and identity theft, and ensures that the University can continue to accept credit card payments.  

All merchants that process credit cards at Yale are required to complete or assist with the completion of the PCI-DSS Self-Assessment Questionnaire (SAQ) on an annual basis and maintain an accurate asset inventory.

Depending on a department’s credit card processing method, different security standards apply, and therefore different SAQ’s must be completed, as follows:  

• SAQ-A: An SAQ A applies when no cardholder data is maintained by the University and all payment processing is outsourced.  The third-party provider must be PCI-DSS compliant.
• SAQ-A-EP: E-commerce merchants who outsource all payment processing to PCI-DSS validated third parties, and who have a website (s) that doesn’t directly receive cardholder data but that can impact the security of the payment transaction. No electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises. Applicable only to e-commerce channels.
• SAQ-B: An SAQ-B applies to those merchants that use a standalone dial-out terminal (phone line) to process credit cards.  These are not connected to a computer, only to a dedicated phone line.
• SAQ-B-IP: An SAQ B-IP applies to merchants using only standalone, PTS-approved payments terminals with IP connection to payment processor, with no electronic cardholder data storage.  This is NOT allowed at Yale.
• SAQ-C: An SAQ-C applies to those merchants transmitting credit card information over the internet through either a POS payment system or a computer.  There must still be no on-site storage of credit card information, but this can be done with an off-site vendor.
• SAQ-C-VT: SAQ- C-VT merchants who manually enter a single transaction at a time via a keyboard into an internet-based virtual terminal solution that is provide and hosted by a PCI-DSS validated third-party service provider.  Terminal only processes payments.   No electronic cardholder data storage.
• SAQ-D: An SAQ-D applies to those merchants that store cardholder data on-site in a secured database.  This is NOT allowed at Yale.

All payment processing vendors and software used by Yale must also be PCI-DSS compliant.

Yale classifies credit card numbers as High Risk Data.  PCI-DSS data is not allowed to reside on a local computer, laptop, or smart phone.  This High Risk Data is not to be stored in digital format.  Yale’s PCI-DSS compliance is dependent on not storing this data digitally.

• Once a transaction is processed, all systems and documents containing a PAN shall mask the PAN except for the last 4 digits.
• The Federal Fair and Accurate Credit Transactions Act (FACT) prohibits receipts from displaying more than 5 digits of the customer’s card number, no more than 5 digits shall be displayed on any system in use at Yale.  
• The customer copy of the receipt must only display the last four numbers of the customer’s credit card number.
• The merchant copies of credit card receipts must also display only the last 4 digits of the card number and must be stored in a locked file in a secured office.
• Any reports or other documents containing credit card numbers must be secured in the same manner as credit card receipts.  
• When required by policy, credit card numbers shall be redacted from documents using a black permanent marker. 
• Documents containing cardholder data shall be kept only for the minimum period of time required by the underlying business process and/or by legal obligation.  After a period of 7 years, the receipts must be disposed by shredding them.  Merchants must review records (receipts and digital records) at least quarterly to identify and destroy card holder data that no longer needs to be retained.
• When disposing of documents containing cardholder data, the documents shall, at a minimum, be cross-cut shredded prior to disposal.  Alternatively, merchants may securely dispose of documents by placing them in Infoshred bins to which access to the inside of the bin is physically prevented.
• Physical access to offices where Payment Cards are being processed shall be restricted and Payment Card processing devices and cardholder data must be physically secured in a restricted access area, such as a locked office, using a cable lock, or in a locked cabinet.

A. Daily Processing

All credit transactions must be processed promptly and transmitted to the processor daily.  This would be commonly referred to as a payment batch.

B. Reconciliation - Recording of Revenue and Expenses

All credit card transactions and fees will be posted to the General Ledger on a monthly basis by General Accounting.  The department will provide one designated account for all income activity and one account for all fee activity.  The department will be responsible for any Online Journal Entries required to post amounts to other accounts.

C. Departmental Reconciliation

The department will receive a monthly statement of activity from the credit card processor.  This statement must be reconciled to the settlement reports from your machine/software/web site and to the monthly Workday statements. 

Note: There will be a timing difference for the last one or two days of credit card activity each month. Please see Section 11 of this procedure for more detail.

If you need to arrange for the removal of any swipe machines, cash registers, or deactivation of any POS or user accounts, contact Yale PCI Administration.  These devices must be disposed of properly by following Procedure 1610 PR.02 Disposal of Obsolete Computers and Peripherals.   

If the equipment is being swapped or traded, it should immediately be sent to Merchant provider.

If the equipment no longer works or for any reason is being retired, please forward the Terminal ID to the Merchant Provider so they can remove it from their list, disable the machine by cutting the cord, then follow Procedure 1610 PR.02 Disposal of Obsolete Computers and Peripherals.

If your department is a seasonal credit card merchant and the account is only used for part of the year, contact Yale PCI Administration and have the merchant account number shut off when not in use.  Fees are not charged during the months that the credit card merchant account is shut off.  When necessary, contact Yale PCI Administration to reactivate the merchant account number.

For a one-time event, Treasury Services provides a website, to which departments may direct their purchasers/participants.

When using the online process, please email agnes.siniscalchi@yale.edu with the total dollar amount collected, the COA account to be credited, and a COA account for the processing fee.

All cardholder data and other data associated with the processing of payments is classified as High Risk Data within Yale’s data classification system (see, Policy 1604 Data Classification Policy).  All systems used to access, create, store, transmit, or receive cardholder data must meet and maintain all Minimum Security Standards for High Risk Data, as well as all other University policies and procedures related to protecting High Risk Data and systems (e.g., Policy 1607 Information Technology Appropriate Use Policy and Policy 1610 Systems and Network Security).  Additional requirements for securing payment processing-related devices is outlined below.

A. Notification about Device Changes

Departments are responsible for securing credit card data as well as the device(s) that is being used for processing credit card transactions.  Yale PCI Administration shall be notified within 30 days when new devices or payment methods are added or when devices are no longer in use.  Please be ready to provide the make, model, and location of each device.

B. Device Inventory

Department shall maintain a list of devices used in the processing of payment card transactions.  Yale PCI Administration shall maintain a master list of PCI devices on campus.  Physical access to these devices shall be limited, and where appropriate these devices must be physically secured (e.g., via locking devices).

C. Device Tampering

The operator must periodically inspect the device(s) to ensure there is no tempering.  The device and office must be locked and secured after hours or when the device is unattended.

D. How Devices May Be Used

Devices used to process payment card transactions may only be used for processing payments.  General office productivity activities (word processing, email, desktop publishing, etc.) must be conducted on a separate system to maintain the integrity and security of the payment card processing environment.

E. User Names and Passwords (for Computers and Servers)

• A user authentication mechanism is required for access to all payment processing devices using a server or desktop operating system (e.g. Microsoft Windows, Linux, Macintosh OS X, etc.) or mobile operating system (e.g. iOS, Android OS, BlackBerry, etc.).
• Unique login IDs and strong passwords shall be used. Never share login credentials.
• When configuring access for users of systems and devices used in the processing of credit card payments, users shall be configured with the least privileges necessary to perform their job responsibilities.
• Access shall be assigned according to a user’s job classification and function.

F. Firmware and Software Patch Management

Merchants and their IT support providers are responsible for ensuring that applications, system software and device firmware on payment processing devices are kept up-to-date.  Within 30 days of a vendor releasing a (1) firmware update (2) operating system patch, or (3) application patch to address a known critical vulnerability*, a merchant shall ensure that any applicable update or patch has been installed on their production devices.  Other security patches shall be installed within 90 days.

* A critical vulnerability can be identified by analyzing the following:

1. Determine the potential impact of the vulnerability.

The potential impact of a vulnerability is measured based on the impact its exploitation would have to the confidentiality, integrity, or availability of the technology and/or the data.  The potential impact of a vulnerability is high if any of the following are true:

• Its exploitation may lead to the unauthorized disclosure or modification of sensitive data (confidentiality, integrity);
• Its exploitation may result in a significant disruption to the technology (availability).

2. Determine the likelihood that the vulnerability will be exploited.

The likelihood that the vulnerability will be exploited can be determined by answering the following questions:

• Can the vulnerability be exploited without authenticating (“logging in”) to the technology or system?
• Can the vulnerability be exploited across the network?
• Is the vulnerability relatively easy to exploit for skilled attackers?

If the answer to two or more of these questions is “yes,” then the likelihood is high.

3. Determine if there are compensating controls to prevent exploitation.

Consider if there are additional protective measures in place that significantly reduce the ease of exploitation or severely limit the accessibility of the vulnerability to a small number of known systems.

If the impact and likelihood are both high, and there are no significant compensating controls, the vulnerability is critical.

G. Antivirus and Antimalware Protection

Where possible, antivirus and antimalware software shall be installed, kept up-to-date and used to monitor system health.  Regular, scheduled scans shall be conducted at least monthly.  Non-administrative users shall be prevented from disabling antivirus and antimalware software.  Administrative users shall request permission from Yale PCI Administration before disabling this software.

H. Log Management (for Computers and Servers)

Additionally, for servers and computers used in the processing of payments, the following logs shall be reviewed daily (other logs shall be reviewed as appropriate) and retained for at least one (1) year:

• Security event logs;
• Logs for system components that store cardholder data;
• Critical system component logs; and
• Logs for servers and components that perform security functions.

I. Network Security

Cardholder data transmitted outside of the Yale PCI Network (e.g. across the Internet) must be encrypted using strong encryption (TLS 1.2 or later) unless a documented justification from the payment processor or payment solution vendor exists.  Industry best practices shall be used to implement this encryption.

Devices used for payment card processing may only be connected to Yale’s PCI Network and/or wirelessly through Yale Secure.  Use of Yale’s other wired or wireless networks is prohibited.  The Yale Secure wireless network may be used only with pre-authorized Clover devices from Bank of America Merchant Services to process payment transactions.

J. Remote Access to these Devices

When remote access by a vendor is required, this functionality must remain disabled until the vendor requests access for a specific support purpose or through an automated process defined in the contract with the vendor.  Remote access must then be deactivated immediately after the support event is finished. Should a vendor or business partner require remote access, send the request to information.security@yale.edu for approval.

K. Mobile Computing Devices

Only pre-authorized mobile computing devices may be used to process card payments.  Unauthorized mobile devices include smartphones such as iPhones and Android OS devices, Square and Clover Go, etc.

L. Computer Configuration Standards (for devices running a desktop or server operating system)

Computers must meet security requirements as defined by Yale PCI Administration to ensure credit card data is properly secured.  Yale PCI Administration can provide further guidance on appropriate security measures in this area.

The following steps must be taken to ensure secure processing of payments on Yale servers and endpoints:

• Yale’s current, most secure Managed Workstation configuration standard shall be used on endpoints where credit cards are processed unless a platform, software or hardware limitation or a vendor requirement prevents the use of this standard;
• 56.129All vendor/manufacturer default passwords associated with the payment processing environment must be changed;
• Non-console administrative access shall by protected by strong encryption (SSH, VPN, or TLS);
• Strong encryption must be invoked before the administrative password is requested;
• Generic user IDs and accounts are disabled or removed;
• Shared user IDs for system administration activities and other critical functions do not exist;
• Shared and generic user IDs are not used to administer any system components;
• For servers, only one primary function (e.g. the file server or web server roles) shall be implemented per server or virtual system component or device (this prevents functions that require different security levels from co-existing on the same server);
• Any unnecessary services, protocols, daemons, etc. shall be disabled if not required for the system to function;
• Document and justify any instances when an insecure service or protocol (e.g. SSL) is enabled.

M. Sending/Receiving Payment Information Using Email and Text Message is Prohibited

Email shall not be used to send or receive credit card information.  If a card number is received via email, delete the card number after processing the transaction, then delete the email.  

Similarly, end-user messaging technologies such as text messages, instant messaging or chat services shall not be used to transmit or receive credit card information.

Exception for receipts: It is, however, acceptable to provide a receipt via email or text message if the cardholder consents to receive electronic disclosure.  Instances where printing, email or text messaging is not an option, merchants should be prepared to provide a handwritten receipt that conforms to all of the sales receipt requirements.

N. Loss, Theft, or Breach

In the event you believe that cardholder data may have been compromised immediately contact Yale PCI Administration. Compromise includes instances where files with credit card numbers are lost or stolen, electronic losses of data, where devices (servers, endpoints or mobile devices) storing sensitive data may have been compromised by malware or a virus.

A.  Network Security

Yale University Information Technology Services shall maintain a firewall (or firewalls) and maintain an appropriate network (or networks), the Yale PCI Network, to protect devices used in payment card processing.  Any firewall or network used in payment processing shall be configured to the standards outlined in PCI-DSS.  Only devices used in payment processes or in place to maintain the health of these devices and the payment processing network shall be allowed on the Yale PCI Network.  Penetration tests shall be conducted at least quarterly to verify the integrity and effectiveness of this segmentation.  The Yale PCI Network shall be monitored for unauthorized changes.  Strong cryptography and security protocols must be used to transmit sensitive cardholder data.

B.  Remote Access Security for Vendors

Outside vendors requiring access to these devices from outside of the Yale network must use remote access technology with the following restrictions:

• Inactive sessions must be disconnected after a defined period of time,
• Remote access technologies may only be activated when needed and must be deactivated once they are no longer needed (e.g. VPN connections to the Yale network may only be initiated when support is needed or a scheduled data transfer must occur),
• No later than July 1, 2016, all users (administrators, employees processing payments, vendors, support providers, etc.) shall use multi-factor authentication for remote access to devices used for processing Payment Card payments.

C. Network Vulnerability and Penetration Testing Scans

In order to ensure system integrity and ensure PCI-DSS compliance, it is necessary for Yale and its security vendors to conduct regular network scans of devices that process Payment Card payments.  Yale personnel will contact you concerning any findings generated by a scan — do not respond to inquiries coming directly from outside parties.  Merchants shall cooperate with Yale in remediating any vulnerability discovered by a scan.  These scans will be conducted at least quarterly as required by PCI-DSS.

On a monthly basis, the Merchant statement, General Ledger statement, and settlement reports from the Swipe Machine/Software/Website should be reconciled against each other to ensure all transactions have been posted and cleared accordingly.

Note: There will be a timing difference for the last one or two days of credit card activity each month.

Reconciliation Steps: 

• Collect all three statements/reports for the month being reconciled:
  
  • Credit Card/Merchant statement (e.g. Elavon Statement),
  • General Ledger statement (e.g. Online Journal Entry batches posted by General Accounting to the GL),
  • and Swipe Machine/Software/Website report (e.g. Tessitura, etc.).
• Verify that the batches from each report are reflected and can be tied out to one another.
  
  • Recommended to Match the Swipe Machine/Software/Website (i.e.Tessitura) transactions to the Credit Card/Merchant statement and then reconcile to GL.
  • Note: The batch totals on the Credit Card/Merchant statement may be totals of more than one batch from the Swipe Machine/Software/Website & GL reports. 
• Once all possible transactions can be reconciled and there are batches that cannot be matched on a one-to-one basis, including the cash/check transactions; verify that the total for the current month (excluding timing differences) can be tied out.
• Annotate any discrepancies or variances on the reports, research and resolve as needed.
• Attach all supporting documentation, group materials, and file in department Business Office.
• Retain all documentation as noted in the University’s Record Retention Policy, Policy 1105.