Skip to content Skip to site navigation Skip to service navigation

Frequently Asked Questions

What is Payment Card Industry (PCI) compliance?

The Payment Card Industry Data Security Standard (PCI DSS) is a required set of standards for optimizing the security of payment card transactions. A payment card is any type of credit, debit, or prepaid card used in a financial transaction. The PCI DSS was developed by the PCI Security Standards Council, an organization founded by American Express, Discover Financial Services, JCB International, MasterCard, and Visa Inc. The standard applies to all organizations that process cardholder information.  

Compliance with the Payment Card Industry Data Security Standard (PCI DSS) is required of all Stanford University departments and organizations (officially known as Stanford Merchants) that accept payment cards for financial transactions. Also, any organization that provides services that could affect the security of payment card data for another organization and owns a Merchant ID (MID) which includes third-party vendor engaged by Stanford Merchants to process payment card transactions on their behalf, or who is engaged in payment card financial services on our campus, must also comply with the PCI DSS. 

Adhering to the PCI DSS requirements provides critical protective measures to make sure payment card data is being kept safe throughout every transaction.

How do I comply?

It is your responsibility to read and understand the policies posted on this website.

You must complete the PCI Security and Compliance Awareness training, and you must retake the training on an annual basis to continue to attest to your knowledge and compliance.

For support questions regarding PCI infrastructure services, please refer to the Technical Services FAQ.

What is merchant level?

Merchant level is determined by the number of credit card transactions a merchant accepts in a year. The amount of the transactions is irrelevant. Merchants who accept less than 20,000 transactions annually are considered a Level 4 merchant. Once a merchant accepts over 6 million transactions in a year they are considered a Level 1 merchant and must have a third-party assessment performed annually. All other merchant levels qualify for an internal or self-assessment. Stanford is a Level 2 merchant. 

PCI DSS version 4.0 is out. What should I do now?

PCI DSS version 4.0 is out and the PCI Compliance team is working with our consulting firm to identify some gaps and next steps. We are not required to apply the new 4.0 until 2025. PCI Compliance team along with the Merchant Services team will work together to draft a plan to implement 4.0 and will notify our merchants accordingly. 

How do I choose the right Self Assessment Questionnaire (SAQ) that matches my merchant environment?

We only do e-commerce. Which SAQ should we use?

  • It will depend on whether the website is hosted by a third party or on campus. Fully outsourced eCommerce payments can qualify for the SAQ A. If the website is hosted by Stanford the appropriate SAQ will depend on how payments are integrated with the website. SAQs A, A-EP, and D are common.

We use the same third-party vendor for eCommerce, Mobile app, virtual terminal, and point of sale. Which SAQ should we use?

  • The corresponding SAQ is appropriate for that payment method. Although this will result in you having to complete multiple (smaller) SAQs, this may be more straightforward and result in fewer total questions to be answered than the more comprehensive SAQ-D.

We have multiple merchant accounts in our department. Which SAQ should we use?

  • We recommend using multiple SAQs that focus on only the controls needed for each merchant ID or each payment channel. Ecommerce payments are assigned one SAQ while in-person payments are assigned a different SAQ. The individual SAQs can be combined into a single document that addresses the necessary controls for all payment processes.
What is the difference between penetration testing vs vulnerability scan? Who is required to complete them?

Vulnerability scanning (req. 11.2) seeks to identify known (published software flaws) weaknesses so that they can be corrected (patched) before they are exploited by an adversary. Vulnerabilities above a severity CVSS 4.0 must be remediated in order to be compliant. Penetration testing (req. 11.3) seeks to identify less obvious weaknesses that may be the result of a confluence of other factors (misconfiguration, poor system design) that may be exploited by someone engaged in active probing. Merchants with SAQs that indicate these requirements are in-scope must complete them.

Vulnerability scanning is akin to checking for unlocked doors at a facility so they can be addressed. Penetration testing is using an unlocked door to gain unauthorized access to the facility.

