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 cards can be accepted using terminal, point-of-sale, or online systems:
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.
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.
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.
The Office of the Bursar has the responsibility and authority to:
Departments authorized to accept credit/debit card payments are responsible for:
Employees are responsible for keeping all cardholder information secure.
Cardholder data includes the full primary account number, cardholder name, expiration date and/or service code (security code).
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.
A collection of fees charged by the credit/debit card processor to process the merchant's transaction.
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.
The process of removing sensitive or classified information from a document before it is stored.
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).
To accept cards for payment:
Card Present (in person purchase)
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.
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:
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:
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 email@example.com.
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 is the process of removing sensitive or classified information from a document before it is stored.
To redact information from a paper document:
Insufficient redaction methods:
Do not use the following methods to redact information from documents, as they are insufficient:
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.
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.
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.
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.
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.
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:
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.
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.
To become PCI compliant:
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:
Because storing cardholder data on paper increases the risk of a security breach, avoid doing so unless you have a strong business need.
To store cardholder data on paper securely:
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.
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:
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:
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.