Ohio University

skip to main content

Getting Started

Accepting credit and debit cards improves a customer’s experience while also creating greater efficiencies in payment collection. However, having this convenience requires thorough preparation and constant vigilance in order to maintain card data security. This page outlines what a department needs to know and do to become a merchant. Under no circumstance should a department contract with a credit card processor to begin accepting credit/debit cards. Departments cannot accept credit/debit cards until they have the approval of the Office of the Bursar.

 

Payment Processing Options

Payment cards can be accepted using terminal, point-of-sale, or online systems:

  • Terminals are small, desktop devices that can process credit and debit transactions and allow users to tap, swipe, or insert a card (chip and PIN), or to enter information manually.
  • Point-of-sale (POS) systems are computers specialized to process payments for a department’s specific business needs—typically one or more PCs connected to a central server or to a hosted environment. A POS system is more complex than a terminal and requires additional security and maintenance. POS systems support the same credit and debit payment cards and entry methods as a terminal.     

Note! Please contact the Office of the Bursar before you purchase any POS hardware or software. We will work with you to ensure that the POS system you are looking to purchase is compatible with the university’s credit card processor and meets any or all operational and security requirements.  The purchase must also be managed by Procurement.

  • Online (ecommerce) applications enable departments to accept credit and debit payments over the internet. The Office of the Bursar can create eMarket sites for online payment processing. Departments that have their own ecommerce system can use the CASHNet® Checkout gateway to handle payment processing. Integrating with the CASHNet® Checkout gateway requires some programming but eliminates any card data security requirements for a department’s web site.  

Note! Departments are not allowed to accept payments via PayPal. Contact the Office of the Bursar so that we can assist you with a solution!

 

All these methods can process Visa, MasterCard, American Express, and Discover cards. Departments may determine which of these cards they want to accept, although most accept all four brands. Payments are processed in real time and post to a merchant's general ledger account(s) the next business day. Any payment processing choice(s) must be approved by the Office of the Bursar before any transactions will be processed.

 

First Steps

  1. Obtain approval as a cash handling department (link form)
  2. Complete and submit the appropriate Merchant Card Services Form to begin the enrollment process.
  3. Review our Data Security pages to prepare your department can comply with all card data security requirements.
  4. Read and follow the Employee Requirements to ensure existing and new employees follow all card data security requirements.
  5. Ensure that employees complete the annual Payment Card Data Security Training . This training is required for all employees who handle payment card data.
  6. Read the Training Resources documents relevant to your department's business operations.

 

What to Expect


Once your request to begin accepting payments has been approved, we will notify your department and work with you to set up the payment options you have chosen.

  • Terminals typically require a new merchant ID to be set up with the university’s credit card processor. Allow up to four weeks for that process to complete.   
  • Point-of-sale systems' setup time will vary widely. If a new merchant ID is required, allow six to ten weeks for that process to complete.
  • Online merchant setup time is determined by how quickly you can integrate your website with CASHNet®.
  • eMarket setup is dependent upon the complexity of your offering.  <Link to eMarket page>

 

Responsibilities

The Office of the Bursar has the responsibility and authority to:

  • Develop and issue operating policies and procedures for handling merchant card services
  • Provide general supervision of merchant card operations
  • Develop and maintain processes and systems
  • Enforce compliance with Payment Card Industry Data Security Standard (PCI DSS) for credit/debit card security
  • Investigate breaches involving cardholder information and recommend disciplinary action

 

Departments authorized to accept credit/debit card payments are responsible for:

  • Developing internal policies and procedures for complying with any applicable federal or state laws and university regulations
  • Meeting accounting requirements regarding merchant card services
  • Exercising reasonable care in screening charge transactions to reduce credit card misuse and loss of funds.

 

Employees are responsible for keeping all cardholder information secure.

 

Definitions

Cardholder Data
Cardholder data includes the full primary account number, cardholder name, expiration date and/or service code (security code).

Chargeback
If a department fails to prove that a customer authorized a credit card transaction, the amount of the transaction will be deducted from the department's account.

Discount Rate
A collection of fees charged by the credit/debit card processor to process the merchant's transaction.

