SECTION 17: Acceptance of Payment Cards (Credit and Debit) and e-Commerce
I. Policy
Purpose: To ensure compliance with applicable standards
Scope: Applies to all MSU employees, faculty, staff, students, organizations, third-party merchants, individuals, processes, applications, systems, and networks involved with the processing, transmitting, or storing of payment card data, or any other process that could impact the security thereof.
Responsible Parties:
- Policy and Procedure: Vice President for Finance and Treasurer
- Strategic Direction Advice: PCI Advisory Group
- Technical Management:Chief Information Officer
- Business Management and Implementation: PCI Compliance Manager and Departmental Merchants
Governing Law or Regulation (as updated from time to time):
- Payment Card Industry Data Security Standard (PCI DSS) version 3.2, revision 1.1
- Visa Cardholder Information Security Plan (CISP)
- MasterCard Site Data Protection Program (SDP)
- Discover Information Security & Compliance (DISC)
- American Express Data Security Operating Policy (DSOP)
- NACHA, The Electronic Payments Association
- State of Michigan Identity Theft Prevention Act 452 of 2004
General Policy Statement:
MSU has contracted with various service providers to enable the acceptance of payment (credit/debit) cards and automated transfers between banks (ACH or e-check) to support the efficient flow of payment into MSU for goods and services. Accordingly, MSU is contractually obligated to comply with the PCI DSS, all the card brand security policies, and NACHA. In the event of a breach, MSU is subject to the State of Michigan laws regarding notification.
Any activities at MSU (on the East Lansing campus or other MSU properties), and all MSU-sponsored or MSU-endorsed activities which involve acceptance of payment card transactions must be compliant with the PCI DSS. This policy applies to all transactions conducted in person, by mail, telephone, fax, or online e-commerce. MSU reports compliance as a single entity. Therefore, if one department is not compliant, MSU is not compliant. Noncompliance can result in financial penalties, brand damage, and the loss of the ability to accept payment cards.
Acceptance of ACH involves sensitive data and must be secured. ACH transactions can only be accepted online through the centrally-supported online solution to ensure they are processed in compliance with the NACHA operating rules.
The specific guidelines for each Merchant may apply differently based on the manner(s) in which cards are accepted. Universal to all Merchants is the requirement to properly train employees at the point of hire and at least annually thereafter.
II. Introduction
Payment cards are generally one of the most efficient means of receiving payment for goods or services provided. As with any business transaction, there are responsibilities and risks that a department assumes to ensure they receive the proper amount while adhering to contractual and/or legal regulations. Both payment cards and PayPal can be accepted by the customer entering their own data online. However, only payment cards can be accepted in-person, over the phone, or through the mail. It is important to understand how the various rules and processing methods impact departmental procedures and accounting, including how the revenue and related expenses are recorded on the University’s general ledger system.
The Cashier’s Office can answer questions regarding cost, processing options (online, stand-alone, mobile, software) and general procedures. Departments considering the acceptance of payment cards should contact the Cashier’s Office to discuss which methods of payment processing are most suitable for the type of activity being planned. The Cashier’s Office acts as a liaison between the departments, the processing companies, the card companies, PayPal, and the bank.
Registered student organizations sponsoring revenue-producing events or activities that involve the acceptance of payment (credit/debit) cards must have prior approval from the Controller’s Office regarding (1) the method of payment card acceptance (e.g., online, in-person, etc.), and (2) any vendors or third-parties involved in the payment card process. Registered student organizations are required to use University-managed solutions for accepting payment cards (e.g, Transact or PayPal).
The business decision whether to accept payment cards, ACH and/or PayPal resides with each department. However, the Controller’s Office must approve all new locations or applications. Important! Gift/donations can only be processed through University Advancement. For more information, refer to "Gifts" located in section 315 of the Manual of Business Procedures.
III. Payment (Credit/Debit) Cards
- Payment Card Industry Data Security Standard
- All merchants must be PCI DSS compliant. MSU reports compliance annually as a single entity. Therefore, if one Merchant is not compliant, MSU is not compliant.
- The PCI DSS was developed cooperatively by all major card brands. The PCI DSS provides specific framework for creating, maintaining and protecting a secure payment card environment. It has been endorsed and adopted by all the major card companies with which MSU does business. Pursuant to these agreements, MSU is contractually required to comply with the PCI DSS.
- Each Merchant is financially responsible for the cost of achieving and maintaining compliance.
- If a Merchant is found to be noncompliant at the time of a breach, the card companies can impose large penalties. Each Merchant is financially responsible for any penalties or costs associated with a breach.
- The PCI DSS document and additional information can be found at the PCI Security Standards Council
- Each Merchant must be familiar with the PCI DSS and all parts relevant to their method of card acceptance.
- PCI Steward – Each Merchant must designate a full-time MSU employee as their PCI Steward. The PCI Steward is responsible for ensuring the Merchant is compliant, including submission of the SAQ and monitoring staff training. Detailed description of the PCI Steward responsibilities is available on the eCommerce at MSU Website.
- Training – Each person involved with the acceptance of payment cards must be trained at the time of hire and at least annually thereafter. Training is free, mandatory, and available at https://secureit.msu.edu/train/pci-dss.html
- Merchant Agreement – Each Merchant is required to complete a Merchant Agreement for each Merchant or Location in the Central Online Application. The Agreement will be provided by the Cashier’s Office. It must be signed by the Dean, Director, Chairperson or Executive Manager and returned to the Cashier’s Office prior to the activation of each new merchant.
- Employee Security Statement – Merchant must require each person with access to cardholder data (employee, volunteer, etc.) to verify in writing that they understand and accept responsibility for the cardholder data. A sample form can be found on the eCommerce at MSU Website.
- Assisted Payments – Assisted Payments occur when a staff member enters card numbers into a Merchant-owned workstation (computer). This is generally not allowed. To be PCI-compliant, the workstation must be configured to allow access to only those applications necessary to process the card transaction. The workstation cannot allow email or Internet surfing. The workstation must have a hardware firewall device between it and any network to which it is attached. The workstation and firewall must have quarterly vulnerability scans. This requires the workstation and firewall to have fixed IP addresses. Instructions to properly configure the workstation can be requested from the Cashier's Office at PCIDSS@ctlr.msu.edu or 517-355-5023. Note: The workstation must be inspected and approved by the PCI Compliance Team prior to its use for Assisted Payments.
- SAQ – Each Merchant is required to complete and submit to the Cashier’s Office a Self-Assessment Questionnaire (SAQ). There are several versions of the SAQ that correlate to the manner in which cards are accepted and the complexity of the Merchant’s card processing environment.
- Choosing the Appropriate SAQ – Review the SAQ Instructions and Guidelines. In summary, MSU Merchants may be eligible for one of the versions as follows:
- SAQ A – Customer enters own card number on Merchant’s third-party hosted website and Merchant does not electronically store cardholder data. Example: Transact eMarket Storefront store. See the special instructions for a Transact Checkout store to become eligible to complete SAQ A.
- SAQ B – Merchant uses stand-alone, dial-out terminal and Merchant does not electronically store cardholder data. Example: Stand-alone terminal connected via analog or cellular phone line.
- SAQ B-IP – Merchant uses only stand-alone, PTS-approved payment terminals with a dedicated IP connection arranged and approved by the Cashier’s Office to the payment processor, with no electronic cardholder data storage.
- SAQ C-VT – Merchant using only web-based virtual terminals approved by the Cashier's Office and there is no electronic storage of cardholder data. Merchant must pay for annual penetration test arranged by the Cashier’s Office. Contact Cashier’s Office for assistance.
- SAQ C – Merchant uses payment application connected to the Internet where staff member enters card number and Merchant does not electronically store cardholder data. Merchant must pay for annual penetration test arranged by the Cashier’s Office. Contact Cashier’s Office for assistance.
- SAQ P2PE – Merchant uses only hardware payment terminals that are included in and managed via a validated, PCI SSC-listed P2PE solution, with no electronic cardholder data storage. Contact Cashier’s Office for assistance.
- SAQ D – All other Merchants not noted above or any Merchant that has electronic storage of cardholder data. Merchant must pay for annual penetration test arranged by the Cashier’s Office.
- Additional information can be found in the University Merchant Services Policy.
- Overview
- Security – Merchant accepts responsibility for the accuracy and confidentiality of the information that staff collect in order to process a sale.
- Card numbers should not be stored unless there is a strong business need to do so. Disputing Chargebacks is not considered a strong reason.
- CSC – Requesting the Card Security Code (CSC) number at the point of transaction is an important fraud prevention step. Merchants considering not capturing it should first consult with the Cashier’s Office.
- Storage of the CSC or magnetic stripe data is strictly prohibited by PCI DSS.
- Wireless – Use of wireless technology is strictly prohibited.The only allowable use of WiFi as part of the process to accept payment cards is the use of a PCI-validated Point-to-Point Encryption (P2PE) solution. See Section C.3.b.iv. and contact the Cashier’s Office for more information.
- Telephone – Receiving card data spoken verbally over a standard telephone is strictly prohibited. Contact the Cashier’s Office for instructions to have the phone lines added to the PCI-managed network.
- Fax – Receiving card data via fax is strictly prohibited.
- Email – Sensitive cardholder data should not be sent or received via email. If a customer provides their card data via email, (1) do not process it; (2) contact the customer to make other payment arrangements (e.g., provide card data online or over the phone, or use a non-card method); and (3) securely delete the email containing the card data from email and trash folders.
- Card Types – MSU presently has contracts with Visa, MasterCard, American Express, Discover and JCB. Debit cards with a Visa or MasterCard logo are also acceptable.
- Face-to-Face (Card Present) Processing – In most cases, the customer should handle their own card, using the tap-to-pay feature, EMV smart chip reader, or swiping it in the magnetic stripe reader of the card terminal or separate PIN pad. As needed, staff may key-enter the card data into the terminal. The Merchant can expect to be charged a slightly higher transaction fee from the card processor for a hand-keyed transaction.
- Mail Order/Telephone Order (MOTO or Card Not Present) – This is a hand-keyed transaction. At a minimum, Merchant must collect the following data before processing a card not present transaction:
- Card number
- Name as it appears on the card
- Card expiration date as it appears on the card
- Cardholder’s billing address
- Revenue – The funds due MSU as a result of card sales are deposited at gross directly to MSU’s bank account. In most cases, the revenue is credited automatically to the department’s general ledger account(s).
- The timing of ledger entry varies, depending on the processing method. The Central Online Application deposits the daily payment card revenue the following business day. For stand-alone terminal Merchants, the revenue is deposited the second business day. All other Merchants should use the Credit Card Receipt eDoc.
- To mitigate fraud, Merchants should reconcile payment card revenue at least daily.
Note: Full card numbers should not be entered into eDoc fields nor should any scanned documentation attached to an eDoc contain the full card numbers. Do not submit any documentation to either the Cashier’s Office or Accounting Office that contains a full card number.
- Expense – Expenses associated with card sales vary by solution. See each section for more detail.
Note: All external revenue is subject to the MSU Administrative Fee.
- Card Rates:
- American Express is about 2.10% and Discover is about 2.0%.
- The Visa, MasterCard, and Discover rates vary depending on many factors, including (but not limited to) whether the card was swiped or dipped, address verification, credit versus debit, and how timely the transaction was settled after it was authorized.
- Current Visa, MasterCard and Discover rates are posted under "Guidelines & Compliance - Payment Card Rates" on the eCommerce at MSU website.
- The card processing company also charges a minimal per transaction fee.
- Budget – Merchants are advised to budget about 3% for Transact and stand-alone payment card expenses.
- Merchant Services – Merchant will be assessed a minimal percent of all payment card revenue to support central management of merchant services and compliance with PCI DSS. The current fee is .14% (.0014) of all payment card revenue and .16% (.0016) of all eCommerce (Transact and Eventbrite) payment card revenue.
- Chargebacks – Chargebacks occur when the customer challenges the validity of the original charge and instructs/requests the card company to reverse it. The funds are deducted from MSU’s bank account. The Cashier’s Office will debit the departmental account accordingly. It is the department’s responsibility to make other payment arrangements with the customer.
- Credits (Returns) – When a refund is authorized for a customer, it should be processed as a refund to the same card that was used for the original transaction. Departments will receive partial refund of fees when they process a credit back to the customer. The refund is netted against all other fees on the monthly entry to distribute fees.
- Record Retention – Storing card numbers is discouraged, as there generally is not a strong business reason to store card numbers. If a Merchant chooses to store card numbers, the recommended retention is 6 months and never more than 18 months.
- Inventory – Merchants must maintain an inventory of all system components that are involved in the processing, storing or transmitting of card data. For hardware, this includes make and model, location, serial number, merchant number and terminal ID number.
- Help – For questions related to accounting, getting started, or PCIDSS contact the Cashier’s Office at 355-5023 or PCIDSS@ctlr.msu.edu. For technical support regarding the Central Online Application, contact the IT Service Desk at 517-432-6200 or ithelp@msu.edu.
- Glossary – There is a glossary of terms at section VI.
- Security – Merchant accepts responsibility for the accuracy and confidentiality of the information that staff collect in order to process a sale.
- Processing Options
- ONLINE (eCOMMERCE)
- Transact eMarket
- Recommended Use - This is the preferred online solution for all non-event activity except when the card is present.
- Information - For overview, options, forms, training, etc. go to the eCommerce at MSU website and see the section on eCommerce Services.
- Storefront Model - Website is hosted on Transact server and Merchant is eligible to complete SAQ A. This is the recommended type, as it is easier to set up and maintain.
- Checkout Model - Customer begins on MSU website and is transferred to Transact at point of payment. Only suggested for departments with dedicated technical support. Merchant is eligible to complete SAQ A after submitting the source code of the website for review and confirming proper access management.
- Website Technical Requirements
- Your payment or checkout page must be served from an MSU-hosted web site or a third-party provider that has been pre-approved by the Cashier’s Office.
- MSU-hosted pages must submit source code for review annually.
- Third-party-hosted pages must provide evidence of PCI compliance prior to go-live and annually thereafter.
- This page is usually the last page the customer interacts with before the processor's payment page is displayed in the customer's browser.
- Your payment/checkout page which transfers the customer to the Transact page cannot collect any card data.
- Your payment or checkout page must be served from an MSU-hosted web site or a third-party provider that has been pre-approved by the Cashier’s Office.
- Send MSU-hosted web page source code documentation to: PCIDSS@ctlr.msu.edu.
- Your documentation must include:
- the web server’s IP address,
- the web address of your e-commerce site, and
- the URL of your payment/checkout page.
- Your documentation must contain a plain ASCII HTML file of the entire web page, as produced by pressing Ctrl-U (View page source) in either Firefox, Chrome, or Internet Explorer. Copy and paste this into Windows Notepad or a similar plain text editor and save.
- In your e-mail, provide the line number for the location in the code where your web page directs the student/customer/donor to the payment processor. The Ctrl-U (View source) function in your web browser provides the line numbers on screen.
- Please include the four-digit store number (e.g., 3123) in the subject line of the email.
- Your documentation must include:
- Access Management
- Remove any unnecessary default accounts and change any default passwords
- Assign each user with access to your web server (including content management systems) a unique login that is paired with a password that is at least 7 characters long and alphanumeric
- Remove and prohibit any shared or generic accounts
- Immediately disable or remove terminated users’ accounts
- Have a policy in place that requires you to notify the MSU Information Security Incident Response team of any suspected security incident immediately.
- Website Technical Requirements
- Activation – Activation is a two-step process. The eCommerce Request Form must be completed first. The test location will be made available. The new Location will be activated after the Merchant Agreement and appropriate SAQ are received and approved by the Cashier's Office. Merchant will be notified by email after the Location has been set up.
- Access – Once set-up is complete, the security administrator for that department must complete an Access Request Form to authorize users for that certain Location.
- Training – Online training is available on the eCommerce site under Transact Payments Training.
- Card Types – All card types are already set-up and available for each Location. Debit cards with a major card brand logo are acceptable and will be processed as a credit transaction.
- ACH
- ACH is added to a Transact store by request only. Unlike payment cards, an ACH transaction does not verify the funds are available at the time of the transaction. In the event an ACH fails to be processed by the customer’s bank, the outstanding payment is treated like a returned paper check. It will be forwarded to the Cashier’s Office Returned Checks/ACH department for processing. See Section 14 for Returned Checks/ACH Payments.
- For this reason, it is strongly recommended that transactions completed via ACH through Transact are NOT refunded until the Merchant confirms with the Cashier’s Office that the ACH payment has not been returned by the bank. Otherwise, the customer might be refunded for a payment that MSU never received.
- Card Security Code (CSC) – The 3-4 digits on the back of a card (on the front of an American Express card). It is strongly recommended that each Location require this information at the point of transaction. However, it should never be stored.
- Assisted Payments – Occur when a staff member enters card numbers into a Merchant-owned workstation (computer). This method is not approved for general use. Cashier’s Office approval required.
- To be PCI-compliant, the workstation must be configured to allow access to only those applications necessary to process the card transaction. The workstation cannot allow email or Internet surfing. The workstation must have a hardware firewall device between it and any network to which it is attached. The workstation and firewall must have quarterly vulnerability scans. This requires the workstation and firewall to have fixed IP addresses. Contact the Cashier’s Office for instructions to properly configure the Workstation.
- The workstation must be inspected and approved by the PCI Compliance Officer prior to its use for Assisted Payments.
- Revenue
- Revenue is automatically credited to the departmental account for every day that transactions are processed on the Central Online Application.
- End-of-Day processing occurs at 6 PM every day. Any transactions occurring after 6 PM are credited to the next business day.
- Revenue should be reconciled at least daily to mitigate fraud.
- The ledger description will indicate the Location number. The Location number is included so that it can be distinguished from another activity if there are multiple Locations crediting revenue to the same ledger account.
- The revenue account and revenue object code are provided during set-up, but can be changed at any time by someone with access to change the store’s settings (referred to as All Access on the Access Request Form).
- Cost
- There are no start-up, supply or minimum monthly costs.
- The cost is about 2.5% of net revenue. Components are discount fees, online processor fees, and merchant services fee.
- Merchants pay only for the days in which they process transactions in Transact and have net sales activity. Merchants will receive a return of fees on those days when refunds exceed sales.
- Expenses are charged to the departmental account in the subsequent month (e.g., March fees will post to the April ledgers).
- Expenses can be charged to a single general ledger account or to the same account(s) where the revenue is posted.
- Note: All external revenue is subject to the MSU Administrative Fee.
- EVENTBRITE
- Recommended Use – This is the preferred online event management solution, for both free and paid events.
- Information – for overview, forms, training, etc., go to the MSU Eventbrite section on the eCommerce at MSU website.
- Setup – Upon receipt of a new event request (see the Eventbrite Event Request Form), the Cashier’s Office will initiate the basic event, including event name, unique code, and banking information. Merchant is responsible for all other design and configuration.
- Revenue – is credited to the departmental account about 10 days after the event has ended. This allows time for Eventbrite to process any refunds, if applicable.
- Cost
- Is charged at the same time as the revenue (about 10 days after the end of the event). Note, there are no fees for free events.
- Is comprised of:
- Eventbrite fees of 1% plus $.99 per ticket sold, but no more than $9.95 per ticket.
- Card processing fees of 3%.
- MSU PCI and IT fees of .14% and .16%, respectively.
- Transact eMarket
- STAND-ALONE TERMINALS
- Recommended Use – Preferred method when card is present. Also appropriate for Merchants that process orders received via mail or phone.
- Terminal Connection Options
- Cellular – Terminal specifically designed to only accept payment cards over cellular network with WiFi disabled. NO other mobile device is allowed. Merchant is responsible for the cost of the monthly cell phone plan included with processing fees.
- IP – Terminal configured with PCI-validated point-to-point encryption (P2PE) connected via a dedicated Ethernet connection or connected to the MSU IT hosted VLAN. Merchant is responsible for cost of installing and maintaining the Ethernet cable. Configuration must be pre-approved and arranged by the Cashier’s Office.
- P2PE – Point-to-Point Encryption. Beyond simply encrypting the card data, a P2PE solution has been validated by the PCI Council. A validated P2PE solution utilizes a proprietary encryption method with strict decryption policies and strong device management controls. These features can significantly reduce the scope of the Merchant’s card processing environment. It can be used in a stand-alone setup or, at the Merchant’s expense, integrated with the Merchant’s local point-of-sale or cash register system. Contact the Cashier’s Office for more information.
- Set-up – Complete and return the
Merchant Request Form to the Cashier’s Office via email: PCIDSS@ctlr.msu.edu. Information to complete the form includes:
- Name for new Merchant and contact information.
- PCI Steward’s name, NetID, phone number and email address.
- Methods of card acceptance.
- MSU account number and object code for automatic revenue deposits.
- MSU account number that will be charged for all applicable fees.
- An estimate of the anticipated annual dollar volume.
- An estimate of the average individual transaction amount.
- Hardware model being requested to purchase or reprogram.
- Activation – The Cashier’s Office staff will forward this information to the processor who assigns a new Merchant number. The Cashier’s Office will notify the department when the hardware and instruction manuals and/or new programming are available, usually within two weeks.
- Operations – An operating manual will be sent to each Merchant. It is important that each person who will process payments read the Merchant’s operating manual.
- Card Types – The terminal will come programmed to accept Visa, MasterCard, Discover, American Express and JCB. This includes regular credit cards and debit or gift cards with the logo of one of these major card brands.
- Costs – Charged to departmental account in the month subsequent to when incurred.
- Hardware – Costs will vary by type (stand-alone, cellular, P2PE). Contact the Cashier’s Office for current prices.
- Discount Fees – Comprised of a percentage and a fixed, per transaction fee.
- Revenue
- The Merchant must settle and transmit the data each day. The gross sales revenue is deposited directly into MSU’s general operating bank account.
- The Cashier’s Office will automatically deposit the sales revenue to a single MSU ledger account. The deposit will occur 1-2 days after the batch is settled and the settlement date will be noted in the line description. To capture the weekend, Monday’s posting will include Friday and Saturday activity, and Tuesday’s posting will include Sunday and Monday activity.
- Revenue should be reconciled at least daily to mitigate fraud.
- OTHER SOLUTIONS
- Use of any third party for processing, storing or transmitting payment card data must be approved in advance by Purchasing, MSUIT and the Cashier’s Office. All vendors must submit a Service Provider Security Assessment before the contract can be signed or renewed.
- Merchants will be allowed to use only those service providers and applications that have been validated as being PCI-compliant. A list of validated level 1 solutions is available on the Visa Global Registry of Service Providers website.
- Revenue
- Merchants that interface with MSU’s processor will have the revenue automatically deposited as described in C.2.h.above.
- Merchants that use a processor other than MSU’s will have to use the Credit Card Receipt eDoc to post the revenue. Documentation of the Batch Settlement Report must be attached to the CCR eDoc.
- Revenue should be reconciled at least daily to mitigate fraud.
- Merchant is responsible for recording applicable expenses. Cashier’s Office will assess PCI fee on a monthly basis.
- LOANER TERMINALS
- There are occasions when a department has a limited need for accepting credit cards in person; for example, onsite registration for a one-time only or once-a-year conference. In cases where using the Central Online Application is not feasible, the Cashier’s Office has several loaner terminals available on a first-come-first-serve basis. Contact the Cashier’s Office at 517-355-5023 regarding terminal availability and the sign-out process.
- The department is responsible for ensuring that PCI DSS guidelines are followed.
- The cost to use a loaner terminal is 3.5% of the net total payment card revenue processed through the loaner terminal. This includes the equipment rental cost and the payment card processing fees charged by MSU’s card processor. The fees are charged in the same month as the revenue.
- The department is responsible for settling the transactions in a timely manner. Settlement reports should be forwarded to the Cashier’s Office for credit to the department’s account.
- The department is responsible for any Chargebacks that result from transactions that were processed during the time the terminal was borrowed. An adjusting entry will be created as needed and routed to the department for a response, if necessary.
- ONLINE (eCOMMERCE)
IV. PayPal
Contact the Cashier’s Office for information about accepting PayPal as a payment type under the University’s contract with PayPal. Departments will be provided with guidelines to add a PayPal checkout button on their own website. Cashier’s Office must pre-approve website before launch. Note, PayPal as a gateway provider is not currently available.
V. ACH
- Overview
- Rules – Federal regulations direct how the banking system manages the ACH process, which in turn determines MSU’s procedures.
- Online Only – ACH acceptance is available online only through the Central Online Application or other application. Departmental staff cannot accept the banking information over the phone or in the mail and then enter it on behalf of the customer. For additional information on Transact, go to the Transact webpage.
- Revenue – The funds due MSU as a result of ACH sales are credited directly to MSU’s bank account. The revenue is automatically credited to the department’s general ledger. There will be an entry for each business day that an ACH batch is sent to MSU’s bank. The end-of-day process occurs at 6 PM. Any transactions after that time will be posted as the next business day.
- Availability – Unlike payment cards, an ACH transaction does not verify the availability of funds before processing the request and giving the seller credit. ACHs are treated the same as paper checks; that is, the funds are not truly valid until the ACH clears the issuer’s bank account.
Note: For this reason, it is strongly recommended that transactions completed via ACH through Transact are NOT refunded until the Merchant confirms with the Cashier’s Office that the ACH payment has not been returned by the bank. Otherwise, the customer might be refunded for a payment that MSU never received.
- Returns – In the event an ACH fails to be processed (e.g., nonsufficient funds, account not found, etc.), it is treated the same as a paper check and referred to the Cashier’s Office for collection. Refer to MBP Section 14.
- Cost – The cost to process an ACH is minimal and centrally funded. There is no cost to departments but departments need to consider that customers will be charged a fee in the event of a returned ACH.
- Help – For questions related to accounting or getting started, call the Cashier’s Office at 355-5023. For technical support regarding the Central Online Application, contact the IT Service Help Desk at 432-6200.
- Glossary – There is a glossary of terms at section VI.
VI. Glossary of Terms
ACH (Automated Clearing House) – Refers to an individual debit to a customer’s bank account that is batched with similar transactions and sent to MSU’s bank for automated processing similar to paper checks. Also referred to as an e-check.
Assisted Payments – Where Merchant staff or representative (e.g., volunteer) enters card numbers on a Merchant-owned computer. The computer must be a Dedicated Workstation (see definition below).
Authorized – The status of a credit/debit card transaction that has been approved by the processor for the amount requested.
Batch – One or more payment card transactions grouped for settlement.
Batch Settlement Report – The report generated by a stand-alone terminal after a payment card batch has been successfully transmitted to the processor.
Card Company (or Association) – Visa, MasterCard, American Express, Discover or JCB.
Card Processing Company (Processor) – Third-party provider that receives settled batch data from Merchants and forwards them to the appropriate card companies (e.g., Visa, MC).
Card Security Code (CSC) – The additional 3-4 digits usually on the back of a card (on front of American Express) that is not part of the card number. May also be referred to as CCC, CSSC or CVC. Used to minimize fraud when the card is not present.
Cardholder – The customer; the person whose name appears on the card being used to purchase goods or services.
Cardholder Data – Defined for PCI DSS purposes as the full card number. Also includes any identifying data if used or stored along with the card number (such as name, expiration date, address, etc.).
Central Online Application – The pre-approved online payment application for which set-up and training are centrally supported. Current application is CASHNet.
Chargeback – A transaction generated by the card company at the customer’s request to take money out of MSU’s bank account and return it to the cardholder.
Credit – A payment card transaction generated by the Merchant to return some or all of the original purchase amount back to the cardholder.
Debit Card – Cards with the logo of one of the major card brands are accepted and processed as a debit transaction (with PIN or signature – also referred to as “online”) or as a credit transaction (without PIN – also referred to as “offline”).
Dedicated Workstation – A Dedicated Workstation is required whenever card numbers are entered into a computer (workstation), a process referred to as Assisted Payments (see definition above). To be PCI-compliant, the workstation must be configured to allow access to only those applications necessary to process the card transaction. The workstation cannot allow email or Internet surfing. The workstation must have a hardware firewall device between it and any network to which it is attached. The workstation and firewall must have quarterly vulnerability scans. This requires the workstation and firewall to have fixed IP addresses. Contact the Cashier's Office for instructions to properly configure the Workstation. Note: The workstation must be inspected and approved by the PCI Compliance Officer prior to its use for Assisted Payments.
Discount Fees – The fees a Merchant pays to the credit card processing company for the service of processing credit/debit card transactions. Can be comprised of both variable (percentage) and fixed (per transaction) fee components. Often stated as an “add-on” to the Interchange Rates.
EMV – Stands for Europay-MasterCard-Visa, the three companies that created the technical standards for using integrated circuits rather than magnetic stripes to store data. EMV cards are also referred to as smart or chip cards. See PNC Bank EMV (Chip) Cards FAQs on the eCommerce at MSU for more information.
Interchange Rates – The fees established by Visa and MasterCard for the service of paying the Merchant immediately while extending credit to Cardholders. Generally comprised of both variable (percentage) and fixed (per transaction) fee components.
Location – In the Central Online Application, refers to a certain activity that the Merchant defines. Each Location is identified by a unique location number by the Cashier’s Office. Same as Store.
Merchant – Any department that accepts payment cards, identified by a unique number that has been assigned by the credit card processing company or the Cashier’s Office. In the Central Online Application it is the same as Location.
Merchant Number – The number assigned by a card company that uniquely identifies a specific activity. In the Central Online Application, there is one shared Merchant number for all Locations. Stand-alone terminal Merchants have individual Merchant numbers for each function or location. Visa, MasterCard and Discover share the same Merchant Number, but American Express issues a separate Merchant Number. Also referred to as Merchant ID or MID.
P2PE - Acronym for Point-to-Point Encryption. A P2PE solution is provided by a third party solution provider, and is a combination of secure devices, applications and processes that encrypt data from the point of interaction (for example, at the point of swipe or dip) until the data reaches the solution provider’s secure decryption environment.
Pending – In the Central Online Application, the status of a transaction that has been authorized but not yet settled.
PIN Debit - Debit card transaction where the customer enters a Personal Identification Number (PIN) on a PIN pad rather than providing a written signature to confirm the transaction. Also referred to as an “online debit” transaction.
Processor – See Card Processing Company
PTS - Acronym for PIN Transaction Security, PTS is a set of modular evaluation requirements managed by the PCI Security Standards Council for terminals that accept PINs.
Self-Assessment Questionnaire (SAQ) - Form used by merchants to document assertion of compliance. Must be completed at least annually and submitted to the Cashier's Office. Contact the Cashier’s Office for online access.
Settled – The status of a transaction once the Card Processing Company has processed it. Could refer to a sale or a credit transaction. Settled transactions are those that will show on the Cardholder’s monthly statement.
Status (of credit/debit card or ACH transaction) – Indicates which stage of the process a transaction is in. It can be authorized, pending, settled or void.
Store – In the Central Online Application, same as Location.
Terminal – Another name for the electronic data capture machine or an individual PC on an automated software application.
Terminal Number – Each terminal is assigned a unique number by the card processor that is printed on receipts and reports so that transactions can be traced back to a specific terminal. Often abbreviated as TID.
Transmit – The act of sending payment card batch data for settlement on a stand-alone terminal.