404.A Open an Internet Storefront Merchant Account Procedure

Open an Internet Storefront Merchant Account Procedure

Open an Internet Storefront Merchant Account Procedure
Procedure # 404.A
Rev.: 2.12.20
Effective Date: January 1, 2020

Related Policy: 404 Credit Card Merchant Services and PCI Compliance Policy 
Functional Owner: Cash Management, Business Services
Contact: PCI Mailbox: pci-help@bussvc.wisc.edu


Contents

I. Procedure Statement
II. Who is Affected by this Procedure
III. Procedure
IV. Definitions
V. Related References
VI. Revisions


I. Procedure Statement

The University of Wisconsin-Madison can accept payment cards from customers to pay for goods and services. An Internet storefront is a method of accepting e-commerce payment transactions via a website.


II. Who is affected by this Procedure

This procedure applies to all UW-Madison departments that accept payment cards online. This procedure should be understood by all Divisional Business Representatives (DBRs), Site Managers, and Operators of the merchant accounts.


III. Procedure

Below are the steps for opening an internet storefront merchant account:

  1. Complete and submit the Card Merchant ID Request Form found HERE.
    1. The DBR must approve the new merchant account.
      1. The DBR will receive an email upon completion of the Card Merchant ID Request Form. The DBR should then sign into the portal to approve the request.
    2. The DBR should determine which card brands the new merchant will accept.
      1. The standard set up for a new merchant account includes MasterCard, Visa, and Discover. Should the department decide to choose to accept American Express cards, an additional reconciliation and an additional connection is required.
  1. Cash Management will review the submitted Card Merchant ID Request Form and contact the Site Manager to facilitate setting up CASHNet and Merchant Connect.
    1. Each person that will log into CASHNet and Merchant Connect must have a unique operator ID.
    2. The department should provide a logo for the checkout page.
  1. The PCI Site Manager must establish card handling procedures and a contingency plan for processing transactions should the primary system be unavailable. An example of department business policies and procedures can be found HERE Once complete, these policies and procedures shall be submitted to Cash Management via e-mail (pci-help@bussvc.wisc.edu).
  1. The PCI Compliance Assistance Team and Elavon will review the website that is being used and ensure that it directs customers to CASHNet for payment. The hosting location must be determined and approved before the Merchant ID (MID) goes into production.
  1. Cash Management will schedule a PCI site visit with the Site Manager once a MID is assigned by Elavon. During the PCI site visit, Cash Management will review the department business policies and procedures and assist with completing the Self-Assessment Questionnaire (SAQ).
  1. Cash Management, or a specific DoIT staff, will activate the MID within CASHNet after the PCI site visit. Once the MID is in production in CASHNet, the storefront website may be used by customers.

IV. Merchant Account Fees

Any fees associated with the acceptance of payment cards in a campus department will be charged to the related merchant on a monthly basis. These fees can be seen in WISER/WISDM once they have been posted. Expenses may include a monthly account maintenance fee of $5.00, Elavon processing fees of approximately 2% of each transaction, and $7.50 for chargeback fees. American Express charges a fee of 2.1% of each transaction.


V. Definitions

Campus Merchant Department – Manage the daily operations of the merchant account(s) and maintain PCI compliance.

CASHNet – A third-party, e-commerce service provider contracted by the University of Wisconsin that is used to process credit card payments.

Divisional Business Representative (DBR) – An individual within the dean or divisional office. This individual has the highest level of PCI responsibility including approving the initial merchant account request and annually reviewing the SAQ as the executive officer.

Merchant Connect (MCP) – An online tool from Elavon, the credit card processor, which displays transaction activity and monthly statements.

Site Manager – This individual is the point of contact for the campus department merchant account(s) and should have influence to establish procedures for the day-to-day handling of payment cards to ensure compliance.


VI. Related References

801 Records Retention Schedule Policy

This Policy covers all types of fiscal records. This includes general financial administration records, gift and grant administration, payments and receipts, state banking and cash management, general ledger, capital improvement and projects, internal controls, and collection.

UW-Madison Administrative Policy
Policy # 801

Effective Date: 09/24/2015
Last Updated: 09/24/2015

Policy Contact: 


Statement of Policy

This Policy covers all types of fiscal records. This includes general financial administration records, gift and grant administration, payments and receipts, state banking and cash management, general ledger, capital improvement and projects, internal controls, and collection.

Background to the Retention Schedule

In early 2006, the PRB approved a General Records Schedule (GRS) governing fiscal records for State agencies. In the course of reviewing the applicability of the GRS for University use, it became apparent it did not meet University needs; and the terminology of the State GRS made it difficult to interpret it within the University System accounting system. Thus, the decision was made that the UW System would opt out of the State GRS, and it would create its own retention policy for fiscal and accounting records or UWS GRS.  In November 2006, a team was created from the newly formed UW System Records Officer Council along with Doug Hendrix, UW System Associate Vice President Financial Services, and Laura Dunek, UW System Records Officer to develop a draft GRS.