Why do I need a PCI workstation to key in credit/debit card transactions?

In general, the use of a dedicated PCI workstation protects transactions from the risk of system compromise that is present on computers that are used to receive an email, browse the Internet, and are susceptible to other vectors of malware infection. Additionally, at Stanford, the use of a UIT ET Compliance Services provisioned PCI workstation or the PCI VPN solution serves to route transactions to the dedicated PCI network, and thus removes the larger University network from PCI compliance scope.

Can I use a non Point-to-Point Encryption (P2PE) POS terminal to accept credit/debit cards? For example, Stripe POS terminals.

Because the use of non-P2PE solutions subjects the associated transaction process to PCI scope inclusion, you may not use them without review and approval from the PCI Compliance team to ensure that other appropriate compensating controls are implemented.

How do I manage the third-party vendor’s PCI compliance?

Request their PCI DSS SAQ documents as well as copies of their recent ASV scan and penetration test report (if applicable).

Third-party service provider (TPSP) management begins at contract signing or acceptance of the user agreement with the appropriate language protections in place. Annually collect the required documentation from the TPSP, which is a component included in the contract.

What kind of cardholder data can we store in my business environment?

The minimum necessary (first six + last four, etc.) in a physically secure manner to facilitate business payment requirements, i.e., card-not-present repeating orders. May not store SAD after payment authorization, and should leverage third-party payment portals for out-of-scope storage wherever possible.

What should I do if our payment solution is compromised?

Notify the Stanford Information Security Office as soon as possible by following the steps on Report an Incident page. Your report will then be assigned to the ISO PCI Compliance team for review and follow-up.

During COVID period, what trends/challenges have you seen around PCI compliance?

Issues related to lack of accessibility to physical assets previously used to support PCI transaction processing at specific sites - i.e., dedicated PCI workstations, POS devices. Also, issues associated with lack of use, i.e., discharge of POS device internal batteries causing the device to lose internal configuration setting and enter a tampered state. Challenges adapting to new processes designed to facilitate remote work, such as setup and training to utilize specially configured virtual desktop environments to process transactions using dedicated virtual terminals, or ensuring that the physical security of home offices is sufficient.

Can I use my personal laptop to use the payment gateways website to process credit cards? E.g. clover, cybersource site

Our policy states that you are required to use a specific Stanford-issued device to process credit cards. This is because once any device is used to process a credit card, then it puts the device and the entire network into PCI scope. There are several technical controls that must be in place on devices used to process payment cards which will reduce the functionality of the device. You can use a P2PE SRED keypad that's attached to a Stanford-issued laptop, which will allow you to run other programs. Even then, the P2PE implementation manual must be followed to ensure the cardholder data is secured appropriately. Generally, the use of personal devices to process credit cards is not allowed and if you have special circumstances, contact the merchant services operations team by submitting a support request. 

Our website has been used by attackers testing over 200 credit cards, charging $1 per card. What actions should we take?

Even though Stanford is not directly responsible for these activities, we recommend the following:

  1. Report this incident by visiting: https://uit.stanford.edu/security/report-incident.
  2. If possible, be proactive in refunding transactions as eventually these transactions will be discovered and reported by the cardholder or payment brands and will need to be addressed. By proactively refunding these transactions you are able to manage the overall impact on University resources. Be sure to keep documentation on refunds in case it is needed for future investigation. Contact the Merchant Services Operations team to further discuss issuing refunds. 
How can we prevent such attacks in the future?

There are several options to take: 

  • If not already in place, requiring both a CVV verification and an AVS (address verification service) will reduce the number of fraudulent payments that are successful.
  • Review authorization messages set up in the payment systems to limit the amount of useful information card testers receive from the system when a payment is declined.
  • Contact the PCI team to see if we can block the IP addresses of known frauds.
  • Implement CAPTCHA. This prevents the attackers from using the automated system to run a batch of credit card numbers.
  • Set a minimum transaction amount to $10 or higher. 

Contact the Merchant Services Team if you want to discuss different options.