Merchant Department
A university department that accepts credit and/or debit cards as a way to pay for goods, services, information, or gifts.

Primary Account Number (PAN)
The PAN is a unique credit or debit card number that identifies the issuing bank and the cardholder account.

Point of Sale (POS)
Hardware and/or software used to process credit/debit card transactions at merchant locations.


Redact
The process of removing sensitive or classified information from a document before it is stored.

 

Accept Cards for Payment

All departments authorized to accept credit or debit card payments must exercise reasonable care in screening transactions to reduce credit/debit card misuse.

Fiscal officers and operations managers must acquaint themselves with the information in the Payment Card Acceptance Requirements. They should summarize that information and make it part of training provided to staff who are processing transactions.

If a portion of any payment is non-refundable, inform the customer of this before you process the sale (for example, 90-day limit for returns, final sales that are not refundable).

 

Procedure

To accept cards for payment:

Card Present (in person purchase)

  1. Make sure the card is signed.
  2. Hold the card through the entire transaction.
  3. Insert the card only once unless prompted to do otherwise by the device.  
  4. Print the sales receipt.
  5. Obtain the customer's signature and compare it to the signature on the card. If the receipt signature differs significantly from the card's signature, ask to see another form of photo identification.
  6. Ensure the transaction is complete before beginning another transaction.

 

Card Not Present (mail, telephone, or web order)

Most of the safeguards for these purchases are embedded in the software or terminal. When you process the transaction, the system or terminal will prompt you to enter information, such as the customer's billing address and the card security code, which is designed to reduce fraud.

If your department has an e-commerce website, do not enter card information for customers or accept payment information by email, chat, instant message or any similar messaging technology, as that increases security risks. Direct the customer to your sales website and to make the purchase for themselves.

 

 

Respond to Disputed Transactions

Cardholders have the right to dispute transactions they claim were not authorized or were charged in error. Disputed transactions that remain unresolved can negatively affect the ability of the University to continue accepting credit/debit cards.

To respond to disputed transactions:

  1. When a cardholder disputes a charge with their financial institution, the Office of the Bursar is contacted.
  2. The Office of the Bursar provides transaction details to the dispute resolution contact at the merchant department. They ask the department to provide supporting documentation (copy request) regarding the transaction.
  3. The department dispute resolution contact has 2 business days to respond with the requested documentation. There is no grace period. If you miss this deadline, the revenue from the transaction will be debited from your department's account.
  4. The Office of the Bursar forwards the documentation (rebuttal) to the financial institution who reviews it and makes a decision. The department may be asked to provide additional information.
  5. The disputed transaction is decided in favor of either the merchant department or the customer. The Office of the Bursar posts any adjustments to the department's account.

 

Refund a Transaction

When an item or service is purchased using a credit or debit card and a refund is necessary, the refund must be credited to the same card account from which the purchase was made.

To refund a transaction:

  • Process the refund through the same technology used to make the original sale (for example, terminal, web, Point of Sale (POS) system).
  • Always credit the same card account used in the original sale. Do not issue cash or a check.
  • Do not refund more than the amount of the original sale. Do not consolidate multiple refunds in one transaction because that can cause the transaction to be flagged as possible fraud.

 

 

Reconcile Credit/Debit Card Transactions

The Office of the Bursar posts receipt transactions to Oracle each business day. Departments must reconcile their internal sales records with the amounts posted to Oracle regularly. Departments must also perform a monthly reconciliation to ensure that sales log matches the amounts posted to the Oracle general ledger. Reconcile all accounts to be sure all revenue has been posted properly in Oracle. If there is a discrepancy, contact the Office of the Bursar as soon as possible at cashier@ohio.edu.       

 

Keeping Merchant Card Records

Records are official and trustworthy documents used for accountability and transparency. Requirements for retaining records are mandated by federal and state laws and regulations. Merchant card records consist of documentation of orders, sales receipts, settlement reports, and Payment Card Industry (PCI) self-assessment questionnaires and related documents.

Your department must retain sales receipts and order forms in a PCI-compliant manner. Retain these records for the current fiscal year and 4 previous fiscal years. Destroy records or securely redact the card numbers from these expired records as is convenient, but at least every month. If a transaction is being disputed, keep the transaction records until the dispute is resolved even if the 12 month period has expired.