On January 31, 2007, the Public Records Board (PRB) approved the University of Wisconsin System General Records Schedule (UWS GRS) on Fiscal and Accounting Records.

What is covered by the new GRS?

The new UWS GRS provides retention policy on nearly all types of fiscal records. This includes coverage for general financial administration records, gift and grant administration, payments and receipts, state banking and cash management, general ledger, capital improvement and projects, internal controls, and collection.

ONE CAUTION: Items relating to credit card documentation (UWS GRS) are still being reviewed and at this time there is no recommendation for length of time for record retention. There were concerns expressed by the Attorney General Representative (AG) to the PRB in which the recommended retention for credit card documentation may not be sufficient; therefore, the retention for those items should NOT be implemented at this time.

What does this mean for your department?

You should feel free to implement the retention times specified in the UWS GRS. It is not necessary to seek further approval from Business Services. Exceptions from UWS GRS are the same exceptions from previous retention policies. Records scheduled for disposal which are subject to open audit questions or investigations, legal investigations, or open records requests MAY NOT be destroyed. Scheduled disposal must be suspended in those instances.  With electronic recordkeeping, it is critical that accounting services and departments have the capability to suspend destruction/deletion. A REMINDER: Changing a record format or its storage media does not change its status as a record or the need to retain it an appropriate length of time.

How do I know if I am responsible for implementing and maintaining this policy for Record Retentions?

Are you the official record holder of the particular record item or record series? If so, your office has primary responsibility for implementing the retention time.

Responsibility for being the official record holder are outlined in the following website:
http://www.library.wisc.edu/archives/records-management/retention-disposition/

Acronyms per Record Retention Schedule:

  • EVT – means the event which closes the records. For fiscal records, this is normally the end of the fiscal year.
  • FISC – means fiscal year.

What is still needed to fully implement the GRS?

Further guidance will be developed on credit card retention, management of copies, supporting accounting systems maintained by individual departments, and the interpretation of certain records within the Shared Financial System. As these items are developed, notices and articles will be posted in Business Services News and on the ARMS website – http://archives.library.wisc.edu/RM/rechome.htm.

Where can the new UWS GRS be obtained?

http://www.library.wisc.edu/archives/records-management/retention-disposition/general-records-schedules/

Acronyms per Record Retention Website:

  • AG – Attorney General Representative
  • UW-Madison Records Management assists campus offices determine what records need to be kept and for how long.
  • GRS – General Records Schedule – schedule used as guidelines for length of time to save fiscal records
  • PRB – Public Records Board – body responsible for the State’s records policies
  • UWS GRS – University of Wisconsin System General Records Schedule

Who should know this policy?

Deans, Directors, and staff dealing with fiscal and accounting records.

704 Non-Sponsored Projects Policy

A non-Sponsored project is a project that is funded by an internal entity such as a state agency, UW institution or another UW-Madison department which doesn’t have billing or reporting requirements. Examples include an internal project, a state project, a trust fund project or a gift project.

UW-Madison Administrative Policy
Policy # 704

Effective Date: April 29, 2010
Last Updated: August 9, 2010

Policy Contact:


Statement of Policy

A non-sponsored project is a project that is funded by an internal entity such as a state agency, UW institution or another UW-Madison department which doesn’t have billing or reporting requirements. Examples include an internal project, a state project, a trust fund project or a gift project. Non-sponsored projects are set-up, maintained, monitored, and closed-out using Project Lite software, a “slimmed down” version of the PeopleSoft Project Costing Module (part of the UW-Madison Grants Module). WISDM is used to access information entered into Project Lite.

  1. Non-sponsored projects:
    • Could have a source of funds from an internal entity such as State, institutional or departmental
    • May be funded by multiple sources
    • Generally do not have billing or reporting requirements
    • May have “effort” reporting requirements depending on the funding source
    • Generally do not have F & A (Facilities & Administration) overhead costs charged
    • Generally do not have conditions attached
    • Time period may extend beyond a fiscal year, but also could be for a shorter period of time
    • Generally do include gift projects
    • Use funds 136 (General Operations Receipts), 161 (Trust Funds), 233 (Gifts), and various other funds
    • Examples of a non-sponsored project could be an internal project, a State project, a Trust Fund project or a gift project
  2. Non–sponsored projects generally use a Project ID format for reporting and monitoring purposes. A Project ID:
    • Represents a type of program activity, event, special event or project within a fund that must be monitored and reported independently from the organization
    • Has a beginning date and generally has a ending date, but could be on-going
    • Is managed/monitored by a project manager/principal investigator either on an inception-to-date basis or on a fiscal year basis
    • Allows for reporting across multiple departments and divisions
    • Consists of seven characters (first 3 characters = “PRJ” and last 4 characters = numbers issued sequentially in NNAA format where NN are numbers and AA are alpha characters)
  3. Project Lite software is used at UW-Madison for the set-up, maintenance, monitoring, and close-out of non-sponsored projects. Project Lite uses a “slimmed down” version of the Projects Costing Module (part of the UW-Madison Grants Module). Three separate panels/screens (general information, team information, user fields) are used within the Project Costing Module. In addition, two customized panels/screens have been added to the Project Costing Module and are also used (award reporting, gift-in-kind reporting).
  4. Accounting Services is responsible for the set-up, maintenance, monitoring, and close-out of all non-sponsored projects unless designated divisions have been delegated this responsibility.
  5. Divisions may request and ultimately receive delegation responsibility fromAccounting Services for the set-up, maintenance, monitoring, and close-out of non-sponsored projects for their division.
  6. In order to effectively assume and maintain appropriate delegationresponsibilities, it may be prudent to have the following roles and responsibilitieswithin a division before assuming delegation:
    • Project Manager/Principal Investigator – identifies need and coordinates with department administrator
    • Department Administrator – works with certified user to edit and/or close project
    • Certified user of Project Lite – verifies need, sets up project, edits existing projects, and closes-out project, as needed
  7. In order to learn about Non-Sponsored projects in general, gift projects, Project Lite, and gain access to Project Lite software potential users must complete a training course that provides Project Lite user certification and delegation responsibility at the successful completion of the course.
  8. Once a division user has attended the appropriate training and has beencertified in the use of Project Lite the user is expected to:
    • Keep his/her login and access to Project Lite confidential
    • Use only his/her login for access to Project Lite
    • Enter information in all appropriate fields during set-up process
    • Set up projects for only the division (s) he/she is responsible for
    • Use appropriate funds for all projects
    • Administer, manage and monitor projects that he/she sets up
    • Change set-up information as needed
    • Update edit information as required
    • Update project status when necessary

