IMPORTANT: Stanford purchasing cards (PCards) and travel cards (TCards) are not a part of the Merchant Services Program. They are a tool for individuals making purchases and traveling on behalf of the university and are managed by Card Services. For more information on PCards, refer to PCards Overview and for information on TCards, refer to TCards Overview. For assistance, submit a support request.
When goods or services are purchased from Stanford using a credit or debit card, and a refund is necessary, the refund should be credited to the original card used for that purchase, if possible. A refund must never exceed the original payment amount. The merchant should process the refund through the same technology used to make the original sale.
If any part of a payment is non-refundable, the merchant must declare this fact in a written No Refund or Cancellation Policy to that customer before the refund is processed. For dual controls, all refunds should be approved by a supervisor before funds are returned to the cardholder. For audit purposes, refund transactions must be properly documented and accounted for.
Before performing any credit card activities, credit card merchants must complete required training and renew the mandatory Payment Card Industry (PCI) compliance training annually. To learn more about the program that manages, supports, and mitigates risk for payments collected digitally and via credit and debit card by Stanford merchants, see Merchant Services Program.
When merchants process card refunds, the internal Merchant Services fee (0.8%) will be reimbursed to the same accounting codes used for the initial fee charge. The external processing fees associated with card refunds may vary depending on merchant account types:
- Stripe merchant account: There is no additional fee to process a refund. The processing fee collected for the initial payment will not be returned by Stripe.
- Non-Stripe merchant account: There will be a small (1%) fee to process a refund. The majority of the processing fee collected for the initial payment will be returned by the acquirer.
You can refund a credit card transaction previously processed via in-person point of sale (POS) or online payment methods using one of the following refund methods.
Refund via Stripe Dashboard
Refunds can be issued using the Stripe online dashboard and are processed immediately. Refer to the Stripe Payment Solutions resource page for additional details and step-by-step instructions.
Refund Using a POS Terminal
Up to 60 Days after transaction
For up to 60 days from the transaction date, merchants can locate and issue a refund (or follow-on credit) to the original transaction in CyberSource. A follow-on credit is linked to a previously authorized transaction, and can be requested within 60 days of the original authorization; after that, merchants (typically) must issue a stand-alone credit.
Refer to the How to: Process Credit Card Refund, CyberSource up to 60 Days tab for step-by-step instructions.
61 to 180 Days after transaction
Between 61 and 180 days from the transaction date, the transaction record with cardholder information can still be located in CyberSource. Merchants can issue a stand-alone credit within the CyberSource Business Center using any computer with internet access. No Virtual Terminal or PCI workstation are required. A stand-alone credit does not need to be linked to a previously authorized transaction.
Refer to the How to: Process Credit Card Refund, CyberSource up to 180 Days tab for step-by-step instructions.
181+ Days after transaction
After 180 days from the transaction date, the transaction record with cardholder information is purged and can no longer be located in CyberSource to be refunded. Merchants can issue a one-off stand-alone credit (SAC) in the CyberSource virtual terminal using the encrypted key pad.
Refer to the How to: Process Credit Card Refund, CyberSource Virtual Terminal tab for step-by-step instructions.
The CyberSource Recurring Billing solution product is available within one business day and is used to create Subscription IDs (a unique payment token for each card) and may be used to process card-not-present refunds (no time limit). This solution will eliminate the need to ask for your customer’s card information again to issue a refund or to make new purchases.
Refer to the How to: Process Credit Card Refund, CyberSource Recurring Billing tab for step-by-step instructions.
Refund Using a POS Terminal
You can issue a refund using a POS terminal on the original credit card, or a different credit card with your supervisor’s approval to authorize the refund transaction.
The POS refund can be performed in two ways:
- Mail Order Telephone Order (MOTO)
Note: We are in the process of moving Stanford VoIP out of PCI Scope. If you need to use a phone to collect credit card information, please submit a support request.
If the POS refund is requested by mail, the sensitive authentication data (SAD) must be rendered unreadable (cross-shredded or blacked-out) after the refund is successfully processed. Otherwise, the paper/documents must be locked with restricted access. Stanford does not allow any electronic storage of SAD (i.e., no email, texts or instant messages).
Refer to the How to: Process Credit Card Refund, Point of Sale (POS) Terminal tab for step-by-step instructions.
Manual Refund via Expense Requests System
If you are not able to obtain the card information of an original or new credit card, or do not have CyberSource access, your only option is to refund the customer by submitting a Non-PO Payment Request using the Expense Requests System.
Refund to Expired or Canceled Credit Cards
Possible actions if a refund is sent to an expired or canceled card:
- If a new card was activated with the same card issuer, the refund is normally credited to the new payment card.
- If the account was closed recently (in the last 2 months), the refund may post to the card-issuing bank who will usually reach out directly to the customers and notify them of any next steps.
- If the account has been closed for some time, the refund/credit will fail. In this case, departments will be notified by Wells Fargo Merchant Services, and they will need to refund the customer via a Stanford-issued payment using the Expense Requests System (ERS)
Next Steps: Merchants should have their customers contact their issuers to locate the refund. If they are unable to find their credit after talking with their bank, contact Merchant Services.
Refund a Different Amount
A credit may be issued for any amount less than the original amount. Merchants can also refund the remaining balance for a transaction already partially refunded. To issue another credit:
- Pull up the original transaction through the General Search (Select Transaction Search > General Search).
- From the Transaction Search Details page, select the Credit link in the Available Actions section.
- Confirm the credit amount.
Enabling Stand-Alone Credit in CyberSource
To protect merchants from erroneous credits, and to mitigate the risk of fraud, the stand-alone credit (SAC) functionality is disabled within the Virtual Terminal and Recurring Billing by default.
When an SAC is issued through a Virtual Terminal or Recurring Billing, no verification process takes place (this is not a limitation of CyberSource; it is common throughout the payment industry). This means a credit can be issued to any card at any time by any user (with the correct user permissions). For this reason, it is imperative for this transaction type to be protected. See Bank Fraud Prevention for information on preventing credit card fraud.
To enable SAC functionality temporarily, contact Merchant Services after collecting the customer's credit card information.
Preventing Double Refunds
A double refund means a customer is provided with two refunds for the same transaction. It also doubles the revenue loss for a merchant under either one of these situations:
- Chargebacks are filed after a refund is issued. The customer contacts the merchant to request a refund. The merchant honors the request, but the funds are not returned immediately. The customer thinks the refund request was ignored and files a chargeback. Both the chargeback and the refund are processed, meaning the customer gets twice the amount of money.
- Chargebacks are filed before a refund is issued. The customer contacts the bank to initiate a chargeback. Then, the customer contacts the merchant and expresses dissatisfaction. To try to appease the customer and avoid a chargeback, the merchant provides a refund. However, the merchant is unaware that a chargeback has already been filed.
Recommendations to help prevent double refund situations are presented in the following table.
|A chargeback is illegitimate, and a refund was not warranted.
|Ask the customer if they have filed a chargeback. The merchant should make the refund as requested as well as take note of the dispute case number, and watch for the chargeback to dispute it when it arrives.
|A chargeback results from a valid consumer complaint.
|The merchant should accept the chargeback as a loss and not issue a refund.
|The merchant issues a refund, but the customer files a chargeback anyway.
|The chargeback can be disputed. The merchant simply needs to prove to the issuer that a refund has already been processed.
Implementing Dual Controls for Refund Approval
Merchants should implement dual controls when issuing refunds. The process must include a separation of duties between staff approving and staff issuing refunds. A higher level of authority must approve each refund processed. The approver should confirm that the refund is valid, check the amount and that the intended individual cardholder is correct and appropriate. In addition, proper supporting evidence of the refund must be documented and maintained according to the university Record Retention Policy.
Displaying Refund Policies Before Checkout
If a merchant allows or restricts the return of goods or cancellation of services, the merchant must disclose return, refund and cancellation policies on the sequence pages before final checkout, and include a Click to Accept button, checkbox, or other acknowledgement.
It is important to work with your IT department and/or third-party vendor to enable this feature through Application Programming Interface integration. This may help to protect you from chargeback disputes that arise from unclear refund and cancellation policies, and prevent fines.