For assistance, consult the Office of the Bursar.

Redaction:

Redaction is the process of removing sensitive or classified information from a document before it is stored.

To redact information from a paper document:

  1. Before  scanning a document (use either of the following methods):
    • Physically cut out all the text to be redacted and dispose of the clippings by cross-cut shredding or by using an officially approved document destruction service, such as Shred-It.
    • Use opaque tape or paper to completely cover over the sections to be redacted.
  2. After  completely cutting out or covering the text to be redacted, copy or scan the document, making sure no un-redacted sensitive personal information is visible; use the resulting copy or image.

Insufficient redaction methods:

Do not  use the following methods to redact information from documents, as they are insufficient:

  • Changing text color:  Changing the redacted text's font color to match the document's background color leaves the redacted text easily discoverable to anyone who clicks and drags over the area using a mouse.
  • Covering or highlighting text:  Covering redacted text with images or comments, or highlighting text with a matching color, leaves the redacted text discoverable.
  • Deleting only visible data:  Digital files retain embedded and hidden metadata containing revision history and other information. Metadata can reveal anything that was contained in the file at any time, even text that was previously deleted or changed, and even if the file was re-saved. Metadata can be useful for tracking revisions, but if it is not purged from the document, anyone can view deleted information, even after the document has been converted to PDF format.
  • White Out or Correction Tape: The white out or correction tape can be removed from the document exposing the sensitive data.
  • Black marker:  A hard copy of a document redacted with black marker may still provide enough image detail to enable someone to see what was assumed hidden; this method is especially risky if that same data repeats multiple times across a document.

 

 

 

Payment Card Acceptance Requirements

 

IN PERSON
The card must be swiped through (magnetic), inserted (chip), or tapped on a card processing terminal or PIN pad. Follow the prompts given by the terminal or PIN pad. Do not keep any card information after a transaction has completed.

PHONE
Card and account information can be keyed into the card processing terminal. Follow the prompts given by the terminal. If any card information is written down while entering a transaction, that information must be shredded once the transaction has been completed.

FAX
Most PC-based FAX software does not provide a secure repository for storing incoming FAXes, therefore the best method to accept card information is by a standalone FAX machine in a controlled location. Treat these FAXes the same way as you would treat cash.
Card information can be keyed into the card processing terminal. Follow the prompts given by the terminal. Once a transaction is complete, the card information on the FAX must be rendered unreadable. If an entire FAX must be kept, marking out the card information with a china marker is preferable.

MAIL
Card information can be keyed into a card processing terminal. Follow the prompts given by the terminal. Once a transaction is complete, the part of the mailed form containing card information must be rendered unreadable. Marking out the card information with a china marker is preferable.

EMAIL
Card information must never be accepted in an email message. If a customer sends card information by email, delete that email and send a response that card information is not accepted by email. In the response, give the customer a list of alternative methods of sending their card information (FAX, mail, phone, and so on). When you reply to the original email, delete any card information in it before sending the message.

SMS TEXT MESSAGING
Card information must never be accepted in test messaging or any other type of instant messaging system.  If a customer sends card information in this manner, delete the message and send a response that card information is not accepted in that manner.  In the response, give the customer a list of alternative methods of sending their card information (FAX, mail, phone, and so on). Be certain when you reply that any card information has been deleted prior to submission.

FORM DESIGN TIP
When designing a form that will have an area to enter card information, put that section at the bottom of the form. After a payment has been processed, the bottom of the form can be cut or torn and then shredded. Remove card information before scanning or imaging the form, or prepping for other long-term storage. Card information on paper being disposed of must always be shredded.

PROCESSING DELAY TIP
It is best to accept card information only when it can be processed immediately. If a delay is required and card information must be stored, do not store it in electronic format, and treat the paper containing card information as if it were cash.