Records Retention

Purchases and receipts against non-sponsored projects fall under the UWS Fiscal and Accounting General Records Schedule.

The retention period for all non-sponsored documents related to purchases and receipts is the fiscal year of creation plus an additional 6 years for the original record and thereafter destroy. Duplicate documents should be destroyed when no longer needed. Do no retain duplicates longer than the original record.


Definitions/Terminology

SPONSORED AND NON-SPONSORED PROJECT

Sponsored Project Non-Sponsored Project
Source of fund is from an external entity whom the UW will have an ongoing relationship with after the initial receipt of funding Source of funds could be from an internal entity such as State, departmental, or institutional
Generally, if money is from the federal government it is a sponsored project May be funded by multiple sources
Ongoing relationship usually in one of the following forms:

  • Billing/letters of credit (LOC) draws
  • Reporting requirements (both technical & financial)
Generally does not have billing or reporting requirements
Reporting requirements include “effort” reporting (work performed) “Effort” reporting may be required depending on funding sources
Facilities & Administration (F&A) overhead coast are usually charged F&A is generally not charged
Has terms & conditions attached Generally does not have conditions attached
Time period often extends beyond a year Time period may extend beyond a fiscal year – could be for a shorter period of time though
Under certain circumstances, internally funded projects may be treated like a sponsored project because of the imposed terms, conditions or other reporting requirements (e.g. fund 101 projects created by Graduate School) Gift projects are generally considered a non-sponsored project
Funds used – 133 (Contracts), 135 (Gifts-WARF), 142-148 (Federal Aid) Funds used – 136 (General Operations Receipts), 161 (Trust Funds), 233 (Gifts), various other funds
Usually is in one of these forms:

  • Grant
  • Contract
  • Cooperative agreement
Examples:

  • Internal project
  • State project
  • Trust Fund
  • Gift Project

DEPARTMENT ID AND PROJECT ID

Department ID Project ID
Represents an organizational unit or reporting entity such as a segment of a school or college Represents a type of program activity, events, special events or project within a fund that must be monitored and reported independently from the organization
Should be used for on-going business operations, recurring expenses/revenue Has a beginning date and generally has a ending date, but could be on-going
Managed/monitored by a department/division supervisor/manager on a fiscal year basis Managed/monitored by a project manager/principal investigator either on an inception-to-date basis or on a fiscal year basis
Keeps track of multiple project ID activity within a department Allows for reporting across multiple departments and divisions
Consists of six digits

  • first two digits = the Division
  • next two digits = the Department
  • last two digits = the Sub-Department

Note: Payroll uses “A” preceding the six digits

Consists of seven characters

  • first three characters* = “PRJ”
  • last four characters* = numbers issuedsequentially in NNAA format (NN = number and AA = alpha)

Note: Payroll only uses the last four characters

* as of February, 2008

Example
03 = Business Services
01 = Administration
10 = Information Technology48 = College of Letters & Science
83 = Sociology
60 = Science & Technology Studies
Examples
A grant
A contract
A gift
A revenue producing activity like the publication of a journal
A conference/seminar
A special event

 

ROLES and RESPONSIBILITIES

