format_list_bulleted Topic Overview

Accepting Credit and Debit Card Payments

Merchant Services (MS) collaborates with Stanford departments to help them establish merchant accounts and securely process credit/debit card payments for their products and services. There are important factors merchants must consider when beginning to accept credit/debit card payments through platforms like Stripe and others. These 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 payments. 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 for details.

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 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 credit cards in a safe and compliant manner. See Bank Fraud Prevention for information on preventing credit card fraud.

Please use the guideline below to determine what processing method is appropriate.

Processing Method    Description
Point-of-Sale (POS) 
  • The customer presents the payment card in person (insert, swipe or use contactless payment such as digital wallet). Customers can use the Stanford acquiring bank provided or approved third party provided stand-alone credit card terminals.
  • Requires approval from MS, ET Compliance and Information Security Office if a new POS system, with its proprietary equipment, is considered.
  • Refer to Resource: Point-of-Sale Merchants for details.
  • Customers directly input payment card or digital payment data online.
  • Can use approved third-party service providers (TPSP) which are payment gateway compatible with Stanford acquiring bank’s processor, Wells Fargo Merchant Services. Their preferred payment gateway is CyberSource. 
  • Requires approval from MS, ET Compliance, and the Information Security Office (ISO) if a new TPSP is considered or a web store is built by IT Services (UIT) resources.
  • Refer to Resource: Ecommerce Merchants for details.
Mail Order / Telephone Order (MOTO) 
  • Customer is not present at the time of purchase; the merchant manually inputs payment card data through a point of sale terminal or online software.
  • VoIP work phones are not PCI compliant; cellular based phones or analog (wired) phones are compliant.
  • Requires use of Stanford acquiring bank gateway services or approved third party stand-alone credit card terminals.
  • An online “virtual” terminal via a payment gateway using available network segmentation.
  • Requires approval from Merchant Services and ET Compliance.

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
    • 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
Note: For events, University IT (UIT) offers Cvent, an approved third-party robust events management platform at Stanford. 

Approved Description
Bidding For Good (with Stripe)
  • BiddingForGood auctions are managed and processed through an all-in-one-digital fundraising platform.
  • Platform provides a choice of integrated processors including Stripe. Select Stripe before an auction home page goes live to sell tickets and accept cash donations.
  • E-commerce only and mobile payment friendly.
  • All credit card data is entered on an order page that is hosted on CyberSource's secure server.
  • After a payment transaction has been completed, the Secure Acceptance solution will return transaction identifiers back to the storefront website. 
  • Transaction details are viewable in CyberSource  business center. Refer to Resource: E-Commerce Merchants for more information.
  • Point-of-sale terminals are credit card swipe, dip or tap terminals. Terminals used on campus must be provided by Wells Fargo approved vendors.
  • Terminals require an analog phone line [a voice over internet protocol (VOIP) line is not compliant for use in transmitting credit card data]. 
  • Wireless terminals, which use a secure, proprietary network provided by Wells Fargo, are also available. See Point-of-Sale Merchants for details.
Encrypted Keypad
Shopify (with Stripe)
  • Create an online store with Shopify and accept credit cards with Stripe.
  • Payments can be accepted for course registration, merchandise,  admission deposit, program tuition, miscellaneous fees.
Slate (with Stripe)
  • Slate provides a built-in payment processing platform, Slate Payments, that can be used to accept payments by credit card, debit card, or electronic check.
  • The Slate Payments Deposit Account is a holding account with Stripe (a connected account on the Slate Payments platform) where your funds are held until transferred to you. Funds are collected, held, and paid out in separate sub-balances depending on the payment method.
  • Payments can be accepted for program tuition, application fees, and admission deposits.
  • Payment link is the Stripe hosted payment page by product. E-commerce only and mobile payment friendly. Link can be converted to a QR payment at point-of-sale.
  • Invoicing is the direct bill payment for a manageable number of customers/vendors. Ecommerce only and mobile payment friendly.
  • Learn more about Stripe Payment Solutions and CardinalPay for Stanford-managed Stripe accounts.
  • Please submit a support request to Merchant Services to set up the account.

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 via 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 via Cybersource virtual terminals. See Point-of-Sale 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

Rental fee ($49.99 per device) with one-time activation fee ($25), and monthly access fee ($15 per month) 

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 one of the three terminals available from Treasury’s loaner program, subject to availability. See Point-of-Sale Merchants for details.

eCommerce Platforms Each ecommerce 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, eCommerce 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

Credit card processing cycle 1

In the authorization and authentication stage, the merchant must obtain payment approval from the issuer. Here are the roles and processes:

  1. Cardholder: The cardholder pays the merchant for a purchase with a credit or debit card. 
  2. Merchant: The merchant uses its credit card machine, software or gateway to transmit the card’s detailed information to the acquirer (or its processor). 
  3. Acquirer: The acquirer (or its processor) forwards the card’s detailed information to the appropriate card network. 
  4. 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.
  5. Issuer: The issuer validates cardholder account, approves or declines the transaction and places a hold for purchase amount on the cardholder’s account. 
  6. Card Network: The issuer sends back the appropriate authorization response through the appropriate card network to the acquirer (or its processor).
  7. Acquirer: The acquirer (or its processor) forwards the authorization response to the merchant’s terminal, software or gateway.
  8. 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

Credit card processing cycle 2

The clearing and settlement occurs after the authorization process takes place. Here are the roles and processes:

  1. Merchant: At the end of each business day, the merchant sends approved authorizations in a batch to its acquirer (or processor).
  2. Acquirer: The acquirer (or processor) routes the batch information to the card network for settlement.
  3. Card Network: The card network forwards each approved transaction to the appropriate issuer. 
  4. Issuer: The issuer transfers the funds through the Card Network less interchange fees. 
  5. Card Network: The card network pays the acquirer (or processor) its percentage of the remaining funds.
  6. Acquirer: The acquirer deposits the funds from sales into the merchant’s bank account via automated clearinghouse (ACH) and debits the merchant’s account for processing fees either monthly or daily.
  7. Issuer: The issuing bank posts transactions to the cardholder’s account. The cardholder receives the statement and pays the bill.


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. For more information, review the Resource: Credit and Debit Card Decline.


A 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. For more information, refer to Resource: Credit and Debit Card Chargeback. To learn about preventing fraudulent credit card activity, see Bank Fraud Prevention.


Refund methods are available for merchants that would like to refund a transaction previously processed in-person point of sale or online. Merchants should obtain the supervisor’s approval to authorize the refund. For more information, refer to Topic Overview: Issuing Refunds to Credit and Debit Cards.

Last Updated: May 10, 2024