Security
Protecting customers’ payment card information is more than a nice idea—it’s a requirement. Two sets of standards apply to merchant card-processing units:

  • The Payment Card Industry Data Security Standard (PCI DSS) is technical and operational requirements set by the PCI Security Standards Council to protect cardholder data. The PCI DSS applies to all business entities that store, process, or transmit cardholder data. The Council is responsible for managing these security standards, and compliance is enforced by the founding members' council: American Express, Discover Financial Services, Visa and MasterCard.
  • The System PCI DSS Policies are special policy additions that relate or “key” to the PCI DSS.

It is each merchant department's responsibility to follow all policies and procedures in the PCI DSS, as well as those put in place by Ohio University. Merchants that do not follow these policies and procedures may lose the ability to accept card payments.

The Office of the Bursar and the Office of Information Technology Security Office are responsible for making sure that all university departments that accept payment cards (for the sale of goods or services) comply with all applicable data security standards. We conduct periodic reviews of each department's processing environment to ensure that all policies and procedures are being followed. As always, any business operation is subject to formal review by the Office of Internal Audit.

 

Become PCI Compliant

All department heads must ensure that their department follows the Payment Card Industry Data Security Standard (PCI DSS) to keep credit/debit card data secure. All departments must meet this standard or they will not be allowed to accept credit/debit cards.

Meeting this standard protects your department and the university. Data breaches can result in fines, penalties, loss of privileges from the credit/debit card processor, and damage to the university’s reputation. This standard also protects your customers. Data breaches can lead to identity theft and can result in lawsuits. In addition, customers are reluctant to shop at locations with a history of data breaches.

 

Procedure

To become PCI compliant:

  1. Consult with the Office of the Bursar and the Office of Information Technology Security Office. They will help you determine your compliance in the areas below:
  • Build and maintain a secure network
  • Protect cardholder data
  • Maintain anti-virus software
  • Implement strong access control measures
  • Regularly monitor and test networks
  • Maintain an information security policy

 

 

Validate PCI Compliance Annually

All departments that accept credit/debit cards must follow the Payment Card Industry Data Security Standard (PCI DSS) for credit/debit card security. Departments must validate their compliance with the PCI Standard each year.

Before you change how you process credit/debit payments, contact the Office of the Bursar to ensure that you remain in compliance. You may need to re-validate your compliance before your next scheduled annual validation.

To validate PCI compliance annually:

  1. The department manager (or CFAO?) receives an email reminder from the Office of the Bursar.
  2. Complete a Self-Assessment Questionnaire (SAQ).
  3. Confirm that all staff are staying current with their annual Payment Card Data Security training.
  4. The Office of the Bursar and the Office of Information Technology Security Office reviews the questionnaire and may contact the department if there are any outstanding issues.

 

 

Store Cardholder Data on Paper Securely

Because storing cardholder data on paper increases the risk of a security breach, avoid doing so unless you have a strong business need.

 

Procedure

To store cardholder data on paper securely:

  1. If you believe you have a business need to store cardholder data, consult with the Office of the Bursar to confirm your business need and determine the best method for storage.
  2. Follow these minimum PCI Standard for any paper that contains card information:
  • Store all materials containing cardholder information in a locked file cabinet, safe, or other secure storage mechanism in a restricted/secure area.
  • Never store sensitive authentication data such as CVC2/CVV2/CID or PIN after the sale has been processed.
  • Limit access to sales drafts, reports, or other sources of cardholder data to employees on a need-to-know basis
  • Make sure all identifying information is removed or redacted according to the guidelines in Keeping Merchant Card Records.
  • Show only the last four digits of the credit/debit card account number on printed receipts.
  • Conduct a periodic inventory of stored paper forms to account for all credit/debit transaction documents. When destroying paper forms that contain cardholder information, render them unreadable by incinerating or pulping them or by using a cross-cut shredder.
  • Do not store card information in any electronic system, including customer databases or spreadsheets.
  • Do not send card information on paper to a different physical location without using a secure courier service that will confirm safe delivery.

 

Payment Card Industry Standards

All University departments that accept payment cards must follow all the requirements in Payment Card Industry Data Security Standard v3.2 and in University PCI DSS Policies .

The most essential documents for complying with PCI DSS are provided in the following list:

See the PCI Data Security Standards Council Document Library for other useful documents, such as a prioritized approach lists, reporting templates, and more.

 