Role Responsibility
Project Manager/PI Identify need and coordinate with department administrators.
Department Administrator Work with certified user to edit and/or close project.
Certified user (at division level) of Project Lite Verify need and set up new project or edit existing project, if appropriate. Contact Accounting Services, if necessary.
Accounting Services Staff
  • Provide test environment access to new user before training
  • Provide training and certification
  • Provide expertise and consulting
  • Monitor and run post-audit reports
  • Serve as back-up when needed
  • Serve as Project Lite administrator for divisions who do not have a certified user

 

TERMINOLOGY-PEOPLESOFT MODULES

Grants & Associated Modules Project Lite
  • UW-Madison, UW-Milwaukee, and UW-Extension will use the Grants Module for setting up sponsored projects
  • UW-Madison, UW-Milwaukee, and UW-Extension will also use the functionality of other associated modules for sponsored projects: Proposals(including WISPER), Award processing, Contracts, Billing, A/R, Commitment Control, Cost Share, Effort Reporting
  • users will be able to access information entered into the Grants Module through WISDM reporting tool
  • will be used by UW-Madison, UW-Milwaukee, and UW-Extension for non-sponsored projects
  • will be used by all other UW system campuses for both sponsored and non-sponsored projects
  • uses a “slimmed down” version of Project Costing Module
  • uses three panels (screens) of Project Costing Module
  • general information
  • team information
  • user fields
  • uses two customized (“bolt-on”) panels that were added
  • award reporting (including financial information)
  • gift-in-kind reporting
  • users will be able to access information entered into Project Lite through WISDM reporting tool
  • users who use both the Grants Module and Project Lite will notice consistency in the data elements regardless of where the project was created
  • unique project numbers will be assigned across campuses
  • project numbering will be auto-numbering (after February 2008)
  • format will be PRJNNAA (NN=numeric, AA=alpha)

 


Procedures


Related Documents


Forms


Who should know this policy?

  • Deans, Directors, and Staff who work with project

104 Transfer of Funds (money) Between UW-Madison Departments/Funding Sources Policy

Funds may be transferred between departments and funding sources within the UW-Madison.


Date:
08/17/05 (Last updated: January 24, 2018 )


Cost Transfer Tool

Statement of Policy:

Funds may be transferred between departments and funding sources within the UW-Madison.


Related Procedure(s):

104-Transfer of Funds (money) Between UW-Madison Departments/Funding Sources


Who should know this policy?

Deans, Directors, and Staff dealing with transfers of funds


Contacts:

Susie Maloney

703 Cost Transfer Request (Non-Salary) Non-Grant–any fund except 133 and 144 Policy

There are circumstances in which it may be necessary to transfer expenditures to a fund after the initial recording of the charge. A Cost Transfer Request (Non-salary) is an after-the-fact reallocation of costs.  The Cost Transfer Request (Non-salary) is used to transfer funds/move expenditures from one fund, department, project, account, amount, etc. to another to assure the accuracy of the general ledger and data integrity. 

UW-Madison Administrative Policy
Policy # 703
Cost Transfer Request (Non-Salary) Non-Grant–any fund except 133 and 144 Policy

Effective Date: October 13, 2009
Last Updated: May 2, 2011


Statement of Policy

  1. There are circumstances in which it may be necessary to transfer expenditures to a fund after the initial recording of the charge. A Cost Transfer Request (Non-salary) is an after-the-fact reallocation of costs.  The Cost Transfer Request (Non-salary) is used to transfer funds/move expenditures from one fund, department, project, account, amount, etc. to another to assure the accuracy of the general ledger and data integrity.  Here are some examples of typical circumstances in which cost transfers are allowed:
    • Correction of a clerical error
    • Reallocation of expenses where multiple accounts benefited
    • Reallocation of shared resource costs
    • Transfer of costs from divisional or discretionary funds to another
  2. For purposes of this policy, non-salary costs are supplies, consultants, travel, equipment and other non-payroll expenditures.
  3. This policy applies to non-grant fund Cost Transfer Requests (Non-Salary) only.  For grant fund transfers refer to http://www.rsp.wisc.edu/policies/costtransfer/index.html.
  4. There are two phases to the transfer process–the preparation phase and the review phase. Three distinct roles are performed during these two phases:  preparer, first approver, and second approver.  During the preparation phase, the preparer often has discovered an error or has been instructed to move funds, and as a result, initiates the transfer process. The person who initiates the transaction may be the first approver (e.g., principal investigator, department administrator; comparable to the approver role in e-Reimbursement).
  5. The review phase entails a second person (e.g., division staff; comparable to the auditor role in e-Reimbursement) to review and process the transaction (or enter the transaction into the Journal Entry Tool [JET] if delegated, trained, and certified.).  The preparer is usually at the department level, but may be at the division level or Accounting Services.  Who corrects the error is generally determined by who found it and who has the knowledge required to make the correction. Separation of duties is important; however, in small departments one person may need to serve in all three roles.
  6. To eliminate redundancy and increase the speed of processing non-salary, Cost Transfer Requests (Non-Salary), the Division of Business Services has elected to certify individuals in using the Journal Entry Tool (JET). To receive certification, approvers must attend the JET Training Program and attest to their ability to perform JET entries correctly. The respective division must also sign a delegation agreement authorizing the individual to act on behalf of the division in the preparation and submission of Cost Transfer Request (Non-Salary) using the JET.
  7. When the transfer is prepared by the division being credited, approval is required from the division being debited. Otherwise, the initiating division should notify the second division, as a courtesy, for informational purposes.
  8.  The roles and responsibilities of each individual are detailed below:
wdt_ID Responsibility Preparer First Approver Second Approver
1 1) Generate form
2 Know policy X
3 Resolve problems X
4 Update form based on approver's feedback X
5 Confirm that:
6 This transfer is necessary X
7 This transfer is reasonable X
8 The expense is allocable to the funding source to which it will be charged X
9 This transfer is consistent with standard university business practices X
10 This transfer is permissible, given university policies X

Additional responsibilities for each role

wdt_ID Role Responsibilities
1 Preparer Know and understand the UW cost transfer policy
2 Preparer Generate the transfer request form
3 Preparer Seek support in resolving difficulties with generating transfer requests
4 Preparer Improve the accuracy of transfer request forms in response to feedback from approvers when requested to do so
5 First Approver Know and understand the UW cost transfer policy
6 First Approver Attend training in the non-salary cost transfer approval roles and responsibilities
7 First Approver Determine whether explicit approvals are required from the "owners" of non-sponsored funding sources, and obtain the explicit approvals when necessary
8 First Approver Route each transfer request form to the second approver
9 First Approver Provide feedback to preparers when the accuracy of transfer forms does not meet an acceptable standard of quality
10 First Approver Provide suggestions to preparers regarding strategies for improving the accuracy of transfer forms

Records Retention

Cost Transfer Requests (Non-Salary) fall under the following record retention schedules. The retention period for Cost Transfer Request (Non-Salary) is the fiscal year of creation + (plus) an additional 6 years for the original record, and thereafter destroy. Duplicate documents should be destroyed when no longer needed. Do not retain duplicates longer than the original record.


Definitions

Necessary: Transfer is necessary to have costs applied to proper funding; original cost is essential to meet a certain result.

Reasonable: Would a prudent person pay this amount for this item or “If it were published on the front page of the Wisconsin State Journal, would that be okay with you”?

Allocable: A cost is allocable if goods or services involved are chargeable or assignable in accordance with the relative benefits received by the projects. In order to be allocable a cost must be treated consistently in like circumstances.

Consistent: Free from variation/contradiction from standard UW business practices.

Permissible: Allowed under UW policies and state law.


Procedures

See procedures for completing the Cost Transfer Request (Non-Salary).


Who should know this policy?

Deans, Directors, and Staff who prepare non-salary cost transfers


Related Documents:

702 Transaction Processing-Closing Purchase Orders (POs) Policy

POs will remain open the entire fiscal year.  POs will be closed or rolled over by Accounting Services at fiscal year-end.  PeopleSoft Shared Financial System (SFS) does not allow the re-opening of POs once closed.

UW-Madison Administrative Policy
Policy # 702

Effective Date: July 1, 2007
Last Updated: July 1, 2007

Policy Contact: Susie Maloney


Statement of Policy

POs will remain open the entire fiscal year.  POs will be closed or rolled over by Accounting Services at fiscal year-end.  PeopleSoft Shared Financial System (SFS) does not allow the re-opening of POs once closed.

Extenuating circumstances may occur during the year which will make closing a PO a necessity.  Other exceptions to closing POs at year end are grants or individual funding lines that are ending.  Accounting Services will close POs at the request of the Dean’s Office or Research and Sponsored Programs (RSP) only in these circumstances…


Related Procedure(s)

702-Transaction Processing–Closing Purchase Orders (POs)


Who should know this policy?

Deans, Directors, and staff who prepare requests to close purchase orders


Related Documents

Use the Encumbrance and Purchase Order Management form.

405 Deferred Revenue – Future Year Revenue Policy

Deferred revenue accounting relates to revenue received from external parties only; not between UW-Madison Divisions or other University of Wisconsin campuses. Examples include revenue received on or before June 30 for fall conferences, summer session tuition, tickets sales for a future fiscal year, prepayments for products yet to be delivered as of June 30, prepayment for services to be performed in a future fiscal year and down payments to be returned in a future fiscal year.

UW-Madison Administrative Policy
Policy # 405
Deferred Revenue – Future Year Revenue Policy

Effective Date: July 7, 2015
Last Updated: July 7, 2015

Policy Contact: Cash Management

(Use policy and procedure only between February 1st through July 2nd each year)


Statement of Policy:

Deferred revenue accounting relates to revenue received from external parties only; not between UW-Madison Divisions or other University of Wisconsin campuses.

Examples include revenue received on or before June 30 for fall conferences, summer session tuition, tickets sales for a future fiscal year, prepayments for products yet to be delivered as of June 30, prepayment for services to be performed in a future fiscal year and down payments to be returned in a future fiscal year.


