UH System Policies and Procedures
- Board of Regents Policies
- Executive Policies
- + 1. General Provisions
- + 2. Administration
- + 3. Organization
- + 4. Planning
- + 5. Academic Affairs
- + 6. Tuition, Financial Assistance, and Fees
- + 7. Student Affairs
- + 8. Business and Finance
- + 9. Personnel
- + 10. Land and Physical Facilities
- + 11. Miscellaneous
- + 12. Research
- Abolished Procedures (Post Oct. 2014)
- Archived AP
UH‐Related Laws and Rules
- Hawaiʻi Revised Statutes (HRS) 304A
- Hawaiʻi Administrative Rules (HAR) Title 20
Administrative Procedure 8.710 Administrative Procedure 8.710
Credit Card Program
Administrative Procedure Chapter 8, Business and Finance
Administrative Procedure AP 8.710, Credit Card Program
Effective Date: January 2020
Prior Dates Amended: June 1992, July 2001, April 2005, March 2015
Responsible Office: Office of the Vice President for Budget and Finance/Chief Financial Officer
Governing Board and/or Executive Policy: EP 1.102, Authority to Manage and Control the Operations of the Campus
Review Date: January 2022
This policy applies to credit card payments processed by the University designated as the merchant of record. The purpose of this policy is to outline the responsibilities of departments that accept credit card payments and to provide procedures for these departments to follow.
To safeguard the University’s information technology resources and to protect the confidentiality of cardholder data, adequate security measures must be taken. Credit card data stored, processed, or transmitted by the University merchant accounts must be protected and must conform to the Payment Card Industry Data Security Standard (PCI DSS).
The University requires that all departments that accept credit card payments comply with applicable PCI DSS requirements and related University policies and procedures.
Departments that fail to comply with PCI DSS and University policies and procedures may have their ability to accept credit cards suspended or revoked. In addition, they may face penalties, fines, or restrictions.
Portions © 2019 Security Metrics, Inc. All Rights Reserved. Used by permission.
A. Contractor – The vendor contracted by the University to provide merchant processing services, including authorization, processing, settlement and reporting of credit and debit card transactions. The Contractor also provides equipment, software, training and support necessary to process these transactions.
B. Merchant Department – A University department that is approved to accept credit cards as a form of payment. It is also referenced as the Merchant in this Administrative Procedure.
C. Merchant Account Contact – A regular, full-time employee that has been designated as the primary contact of the merchant and who coordinates the merchant’s compliance with PCI DSS and related University policies and procedures. The Merchant Account Contact shall be appointed by the Dean/Director or Department Head of the unit.
D. Merchant Fee – The service fee paid to the contractor by the Merchant based on the terms of the University’s merchant contract.
E. Merchant Identification Number (MID) - A unique identification number established and issued by the contractor that identifies the department as a merchant.
F. Merchant Information Technology (IT) Contact – The department’s designated IT staff member that works with the Merchant Account Contact on implementing required safeguards related to the merchant’s technical PCI DSS requirements.
G. Payment Card – For purposes of PCI DSS, payment cards includes any credit, debit or prepaid cards used in financial transactions that bear the logo of the five major card associations (Visa, MasterCard, American Express, Discover and JCB). In this Administrative Procedure, the term credit card may be used in lieu of Payment Card.
H. Payment Card Industry (PCI) – Includes Payment Card brands, issuing and acquiring banks, independent sales organizations, service providers and merchants who accept Payment Cards.
I. PCI Security Standards Council (SSC) – A council comprised of the five major card associations including, Visa, MasterCard, American Express, Discover and JCB International. The council is responsible for the development, management, education and awareness of the PCI DSS.
J. PCI DSS – A set of twelve technical and operational requirements set by the PCI SSC to protect cardholder data and reduce credit card fraud. These standards apply to all entities that store, process or transmit cardholder data. The Merchant Department is required to meet the applicable requirements for their payment processing method/merchant environment.
K. Payment Processing Method – How a credit card transaction is processed, which includes:
1. In-Person/Card Present – in person transactions where the cardholder presents their credit card to
make a payment.
2. eCommerce – a non-face-to-face, on-line transaction using electronic media over a public or private
network. Refers to all forms of business activities conducted over computer networks such as the
3. Mail order/telephone order (MOTO) – cardholder data is provided to the merchant by the cardholder
via mail, facsimile or through the phone. Credit card information sent via other electronic methods
(e.g. email, text, etc.) is prohibited.
L. Third-Party Payment Processing Service Provider – A third-party that provides connectivity among merchants, customers and financial networks to process authorization and payments and securely stores Payment Card data. The provider must be a PCI DSS validated third-party.
M. Self-Assessment Questionnaire (SAQ) – An annual self-assessment and attestation intended to demonstrate compliance with PCI DSS.
Portions © 2019 Security Metrics, Inc. All Rights Reserved. Used by permission.
III. Administrative Procedure
A. Roles and Responsibilities
1. Treasury Office
a. Establish and document policies and procedures related to University’s credit card program.
b. Establish merchant accounts. This includes approval or disapproval of requests to participate in
the credit card program, including requests to use a third party payment processing service.
c. Create the Credit Card Vendor Number in the University’s financial system.
d. Close merchant accounts.
e. Establish and maintain relationships with Contractor and other entities related to credit card
f. Coordinate review for new merchant requests and modifications to existing merchant set up and
collaborate with Information and Technology Services (ITS), as needed, for review of network
segmentation configuration and other technical safeguards.
g. Coordinate University PCI compliance process, including coordinating training and distribution of
information notifications to University merchant personnel.
h. Submit University’s consolidated SAQ on an annual basis, based on information received from the
Merchant Account Contacts and in accordance with terms of the merchant service contract.
2. Merchant Department
a. Protect credit card data by complying with security requirements and safeguard of cardholder data
as set forth by the PCI DSS. Failure to comply may increase the University’s exposure to increased
b. Comply with University policies and procedures and with terms of the University’s contract for
credit card processing.
c. Comply with any Merchant Department specific procedures.
d. Fiscal Staff
(1) Make timely payment of all merchant fees, rental costs of equipment or software, dedicated
analog lines and data costs.
(2) Respond to chargeback notices in timely manner.
e. Dean/Director or Department Head
(1) Appoint Merchant Account Contact.
(2) Understand responsibilities with compliance related to accepting credit card payments for the
Campus/School or department.
(3) Accept responsibility for any fines, fees, or penalties assessed for data breaches due to
merchant’s non-compliance of PCI DSS requirements.
(4) Ensure Merchant Account Contact is completing the required documentation.
f. Merchant Account Contact
(1) Notify the Treasury Office by completing and submitting the Credit Card Program – Participation
and Change Request Form (Appendix B) for establishment of a new MID and for any changes to
the existing merchant environment (changes to contact information, payment processing
method, payment processing device, third party service provider, etc.) prior to implementing
(2) Coordinate with department and information technology (IT) staff as needed for PCI DSS
compliance program process.
(3) Compile and maintain merchant documentation, as required.
(4) Complete the PCI DSS Checklist review, as applicable.
(5) On an annual basis, complete the applicable merchant SAQ and submit as requested to the UH
Treasury Office by due dates established. Failure to submit the SAQ will cause the University to
be out of compliance.
(6) Leads Merchant Department incident response and remediation procedures for merchant’s
unit, to include but not limited to, reporting incidents to the UH Chief Information Security
Officer (CISO) & Incident Response Team (IRT) and conduct incident handling and remediation
as directed by CISO and IRT.
(7) Coordinate PCI DSS security activities, to include but not limited to information and physical
g. Merchant IT Support Staff/Department
(1) Supports and implements PCI DSS process, to include but not limited to internal vulnerability
scanning, developing and maintaining secure systems and applications, protection of systems
(e.g. anti-virus), and maintaining properly configured firewalls in consultation with ITS
Information Security Team as necessary.
(2) Support Merchant for IT security-related incident response and remediation.
3. ITS Information Security Team
a. Collaborate with UH Treasury Office on technical requirements and coordinates policies and
procedures related to the University’s PCI DSS security.
b. Assist UH Treasury Office with reviews of merchant departments SAQs and overall submission of
c. Assist merchant departments with PCI DSS technical training, technical guidance, and compliance
d. As part of the IRT, direct and coordinate technical investigation for security-related incidents.
e. Provide technical guidance to merchant as needed.
B. Procedure to Participate in Payment Card Program
1. Merchant Account Contact submits a Credit Card Program – Participation and Change Request Form
to the UH Treasury Officer. Among other information, the request shall include the following:
a. The justification for participating in the Payment Card program;
b. The legal authority that permits the campus/department to collect and deposit receipts (Consult
with FMO Tax Services for review of any Unrelated Business Income Tax considerations, as
c. For eCommerce payment processing:
(1) The University has implemented a third party (TouchNet Information Systems, Inc. (TouchNet))
secure, PCI DSS compliant, hosted eCommerce management system that supports payment
processing for a variety of eCommerce applications. Merchant departments shall use the
designated eCommerce system, unless an exception is granted.
(a) Exceptions may be granted if:
(i) TouchNet cannot meet the business needs of the merchant.
(ii) The alternate system is in compliance with PCI DSS.
(iii) The alternate system must be able to process credit card transactions utilizing the
Contractor’s processor (i.e. FISERV (FKA First Data)).
(iv) The information about the proposed alternate system must be included on the Credit
Card Program – Participation and Change Request Form.
(b) Departments granted an exception to use an alternate system will be responsible for any
costs to operate and maintain the system.
(c) Departments granted such exceptions also assume all responsibility and liability for the
security of all transactions and data, including any monetary loss suffered by the University
due to theft or improper use of credit card numbers and data breach remediation costs from
failure to comply with PCI DSS.
(2) The Credit Card Program – Participation and Change Request Form must be signed by the
Merchant Account Contact, merchant department IT contact, fiscal administrator, and
Dean/Director or Department Head.
(3) Once approved, the Treasury Office will submit the request to the Contractor for MID
(4) Contractor will provide MID once application is approved.
(5) Departments are prohibited from contracting directly for credit card services from the
Contractor or any other entity.
C. Receipting, Recording and Reconciling
1. Refer to Administrative Procedure 8.701, Receipting and Depositing Funds Received by the University,
Section III.E. for procedures on receipting, recording and reconciling credit card transactions.
D. Responding to Dispute Notifications
1. Should a cardholder dispute a credit card transaction, a dispute notice will be provided to the
merchant’s fiscal administrator.
2. A response must be submitted by the merchant for all dispute notifications to the processor as
directed on the chargeback notice.
3. The merchant will receive an invoice from the Contractor for the chargeback amount, regardless of
the outcome of the dispute decision. The merchant shall promptly process payment to the
4. Should the dispute be decided in favor of the University and the chargeback reversed, the UH
Treasury Office will notify the merchant contact and the merchant will record the receipt of the funds
in the University’s financial system.
E. Procedures to Withdraw from the Credit Card Program
1. Submit the Credit Card Program – Participation and Change Request Form (mark as “Request to
Close”) with applicable signatures and explanation of reason to withdraw from the program to the UH
2. Upon approval, the UH Treasury Office shall coordinate the closing procedures with merchant
department and Contractor.
3. Any equipment obtained from the Contractor must be promptly returned.
F. University PCI DSS Compliance Process
a. The PCI SSC set forth PCI DSS, a set of twelve technical and operational requirements to protect
cardholder data and reduce credit card fraud.
b. The PCI DSS requirements apply to all organizations that store, process or transmit credit card
data, thus, as such an organization, the University is required to comply with PCI DSS.
c. Each University Merchant is required to comply with University policies and procedures and the
applicable PCI DSS requirements based on their payment processing method/merchant
d. University policies and procedures and PCI DSS requirements apply to all University Merchant
personnel involved with University merchant operations that could affect the security of cardholder
2. The SAQ is an annual PCI-mandated attestation intended to demonstrate compliance with PCI DSS.
Depending on the payment processing method/ merchant environment, a specific set of PCI DSS
requirements are applicable and are detailed in the applicable SAQ. Failure to meet the PCI DSS
requirements may increase exposure to fraudulent activity. In addition, failure of the Merchant
Account Contact to submit the SAQ on an annual basis will cause the University to be out of
Descriptions for each SAQ type are provided below:
SAQ Type Description
A Card not present (eCommerce) merchants that have fully outsourced all cardholder data
functions to PCI DSS compliant third-party service providers with no electronic storage,
processing, or transmission of any cardholder data on the merchant’s systems or premise.
This SAQ is applicable for the University merchants utilizing TouchNet.
A-EP eCommerce merchant who outsources all payment processing to a PCI DSS validated third
party, but whose website may impact the security of the payment transaction. No
electronic storage, processing or transmission of cardholder data on merchant’s systems or
B Card-present merchant that uses a standalone dial-out terminal (analog or cellular phone
line) to process credit cards or imprint machines; no electronic cardholder data storage.
B-IP Merchants using only standalone, PIN Transaction Security (PTS) approved payment
terminals with an Internet Protocol (IP) connection to the payment processor with no
electronic cardholder data storage.
C Merchants with payment application systems connected to the Internet, no electronic
cardholder data storage.
C-VT Merchants that manually enter a single transaction at a time via keyboard into an internet-
based virtual terminal solution that is provided and hosted by a PCI-DSS validated third-
party service provided. The terminal used shall only process payments. No electronic
cardholder data storage.
P2PE Merchants using only hardware payment terminals included in and managed via a
validated, PCI SSC-listed Point-to-Point Encryption (P2PE) solution (the P2PE solution must
be listed at: https://www.pcisecuritystandards.org/assessors_and_solutions
/point_to_point_encryption_solutions) with no electronic cardholder data storage.
D All merchants not included in descriptions for the above SAQ types. Applies to merchants
that electronically store cardholder data. Electronic storage of cardholder data is not
allowed at the University.
3. PCI DSS Requirements
a. PCI DSS is comprised of 6 primary goals with 12 requirements. These goals and requirements were
designed to ensure safe-handling of sensitive information related to credit card transactions. The
goals and requirements are listed below. To see the complete PCI DSS requirements and additional
information on PCI DSS, see the PCI SSC website at: https://www.pcisecuritystandards.org/
Goal - Build and Maintain a Secure Network and Systems
b. Requirement #1 – Install and maintain a firewall configuration to protect cardholder data
Firewalls are devices that control computer traffic allowed between the University’s networks
(internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas
within an entity’s internal trusted networks. The cardholder data environment is an example of a
more sensitive area within an entity’s trusted network. A firewall examines all network traffic and
blocks those transmissions that do not meet the University’s specified security criteria.
All systems must be protected from unauthorized access from untrusted networks, whether
entering the system via the Internet as e-commerce, employee Internet access through desktop
browsers, employee e-mail access, dedicated connections such as business-to-business
connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and
from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key
protection mechanism for any computer network.
Other system components may provide firewall functionality, as long as they meet the minimum
requirements for firewalls as defined in this requirement. Where other system components are
used within the cardholder data environment to provide firewall functionality, these devices must
be included within the scope and assessment of requirement 1.
c. Requirement # 2- Do not use vendor-supplied defaults for system passwords and other security
System components used in sensitive networks often will come with default vendor settings
(usernames, passwords, configuration settings, etc.). Vendor-supplied defaults for system
passwords and other security parameters must be changed before systems are installed in the
secure network environment (cardholder data network).
Individuals with malicious intent (external and internal to an entity) often use vendor default
passwords and other vendor default settings to compromise systems. These passwords and
settings are well known by hacker communities and are easily determined via public information.
Goal - Protect Cardholder Data
d. Requirement #3 – Protect cardholder data
Cardholder data is defined as:
• Primary Account Number (PAN)
• Card Validation Code (CVV, CVV2, and CVC2)
• Credit Card Personal Identification Number (PIN)
• Any form of magnetic stripe data from the card (Track 1, Track 2)
Cardholder data must be protected when stored or in transit over public (or untrusted) networks.
Strong industry standard encryption methodologies must be used to protect data stored on hard
drives, removable media, backups, etc.
Protection methods such as encryption, truncation, masking, and hashing are critical components of
cardholder data protection. If an intruder circumvents other network security controls and gains
access to encrypted data, without the proper cryptographic keys, the sensitive data is unreadable and
unusable to that person.
e. Requirement #4 – Encrypt transmission of cardholder data across open, public networks
Cardholder data must be encrypted during transmission over networks that are easily accessed by
malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and
authentication protocols continue to be targets of malicious individuals who exploit these
vulnerabilities to gain privileged access to cardholder data environments.
Goal - Maintain a Vulnerability Program
f. Requirement #5 – Protect all systems against malware and regularly update anti-virus software or
System components within the cardholder data network must be part of an active vulnerability
maintenance program. This program will control the existence of malicious software (e.g., anti-
virus software) and provide policies covering development efforts and system or software
updates/upgrades such that security is maintained.
Malicious software, commonly referred to as “malware”—including viruses, worms, and Trojans
—enters a sensitive network segment during many business approved activities, including
employees’ e-mail and use of the Internet, mobile computers, and storage devices, resulting in the
exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly
affected by malware to protect systems from current and evolving malicious software threats.
g. Requirement #6 – Develop and maintain secure systems and applications
Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of
these vulnerabilities are fixed by vendor-provided security patches, which must be installed by the
entities that manage the systems. All systems must have all appropriate software patches to
protect against the exploitation and compromise of cardholder data by malicious individuals and
Note: Appropriate software patches are those patches that have been evaluated and tested
sufficiently to determine that the patches do not conflict with existing security configurations.
Goal - Implement Strong Access Control Measures
h. Requirement #7 – Restrict access to cardholder data by business need to know
Access to system components and software within the cardholder data network must be controlled
and restricted to those with a business need for that access. This is achieved using active access
control systems, strong controls on user and password management, and restricting physical
access to critical or sensitive components and software to individuals with a “need to know.”
Systems and processes must be in place to limit access to critical data and systems based on an
individual’s need to know and according to job responsibilities.
Need to know is when access rights are granted to the least amount of data and privileges needed
to perform a job.
i. Requirement #8 - Identify and authenticate access to system components
It is critical to assign a unique identification (ID) to each person with access to critical systems or
software. This ensures that each individual is uniquely accountable for his or her actions. When
such accountability is in place, actions taken on critical data and systems are performed by, and can
be traced to, known and authorized users.
j. Requirement #9 – Restrict physical access to cardholder data
Any physical access to data or systems that house cardholder data provide the opportunity for
individuals to access devices or data and to remove systems or hardcopies, and should be
Goal - Regularly Monitor and Test Networks
k. Requirement #10 – Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or
minimizing the impact of a data compromise. The presence of logs in all environments allows
thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of
a compromise is very difficult without system activity logs. Detailed monitoring procedures should
be developed and documented.
l. Requirement #11 – Regularly test security systems and processes
Vulnerabilities are continually being discovered in current, and introduced by new software. System
components, processes, and custom software must be tested frequently to ensure security controls
continue to reflect a changing environment. Detailed testing procedure should be developed and
Goal - Maintain an Information Security Policy
m. Requirement #12 – Maintain a policy that addresses information security for all personnel
Consistent policies and procedures are required to be practiced and followed at all times.
All employees should be aware of the sensitivity of data and their responsibilities for protecting it.
The University’s information security policy and procedures apply to all employees (full-time, part-
time, casual hires, student employees) and others (i.e. volunteers) that work within the University’s
cardholder data environment.
Refer to Appendix C for University’s PCI Incident Response Plan Guidelines.
4. Applicable University Policies
a. The Information Security Governance Leadership Group ensures that all information security
policies, procedures and other initiatives are implemented and maintained within their authorities.
b. University policies related to Information Security are available at https://www.hawaii.edu/infosec
/policies/ and include the following, but are not limited to:
(1) EP 2.210 – Use and Management of Information Technology Resources Policy
(2) EP 2.214 – Institutional Data Classification Categories and Information Security Guidelines
(a) Credit card information is categorized as “Regulated.” This means that inadvertent
disclosures or inappropriate access requires breach notification in accordance with HRS
§487N and is subject to financial fines.
(b) Refer to General Information Security Practices, and Technical Guidelines Table for
Regulated data at: https://www.hawaii.edu/infosec/techguidelines/#regTable
(3) EP 2.215 – UH Institutional Data Governance Policy
(4) EP 8.200 – Policy on Contracts and Signing Authority
(5) AP 2.215 – Mandatory Training and Continued Education Requirements for Data Users
(a) All personnel that handle cardholder data are required to meet requirements of AP 2.215,
(i) Submission of General Confidentiality Notice (GCN)
(ii) Completion of Information Security Awareness Training (ISAT)
(6) AP 8.450 – Records Management Guidelines and Procedures
c. External standards and regulations include:
(1) HRS 487N – Security Breach of Personal Information (https://www.capitol.hawaii.gov/hrscurrent
(2) PCI DSS – Payment Card Industry Data Security Standard https://www.pcisecuritystandards.org
d. The University’s policies and procedures related to the University’s PCI DSS compliance process is
reviewed at least annually. Merchant departments that establish supplemental procedures for
their departments should annually review their procedures to reflect changes to business
objectives or risk environment.
5. Merchant PCI DSS Compliance Process
a. The Merchant must determine the applicable SAQ type required for the MID based on the payment
processing method/merchant environment as described in the table above. Whenever there is a
change in the merchant’s processing method or environment the Merchant Account Contact must
complete the Credit Card Program – Participation and Change Request Form before any change is
implemented, and the merchant’s SAQ type should be re-evaluated. The SAQ type will govern the
PCI DSS requirements applicable to the Merchant.
b. At mid-year, or whenever there is a change in the Merchant’s processing method or environment,
the Merchant Account Contact should complete the applicable SAQ checklist, as provided by the UH
Treasury Office, to determine compliance with PCI DSS and University requirements.
c. To provide Merchant Departments with assistance on technical requirements, refer to the UH ITS
PCI Technical Guidelines document (Appendix A).
d. The Merchant Account Contact shall compile and maintain all required PCI DSS documentation for
the merchant. The SAQ checklist provides information on supporting documentation that should
be maintained and references to templates available. The Merchant should identify and maintain
additional documentation to support the applicable PCI DSS requirement compliance efforts.
e. All merchants must be compliant with PCI DSS. Any non-complying requirements identified must
be remediated or brought to the attention of the UH Treasury Office for assistance in resolution.
f. The UH Treasury Office will send out a request for completion and submission of the annual SAQ
and attestation. The checklist and required documentation serve as back-up documentation for
completion and support of the preparation of the merchant’s annual SAQ and attestation of
compliance. The Merchant Account Contact shall submit the SAQ and any other required
documents by the due date established by the UH Treasury Office.
g. The Treasury Office and/or ITS Information Security may request information to review and validate
responses to the mid-year checklist and/or annual SAQ. Required PCI DSS documents should be
maintained and may be requested in this validation process.
6. University SAQ Process
a. On an annual basis, the Treasury Office is required to submit a SAQ on behalf of the entire
University to its Contractor.
b. The University’s SAQ is based on the individual SAQ submissions by merchant departments. The
Treasury Office will review the merchant prepared SAQs in consultation with ITS for technical
requirements, as necessary.
c. The University is required to be in compliance with PCI DSS, therefore, all merchants must be in
Portions © 2019 Security Metrics, Inc. All Rights Reserved. Used by permission.
IV. Delegation of Authority
There is no administrative specific delegation of authority.
V. Contact Information
Treasury Office, 956-7638, or email@example.com
PCI Security Standards Council: https://www.pcisecuritystandards.org/pci_security/
PCI DSS validated payment applications: https://www.pcisecuritystandards.org/assessors_and_solutions/payment_applications?agree=true.
Visa Global Registry of Service Providers:
General Information Security Practices, and Technical Guidelines Table for Regulated data: https://www.hawaii.edu/infosec/techguidelines/#regTable
VII. Exhibits and Appendices
Appendix A – UH PCI Technical Guidelines
Appendix B - Credit Card Program – Participation and Change Request Form
Appendix C – UH PCI Incident Response Plan Guidelines
Vice President for Budget and Finance/Chief Financial Officer
January 31, 2020
Topicscredit card payments; merchants; payment processing methods; PCI DSS