System PCI DSS Policies

This page lists policies that apply to all System and university merchants in addition to what is included in the PCI DSS version 3.1 (summarized on the Payment Card Industry Data Security Standard page).

Data retention and disposal (requirement 3.1)

Cardholder data may only be retained to that which is required for business, legal, and/or regulatory purposes. Business requirements for cardholder data storage must be documented and submitted with the yearly Self-Assessment Questionnaire (SAQ). Cardholder data must be deleted/removed/expunged from any system according to the procedure set by the department's records retention schedule. If no records retention schedule is currently on file with the University Records Manager, all records must be kept until the record retention has been completed.

Departments must implement a quarterly procedure to remove, or review, stored cardholder data that has exceeded any retention requirement and is subject to removal. Cardholder data must be deleted/removed/expunged in a PCI DSS compliant manner.

This policy applies to all cardholder data both in electronic and paper format.

 

Sensitive authorization data (requirement 3.2)

Sensitive authentication data must never be stored after authorization. If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process. Displaying PAN (Primary Account Number) (requirement 3.3)

The cardholder PAN (Primary Account Number) must be masked at all times unless there is a legitimate business need to see the full PAN. The first six and last four digits are the maximum number of digits to be displayed.

 

Strong cryptography (requirement 4.1)

Use strong cryptography and security protocols (for example, TLS, IPSEC, SSH, and so on) to safeguard sensitive cardholder data during transmission over open, public networks, including the following:

  • Only trusted keys and certificates are accepted.
  • The protocol in use only supports secure versions or configurations.
  • The encryption strength is appropriate for the encryption methodology in use

 

Transmitting cardholder data (requirements 4.2.a and 4.2.b)

Never transmit or accept any cardholder data by email, chat, instant message, SMS, or any similar end-user messaging technology.

 

Security patch, anti-virus software, and vulnerability management (requirements 5.2.a and 6.1)

All system components, software, and anti-virus software must have the latest vendor-supplied security patches installed within one month of release. Virus definitions must be updated within 48 hours of release.

Policies and procedures must be examined to verify that processes are defined to identify new security vulnerabilities.

 

Development of payment processing systems (requirement 6.3.2)

Any internally-developed systems that store, process, or transmit cardholder data must be approved by the Office of the Bursar and the Office of Information Technology Security Office and developed according to the Payment Application Data Security Standard (PA-DSS). All code, including changes after going live, must be reviewed by individuals other than the originating code author and by individuals who are knowledgeable in code review techniques and secure coding practices. Appropriate corrections must be implemented prior to release. Code review results must be reviewed and approved by the OIT Security Office prior to release.

 

Access control (requirement 7.1 and subrequirements)

Access to system components and cardholder data must be limited to individuals whose job requires such access. Access rights for individuals must be set to the least number of privileges to perform the required job and must be assigned based on job classification and function. Authorization forms and documented approval must be maintained for all cardholder data access. All access controls must be implemented by an automated control system.

 

User accounts and passwords (requirements 8.1.5, 8.5.1, 8.5.7, and 8.5.8)

All user accounts and passwords must follow addition, deletion, modification requirements set forth in the PCI DSS. Group, shared, or generic accounts and passwords are not allowed.

Accounts used by vendors to access, support, or maintain system components via remote access must be enabled only during the time period needed and disabled when not in use.

 

Media distribution and retention (requirements 9.6, 9.7.a, 9.7.1, 9.7.2, 9.9, 9.9.1, 9.10, and subrequirements)

Any distribution of media, including paper forms, that contains cardholder data must be strictly controlled. The media or the container must be clearly marked so it can be identified as confidential. Media sent outside of a department must be logged and tracked.

All media storage must be inventoried annually.

All media destroyed must be cross-cut shredded, incinerated, pulped, or securely deleted so that there is reasonable assurance that any hard copy materials or data on electronic media could not be reconstructed. Any media ready for disposal must remain as secure as its original storage.

 

Device tampering and substitution (requirement 9.9)

Departments must maintain a proper inventory of all credit card terminal devices and share that information with the Office of the Bursar. Devices must be inspected annually for tampering or substitution. Inspection training is available via the Cash Handling and Credit Card Security Awareness training.

 