Who should know this policy?

Deans, Directors, and staff handling receipting related to future year activity.


Which form should be used?

Both forms are acceptable to be used. If you have more that 10 transfer lines please use the Deferred Revenue Jet Upload Template.


Related Procedure/Policy


Related Documents

404 Credit Card Merchant Services and PCI Compliance Policy

404 Credit Card Merchant Services and PCI Compliance Policy

UW-Madison Administrative Policy
Policy # 404
404 Credit Card Merchant Services and PCI Compliance Policy

Effective Date: January 1, 2020
Last Updated: February 12, 2020
Last Reviewed: July 23, 2020
Next Review: December 1, 2020


Policy Summary

UW-Madison departments which accept payment cards as a form of payment for goods and services are required to comply with Payment Card Industry Data Security Standards (PCI DSS). The purpose of the PCI DSS is to ensure payment card data is protected.

The PCI Compliance Assistance Team (PCI CAT) will validate each department’s PCI compliance. Failure to comply with the PCI DSS requirements can result in the loss of payment card processing privileges.


Policy Application

This policy applies to all UW-Madison departments which accept payment cards as a form of payment for goods and services.


Rationale

UW-Madison processes over $100 million in payment card transactions per year. This represents almost 3 million transactions from over 200 merchant accounts. The University is contractually responsible for protecting the payment card data used to process these transactions per the guidance provided by the PCI DSS.

A payment card breach may result in fines starting at $500,000. We must also consider additional costs of a payment card breach which are estimated around $242 per payment card[1]. More importantly, UW-Madison’s reputation would be tarnished. This could result in fewer donors willing to support the University or business partners willing to acquire University resources.

Securing payment card data is everyone’s responsibility. Should there be a data security breach, the department responsible for the merchant account will be responsible for the costs of the breach. UW-Madison can reduce the risk of payment card data being compromised by securing the network, hardware, applications, processes, and meeting PCI compliance requirements.

[1]IBM sponsored report by the Ponemon Institute; Cost of a Data Breach Report 2019


Policy Detail

The highest level of PCI responsibility belongs to the Divisional Business Representative (DBR). This individual is responsible for approving the initial merchant account request and reviewing the Self-Assessment Questionnaire (SAQ) annually as the executive officer.

Each department accepting payment cards is required to designate a PCI Site Manager for each merchant account. The PCI Site Manager serves as the point of contact for the merchant account and should have influence to establish procedures for the day-to-day handling of payment cards to ensure compliance.

A. Opening a Merchant Account

Cash Management Approval

The implementation of any and all e-commerce websites or payment card devices to collect revenue must be approved by the Cash Management team within the Division of Business Services – Accounting Services Unit, the Office of Cybersecurity, and, when necessary, Purchasing Services. This ensures that all cash management, security, and contractual requirements are adhered to. Third-party vendors which process payment cards on behalf of the University and submit payment via ACH or paper check must also be approved by these departments; CASHNet is the preferred e-commerce vendor on campus.

