Merchant Services (MS) provides payment solutions and operational support for Stanford departments to securely process incoming credit, debit card and digital transactions for university products and services. There are important factors merchants must consider when beginning to accept card and electronic payments like Stripe and others. These factors include establishing roles and responsibilities for the process, determining payment method and the associated fee structure, and using third-party service providers. To learn more about Merchant Services, see Merchant Services Program.
Stanford merchants are required to maintain compliance with university policies and must review the Administrative Guide prior to processing transactions. These ensure protection of Stanford's information resources, outline procedures to be followed when a computer security incident is discovered, provide guidance on proper engagement in unrelated business activities, and ensure relationships with entities independent of the university are structured correctly. See the Administrative Guide Policy 3.4.2: Card and Payment Account Acceptance and Processing.
FMS also offers the Card Services program, which is intended to support PCards and TCards that are used as university payment methods. Department merchants who accept credit and debit cards to collect payments for university goods and services are not part of that program. For more information on purchasing and traveling on behalf of the university, visit the PCards Overview or TCards Overview.
To better understand the process of a credit or debit card transaction, it is necessary to learn the key players involved:
- Cardholder: Non-consumer or consumer customer to whom a payment card is issued or any individual authorized to use the payment card
- Merchant: Any business that maintains a merchant account that enables them to accept credit or debit cards as payment methods from customers (cardholders) for goods or services
- Acquirer: Also referred to as “acquiring bank” or “merchant’s bank,” acquirers contract with merchants to create and maintain merchant accounts that allow the business to accept credit and debit cards; provide merchants with equipment to accept cards and manage customer service and other necessary aspects involved in card acceptance; deposits funds from card sales into a merchant’s account
- Processor: Sometimes referred to as “payment gateway” or “payment service provider (PSP)”; entity engaged by acquirers to handle credit and debit card transactions on their behalf
- Issuer: Also referred to as “issuing bank” or “cardholder’s bank”; entity that issues credit or debit cards to consumers and pays acquiring banks purchases that their cardholders make; it is the cardholder’s responsibility to repay their issuing bank under their credit card agreement
- Card Network: Entity that controls where credit or debit cards can be accepted and facilitates transactions between acquirers and issuers; four major card networks include Visa, Mastercard, Discover and American Express; Card networks are not banks, and they do not issue credit cards or merchant accounts
Prior to accepting credit cards, determine what’s being sold, the prices, and options for accepting and processing payments. Determining how and where to accept payments is an important consideration. The Payment Card Industry – Data Security Standards (PCI DSS) sets very specific rules on how high-risk cardholder data is managed. Selecting the appropriate method helps merchants accept payments in a safe and compliant manner. Learn more about preventing credit card fraud.
Please use the guideline below to determine what processing method is appropriate.
| Processing Method | Description |
|---|---|
| Point-of-Sale (POS) |
|
| E-commerce |
|
| Mail Order / Telephone Order (MOTO) |
|
A merchant of record (MOR) is a legally recognized entity that sells goods or services to a customer; and to whom the customer owes payment for such goods and services. A MOR is obliged to process any payments and takes on the liability related to those transactions which include collecting sales tax, ensuring payment card industry (PCI) compliance, and honoring refunds and chargebacks timely.
General Guidance
- The Office of the Treasurer at FMS partners with ISO and P2P in the selection of Stanford-approved vendors who are centrally supported and accepted for deployment on campus (see Approved Third-Party Service Providers below).
- Vendors must be PCI compliant upon initial assessment and agree to maintain compliance exhibited by providing annual compliance documents upon request
- Payment receipts must be transmitted to Stanford’s main bank account on a timely basis
- Vendor integration with Stanford’s preferred merchant acquirer/processor/payment gateway, will make Stanford the MOR with:
- Wells Fargo Merchant Services/First Data Nashville/CyberSource or Authorize.net
- Stripe
New Vendor as Merchant of Record
Vendor requirements to serve as a MOR for Stanford:
- Evidence and justification that vendor already on the approved vendor list do not meet the business need/s (see Approved Third-Party Service Providers below)
- Vendor cooperates fully and timely in providing the documentation required to determine their level of compliance with the objective and subjective criteria required to become a MOR
- Vendor agreement stipulates that the university’s money is physically and legally separated from third-party vendor operational money
- Vendor is PCI compliant upon initial assessment and agrees to provide annual compliance documents upon request
- Vendor demonstrates financial soundness, viability, and substantiates themselves as an industry leader and as a future going concern
- Payment volume in the view of MS is modest and it is determined that the impact to university operations are limited should the vendor fail financially
- Payment receipts are transmitted to a dedicated Stanford bank account in a timely manner (ACH debits to university owned bank accounts are prohibited)
- Vendor offers a competitive card processing fee
- May be subject to an incremental Merchant Services fee and/or performance hurdle requirements upon evaluation
Learn more about the payment capability and data risk assessments for Third-Party Vendor Evaluation.
The Office of the Treasury (OOT) centrally manages Stanford University’s relationship with its acquiring bank to facilitate processing services that meet department needs and adhere to industry and institutional data security standards. All Stanford entities that accept credit cards must use Stanford’s acquiring bank and an approved vendor for gateway and front-end software and services. Leveraging existing relationships and proven products allows departments to expedite new merchant account set ups, limit counterparty risk and maintain compliance.
The following approved vendors are centrally supported by MS and are acceptable for deployment on campus. Please contact MS for information prior to engaging the service. If there is a vendor not listed below that you feel is essential to your business, learn more about the criteria and steps for a Third-Party Vendor Evaluation.
| Approved | Description |
|---|---|
| Bidding For Good (with Stripe) |
|
| CardinalPay (with Stripe) |
|
| CyberSource |
|
| Clover |
|
| Cvent |
|
| Encrypted Keypad |
|
| Shopify (with Stripe) |
|
| Slate (with Stripe) |
|
| Stripe |
|
| Other |
|
It’s important that merchants consider the associated fee structure when reviewing the available processing method options.
| Fee Type | Description |
|---|---|
| Credit Card Processing (All Merchants) | Processing fees are billed on a monthly basis. Credit card processing fees are typically 2.5% to 3% of credit card revenue. Generally these are debited from your department’s PTA on the 10th business day of the month following the month in which they were incurred. |
| Stanford Merchant Services Fee | Billed monthly at 0.8% of the prior month's card revenue through an iJournal to your department's PTA with an expense type of 58502 (Stanford Merchant Services Fee). This fee is assessed by the university on all credit/debit card and digital payment revenue collected through any channel. |
| Terminals for Purchase | Merchants can use a physical point-of-sale (POS) device or terminal to accept in-person and/or mail-order-telephone-order (MOTO) card payments or use Point-to-Point Encrypted (P2PE) keypads (aka: SREDKeys) for processing transactions through Cybersource virtual terminals. See Point-of-Sale Solutions for Stanford Merchants for information on device types, cost, usage, and maintenance. Note: Departments are solely responsible for obtaining the equipment pricing provided by other approved third-party service providers. |
| Terminal for Rental | If you need up to three devices, you can rent point-of-sale devices from Merchant Services. Rental fee will not be charged for the month, if terminals are ordered after and/or returned before the 20th of the same month. No fees are charged if departments borrow a terminal available from Treasury’s rental program, subject to availability. |
| E-commerce Platforms | Each e-commerce site may have their own additional processing fees. Departments are responsible for determining pricing provided by approved third-party website providers. |
Credit or debit card transactions are processed through a variety of platforms used by a merchant, including point of sale terminals, e-commerce, and telephone or mail. The entire processing life cycle from the time the card is dipped/swiped/tapped/keyed until a receipt is produced takes place within 2 to 3 seconds. There are two stages in the transaction process.
Stage 1: Authorization and Authentication
In the authorization and authentication stage, the merchant must obtain payment approval from the issuer. Here are the roles and processes:
- Cardholder: The cardholder pays the merchant for a purchase with a credit or debit card.
- Merchant: The merchant uses its credit card machine, software, or gateway to transmit the card’s detailed information to the acquirer (or its processor).
- Acquirer: The acquirer (or its processor) forwards the card’s detailed information to the appropriate card network.
- Card Network: The appropriate card network requests payment authorization from the issuer. The authorization request includes card number, card expiration date, billing address, card security code, and payment amount.
- Issuer: The issuer validates cardholder account, approves or declines the transaction, and places a hold for purchase amount on the cardholder’s account.
- Card Network: The issuer sends back the appropriate authorization response through the appropriate card network to the acquirer (or its processor).
- Acquirer: The acquirer (or its processor) forwards the authorization response to the merchant’s terminal, software or gateway.
- Merchant: The merchant receives authorization response and provides the cardholder a receipt to complete the sale if it is approved. All authorized transactions are stored in a batch file awaiting settlement.
For more information and to learn about the account process, refer to Topic Overview: Merchant Account Life Cycle.
Stage 2: Clearing and Settlement
The clearing and settlement occurs after the authorization process takes place. Here are the roles and processes:
- Merchant: At the end of each business day, the merchant sends approved authorizations in a batch to its acquirer (or processor).
- Acquirer: The acquirer (or processor) routes the batch information to the card network for settlement.
- Card Network: The card network forwards each approved transaction to the appropriate issuer.
- Issuer: The issuer transfers the funds through the Card Network less interchange fees.
- Card Network: The card network pays the acquirer (or processor) its percentage of the remaining funds.
- Acquirer: The acquirer deposits the funds from sales into the merchant’s bank account through automated clearinghouse (ACH) and debits the merchant’s account for processing fees either monthly or daily.
- Issuer: The issuing bank posts transactions to the cardholder’s account. The cardholder receives the statement and pays the bill.
Decline
A credit or debit card decline occurs when the payment cannot be processed for a particular reason. The transaction can be declined by the payment gateway, the acquirer (or its processor) or most commonly the issuer.
Refund
Stanford merchants can issue a refund for a transaction previously processed in-person through a point of sale or online. Merchants should obtain the supervisor’s approval to authorize the refund.
Chargeback
A credit or debit card chargeback occurs when a cardholder disputes a certain charge posted to their account. It is usually a result of criminal fraud or friendly fraud, but may also occur due to merchant errors.
Identifying card fraud activity
This list of fraud indicators is directly useful to department merchants, especially e-commerce merchants:
- Big-ticket items or high volume (high resale value)
- Similar account numbers (possible generated numbers)
- Multiple transactions in a short period (“run a card”)
- One billing address with multiple shipping addresses or multiple cards for the same address
- Multiple cards from a single IP address
- “Carding” behavior (many low-dollar transactions to validate stolen numbers)
Submit a support request to Merchant Services to evaluate fraud prevention options, such as:
- Implement a card verification value (CVV) and/or an address verification service (AVS) security step
- Consider setting a minimum transaction amount to $10 or higher when possible
- Block the IP addresses of known frauds
- Implement CAPTCHA to prevent attackers from using the automated system to run a batch of credit card numbers
Handling fraudulent transactions
If you suspect any fraudulent financial activities on your ecommerce website, immediately:
- Report suspicious activities
- Refund the successfully settled fraud transactions immediately to manage the impact of potential chargebacks. Be sure to keep documentation on refunds in case it is needed for any future investigation.