Log review (requirements 10.6, 10.7.a, and 10.7.b)

Logs for all system components that are in scope for PCI DSS compliance must be reviewed at least daily. All exceptions must be documented and review of those exceptions must be documented as well.

Audit logs must be retained for at least one year and a process be in place to immediately restore at least the last three months’ logs for analysis.

 

PCI DSS requirements (requirement 12.1)

All merchants must be PCI DSS compliant at all times. All merchants must comply with all applicable PCI DSS requirements.

 

Risk assessment (requirement 12.2)

The PCI DSS must be reviewed on a yearly basis for any risks that are not currently being addressed by the standard. Any unaddressed risks must have new controls proposed along with a standard risk assessment for those new controls. Applicability of any controls will be assessed across the merchant installed base and an implementation plan developed for rolling out any additional controls.

 

Employee-facing technology use (requirements 12.3.1 through 12.3.7)

All employee-facing technologies used within a cardholder data environment require written approval from the Office of the Bursar.
 

Wireless, removable electronic media, laptops, and personal data/digital assistants (PDAs) are not allowed within any cardholder data environment.

Approved devices include:

  • Payment card terminals provided by the Office of the Bursar
  • PCs and auxiliary peripherals specifically configured and dedicated to processing payments (see workstation standard)

 

All technology use must be authenticated with user ID and password or other authentication item (such as a token).

A list of all devices and the personnel authorized to use the devices must be maintained and reviewed on a yearly basis. All devices must be labeled such that they can be properly tracked to a device owner or manager and device purpose.

Approved devices must be used only on networks designed to be PCI DSS compliant and approved by the Office of the Bursar.

 

Remote access technology (requirements 12.3.8 through 12.3.10b)

Any device that utilizes remote-access technologies must employ automatic disconnect of sessions after a period of inactivity. That period must not exceed 60 minutes.

Any remote-access technology used by vendors or business partners must be activated only when needed, with immediate deactivation after use.

If remote-access technology is employed, copying, moving, or storing of any cardholder data, even temporarily, onto any local media is strictly forbidden.

Any email or internet access within a cardholder data environment requires written justification approved by the Office of the Bursar and must be reviewed annually as part of the Self-Assessment Questionnaire documentation process.

 

Applicability (requirement 12.4)

All policies and procedures related to PCI DSS compliance apply to all System and university employees as well as contractors or volunteers working on behalf of Ohio University.

 

Responsibility for security policies and procedures (requirement 12.5.1)

The Office of the Bursar and the Information Security Office are responsible for establishing, documenting, and distributing PCI DSS security policies and procedures.

 

Responsibility for security alerts (requirement 12.5.2)

All departments that process credit card payments are responsible for monitoring and analyzing security alerts and information, and distributing them to appropriate personnel.

 

Responsibility for security response and escalation procedures (requirement 12.5.3)

The Office of the Bursar is responsible for creating and distributing security incident response and escalation procedures.

 

Responsibility for user account management (requirement 12.5.4)

Any department that operates a payment system that requires user accounts must assign and document the security individual or team responsible for the management of those user accounts.

 

Responsibility for access to data (requirement 12.5.5)

Any department that operates a payment system that stores cardholder data must assign and document the security individual or team responsible for the monitoring and controlling access to the data.

 

Engaging service providers (requirement 12.8.3)

Before establishing service with a vendor that stores, processes, or transmits cardholder data on behalf of Ohio University, a department must obtain approval from the Office of the Bursar to use that vendor. A vendor must be able to demonstrate that they are PCI DSS compliant.

 

Security breach training and incident response review (requirement 12.10)

Ohio University employees who are responsible for security breach management must review security breach procedures on an annual basis.

The PCI DSS Incident Response Plan must be reviewed on an annual basis. The plan must be modified and improved to accommodate lessons learned and industry security developments.

 

Event monitoring (requirement 12.10.3)

Any department that processes payments with a system that utilizes monitoring systems such as IDS (intrusion detection system) or file integrity monitoring must have a University staff member available on a 24/7 basis to respond to any alerts from those monitoring systems.