All revenue must be deposited into a UW-Madison bank account which posts to WISER/WISDM. Gift or donation merchant accounts can only be processed through the University of Wisconsin Foundation (http://www.supportuw.org/how-to-give).

Policies and Procedures

Written PCI policies and procedures must be established by the PCI Site Manager and submitted to Cash Management; templates will be provided by Cash Management upon request. If stated business practices change, all changes must be submitted to Cash Management via e-mail at pci-help@bussvc.wisc.edu. Departments must address the following components in their business policies and procedures for each merchant account:

  1. A listing of the e-commerce sites where items are sold or event registration occurs (e-commerce only).
  2. A listing of payment card devices that are used with the following pieces of information for each device (physical device only):
    1. The physical location of the device;
    2. The type/version of the device;
    3. When the device is used.
  3. A contingency plan for processing transactions should the primary system be unavailable.
  4. That departments are responsible for the physical security of all payment card devices and other equipment used to collect cardholder data (CHD) and will comply with the following procedures (physical device only):
    1. Obtain approval of the PCI CAT for the storage, transmission, and processing of payment card data in an electronic format. All network locations and devices must be specifically approved for processing payment cards;
    2. Maintain an inventory of all payment card devices and their locations;
    3. Inspect the devices to check for tampering or substitution. It is recommended to complete the inspections during regular financial reconciliations but is required to be completed on a quarterly basis at a minimum;
    4. Document the device inspections; a device inspection log template can be found HERE;
    5. Implement training for all personnel to increase understanding of what suspicious behavior, tampering, and substitution look like and procedures on how to report it.
  5. That a list of employees with access to CHD is maintained and reviewed periodically.
  6. That access to CHD is restricted to only those users who need the data to perform their job duties.
  7. A listing of acceptable methods of processing payment cards.
  8. That email must never be used to transmit payment card or personal payment information. If email is used for this purpose, disposal as outlined below is critical:
    1. The email should be replied to immediately with the payment card number deleted stating that, “UW-Madison does not accept payment card data via email as it is not a secure method of transmitting cardholder data;”
    2. Provide a list of the alternative, compliant option(s) for payment;
    3. Delete the email from your inbox and delete it from your email trash.
  9. That fax machines, if used to transmit payment card information to a merchant department, must be standalone machines with appropriate physical security; receipt or transmission of payment card data using a multi-function fax machine is not permitted.
  10. The merchant account’s refund policy. Refunds must be processed with the same payment card account which was used to process the original transaction.

Merchant Account Fees

Any fees associated with the acceptance of payment cards in a campus department will be charged to the related merchant on a monthly basis. These fees can be seen in WISER/WISDM once they have been posted.

For more information on how to open a merchant account, refer to the following procedures:

 B. Maintaining a Merchant Account

Internal Controls

The following procedures are required to ensure campus merchants maintain adequate transaction integrity:

  1. A reconciliation of payment card activity to WISER/WISDM should be completed and documented at least monthly. E-commerce orders should be reconciled to the CASHNet reporting portal before any merchandise is shipped.
  2. Adequate separation of duties between sales transaction processing and the physical goods being sold must be maintained. In addition, there should be separation of duties between the person issuing refunds and the individual reconciling the account.
  3. All users are required to have their own CASHNet login and Merchant Connect login for access to transactions, settlements, and monthly fees.
  4. All merchant storefronts or shopping carts are to complete quarterly vulnerability scans. Merchants should remediate any vulnerability within 30 days. Scans can be coordinated through the Office of Cybersecurity at https://it.wisc.edu/services/scanning-tools/.
  5. The merchant should periodically perform transaction walk-throughs to ensure the payment page redirects to CASHNet. After reaching the CASHNet page, the browser can be closed without entering any payment card data.
  6. All payment card devices should be inspected for tampering or substitution based on established procedures; these inspections should be documented.

Storage and Destruction

The storage of payment card data, both electronically and/or on paper, received at any and all locations, must be reviewed and approved by the PCI CAT. The following are procedures that should be implemented to ensure proper storage and destruction of payment card data:

  1. Physical security controls are in place to prevent unauthorized individuals from gaining access to the buildings, rooms, or cabinets that store the equipment, documents, or electronic files containing CHD.
  2. No database, electronic file, or other electronic repository of information will store the full contents of any track from the magnetic stripe, the card validation code, or the personal identification number (PIN).
  3. Portable electronic media devices should not be used to store CHD. These devices include, but are not limited to, the following: laptops, USB flash drives, portal external hard drives, compact disks, floppy disks, and personal digital assistants.
  4. CHD should not be retained any longer than that defined by a legitimate business need. The portion of a document with CHD should be destroyed immediately after processing the transaction using a cross-cut shredding machine. It is possible to maintain adequate documentation for transactions without retaining CHD.
    1. Mail order forms with payment card information must be secured after the mail is opened.
    2. Any retention of payment card data after the authorization is received must be documented in the department’s policies and procedures and approved by the PCI CAT.
  5. Chargeback documents from Elavon containing CHD must be secured until processed and destroyed (cross-cut shredded) after processing.The maximum period that PCI Operator Training forms and corresponding PCI compliance logs may be retained is three years from the date of creation. For more detail regarding record retention, please see the University of Wisconsin System Fiscal & Accounting General Records Schedule.
  6. All computers on the PCI Network must be returned to DoIT Departmental Support for sanitization (http://www.doit.wisc.edu/services/departmental-support/). The computer can be returned to the department after the sanitization process is completed. This media includes, but is not limited to: hard drives, tapes, USB drives, etc. The official University Media and Device Disposal and Reuse Policy is documented HERE.

 Self-Assessment Questionnaire (SAQ)

The department’s compliance will be validated through the process of completing and submitting an annual SAQ for each merchant account. This provides the department the opportunity to review their payment card acceptance procedures and ensure compliance is being maintained. The PCI CAT reserves the right to validate responses provided by merchants. Failure to validate the department’s compliance through the SAQ submission process will result in merchant account termination.  If the merchant and PCI CAT cannot agree on the interpretation of the PCI Standards, a third-party PCI Qualified Security Assessor (QSA) will be consulted for final interpretation.

Training

The following training requirements must be met to maintain compliance:

  1. All new DBRs and Site Managers are required to attend an initial in-person PCI Compliance Training session which is offered twice a year.
  2. All DBRs and Site Mangers are required to complete the online PCI Compliance Training renewal annually. This training is completed using Canvas; contact pci-help@bussvc@wisc.edu for access.
  3. Any employee or volunteer that handles a payment card on behalf of UW-Madison is required to complete the PCI Operator Training
    1. The PCI Site Manager is responsible for tracking the completion of all the PCI Operator Trainings each year.

Risk Assessment

The Office of Cybersecurity, along with the Cash Management team within the Division of Business Services – Accounting Services Unit, will conduct an annual formal risk assessment. Departments may be asked to participate in the formal risk assessment discussion. The risk assessment will identify vulnerabilities and the potential impact to PCI compliance. The likelihood and impact of the threats will be scored, ranked, and prioritized. All threats will be addressed with mitigation tasks, timelines, and/or acceptance statements. Documentation will be maintained from the output of the risk assessment exercise.

Incident Response

In the event of a breach or suspected breach of security, the department or unit must immediately report the incident following the steps documented HERE. If the suspected activity involves computers (hacking, unauthorized access, etc.), immediately notify the DoIT Help Desk.

C. Closing a Merchant Account

A merchant account will be closed if the department fails to comply with this policy and/or PCI DSS requirements. Compliance includes maintaining a Site Manager, completing the required annual training, and submitting the appropriate documentation, such as the annual SAQ. Additionally, a merchant account may be closed if there is no activity for twelve consecutive months.

If the merchant account is no longer needed, a merchant may close its account by contacting Cash Management at pci-help@bussvc@wisc.edu. Confirmation from the DBR will be needed as authorization to close the account. Payment card machines that are no longer needed should be returned to Cash Management at 21 N. Park Street, Suite 6101.


Consequences for Non-Compliance

Failure to meet the requirements outlined in this policy will result in suspension of the physical and, if appropriate, electronic payment capability of the non-compliant merchant(s). In the event of a breach or violation of the PCI DSS, the payment card brands may assess penalties to UW-Madison’s bank which will likely then be passed on to UW-Madison. Any fines and assessments imposed will be the responsibility of the compromised merchant. A one-time penalty of up to $500,000 per card brand per breach can be assessed as well as on-going monthly penalties thereafter until compliance is achieved.

Persons in violation of this policy are subject to sanctions including loss of computer or network access privileges, disciplinary action, suspension and termination of employment, as well as legal action. Some violations may constitute criminal offenses under local, state, or federal laws. UW-Madison will carry out its responsibility to report such violations to the appropriate authorities.


Supporting Tools


Definitions

CASHNet: A third-party, e-commerce service provider contracted by the University of Wisconsin that is used to process credit card payments.

Card Brands: Payment card networks including Visa, Mastercard, Discover, and American Express.

Cardholder: The person to whom a payment card is issued or any individual authorized to use the payment card.

Cardholder Data (CHD): At a minimum, cardholder data consists of the full Primary Account Number (PAN). Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date, and/or service code. The cardholder name with only the last 4 digits of the PAN is not considered CHD and does not need to be protected. See Sensitive Authentication Data for additional data elements that may be transmitted or processed (but not stored) as part of a payment transaction.

Card Identification Number (CID): The three-digit security code on the back of the payment card for MasterCard, Visa, and Discover. The four-digit security code on the front of American Express payment cards.

Chargebacks: Occur when the customer challenges the validity of the original charge and instructs their bank to reverse the charge.

Merchant Connect (MCP): An online tool from Elavon, the credit card processor, which displays transaction activity and monthly statements.

Payment Card: A financial transaction card issued by a financial institution. Also called Bankcard, Charge Card, Credit Card, or Debit Card.

Payment Card Industry Data Security Standards (PCI DSS): A multifaceted security standard developed and owned by the major payment card companies that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. PCI DSS represents a common set of tools and measurements to help ensure the safe handling of sensitive information. The standard comprises 12 requirements that are organized in 6 logically related groups or “control objectives.” Failure to conform to these standards can result in losing the ability to process payment card payments, being audited, and/or being fined.

Point-to-Point Encryption (P2PE): A comprehensive set of security requirements for point-to-point encryption solution providers; this PCI standard helps those solution providers validate their work. Using an approved point-to-point encryption solution will help merchants to reduce the value of stolen cardholder data because it will be unreadable to an unauthorized party. Solutions based on this standard also may help reduce the scope of their cardholder data environment and make compliance easier.

Sensitive Authentication Data: Information used to authenticate cardholders and/or authorize payment card transactions including but not limited to card validation codes/values, full track data from the magnetic stripe or equivalent on a chip, PINs, and PIN blocks.

Service Provider: A business entity that is not a payment brand but is directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This includes companies that provide services that control or could impact the security of cardholder data. Examples include service providers that provide managed firewalls, intrusion detection systems (IDS), and other services.


General Responsibilities

Campus Merchant Department – Manage the daily operations of the merchant account(s) and maintain PCI compliance.

Divisional Business Representative (DBR) – An individual within the dean or divisional office. This individual has the highest level of PCI responsibility including approving the initial merchant account request and annually reviewing the SAQ as the executive officer.

Payment Card Industry Compliance Assistance Team (PCI CAT) – Provide guidance and monitor PCI compliance requirements.

Site Manager – This individual is the point of contact for the campus department merchant account(s) and should have influence to establish procedures for the day-to-day handling of payment cards to ensure compliance.


Links to Related Policies & Procedures