Process of Setting up a New
Merchant Account
S e t t i n g u p a N e w M e r c h a n t A c c o u n t Page 2
Table of Contents
PCI DSS ... 3 Who to contact? ... 3 Bakcground on PCI... 3 Why comply? ... 3 How to comply? ... 3 PCI DSS Scope ... 4Does PCI DSS Apply to Me? ... 4
What if I am not compliant? ... 4
What is UBC e-Payment (previously Consolidated Billing Module)?... 4
PROCESS TO SET UP A NEW MERCHANT ACCOUNT... 5
• PROCESS 1 ... 5
• PROCESS 2 ... 6
Sample of Cardflow Process ... 7
• PROCESS 3 ... 8
• PROCESS 4 ... 8
• PROCESS 5 ... 8
PCI DSS Self- Assessment Questionnaire (SAQ) ... 9
SAQ Documents ... 10
Merchant Levels ... 11
Guidelines for Cardholder Data Elements ... 12
S e t t i n g u p a N e w M e r c h a n t A c c o u n t Page 3 PCI DSS – Payment Card Industry Data Security Standard
Who to contact?
• Raul Ramos of Finance – for PCI compliance requirements
• Michele Benitez of Revenue Accounting – for Merchant account set up (after PCI compliance) Bakcground on PCI
• PCI Security Standards Council (PCI SSC or the Council) was launched in September 2006 by major payment brands: Visa, MasterCard, AMEX, Discover and JCB International
• A global forum for ongoing development and enhancement of security standards for account data protection, including the PCI DSS
• The goal of PCI DSS is to protect cardholder data that is processed, stored or transmitted by merchants in order to thwart theft of cardholder data and prevent fraud
• PCI DSS covers security systems and networks that store, process or transmit card data; they cover credit card transactions only, NOT bank debit cards
• Exceptions are the new VISA and MasterCard debit transactions, which is covered by PCI DSS Why comply? Prevent thieves from stealing credit card data and using it to commit fraud.
• Fraud and cardholder data compromise impact consumer confidence and damage your reputation as merchants
How to comply? Minimize or eliminate amount of stored credit card data (electronically or on paper) to reduce your risk and scope.
• Don’t store it if you don’t need it • Protect credit card data that is stored
S e t t i n g u p a N e w M e r c h a n t A c c o u n t Page 4 PCI DSS Scope
• PCI DSS requirements are applicable if a Primary Account Number (PAN) or credit card number is stored, processed or transmitted. If a PAN is not stored, processed or transmitted, PCI DSS requirements do not apply. Refer to guidelines on page 14.
• PCI DSS applies to all systems and networks that store, process and/or transmit cardholder data and connected systems including:
o All external connections to the entity’s network
o All connections to and from the authorization and settlement environment o Point of sale (POS) environment
• PCI DSS requirements apply to all system components. In the context of PCI DSS, “system
components” are defined as any network component, server or application that is included in, or connected to, the cardholder data environment. System components also include any virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual
applications/desktops, and hypervisors.
Does PCI DSS Apply to Me?
• PCI standards apply to all organizations/entities that store, process or transmit cardholder data • The security standards apply to all types of payments including in-person, mail, telephone and
e-commerce web transactions
• PCI compliance is required for any merchant that accepts payment cards, even if the quantity of transactions is just one
What if I am not compliant?
• UBC merchants will be responsible for and bear all costs related to becoming PCI DSS compliant • IN the event of a security breach/data compromise, the UBC merchant involved pays all costs (i.e.
forensics investigation, remediation costs, fines/penalties, litigation costs, etc.)
What is UBC e-Payment (previously Consolidated Billing Module)?
• UBC Information Technology (UBC IT) has developed several web payment services, known as UBC e-Payment, for UBC merchants to process credit card and Interac Online™ for UBC business transactions • Merchants are requested to consider UBC e-Payment before exploring other payment process or
securing a payment application from an external service provider
• UBC E-Payment users are obliged to sign a Terms of Use Agreement and/or Service Level Commitment (SLC) to monitor changes in procedures and to adhere with PCI compliance standards
S e t t i n g u p a N e w M e r c h a n t A c c o u n t Page 5 PROCESS TO SET UP A NEW MERCHANT ACCOUNT
• PROCESS 1: Merchant Business Owners should educate themselves with the PCI DSS policy.
o PCI standards apply to all organizations/entities that store, process or transmit cardholder data o All UBC merchants that process, store or transmit credit card data as payments to the University
and/or operate point of sale (POS) systems must be in compliance with PCI DSS v.1.2.2 (v.2.0 at January 1, 2012)
o The security standards apply to all types of payments including in-person, mail, telephone and e-commerce web transactions
o PCI compliance is required for any merchant that accepts payment cards, even if the quantity of transactions is just one
o Resources:
PCI DSS policy - https://www.pcisecuritystandards.org/merchants/
UBC Policy 106 - http://universitycounsel.ubc.ca/files/2010/08/policy106.pdf UBC PCI Compliance - http://www.finance.ubc.ca/ap/PCICompliance-Main.cfm UBC IT Security Policies -
http://www.it.ubc.ca/service_catalogue/information_security/security/security_policies.html UBC PCI Compliance Resources -
S e t t i n g u p a N e w M e r c h a n t A c c o u n t Page 6 • PROCESS 2: Merchant documents cardflow process.
o Refer to PCI DSS Requirements for guidance in documenting the cardholder data flow - https://www.pcisecuritystandards.org/documents/navigating_dss_v20.pdf.
o The PCI DSS is the global data security standard adopted by the card brands for all organizations that process, store or transmit cardholder data. It consists of 12 steps that mirror best security practices.
Build and Maintain a Secure Network
Requirement 1: Install and maintain a firewall configuration to protect cardholder data Requirement 2: Do not use vendor-supplied defaults for system passwords and other
security parameters Protect Cardholder Data
Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks Maintain a Vulnerability Management Program
Requirement 5: Use and regularly update anti-virus software or programs Requirement 6: Develop and maintain secure systems and applications Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need to know Requirement 8: Assign a unique ID to each person with computer access Requirement 9: Restrict physical access to cardholder data
Regularly monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data Requirement 11: Regularly test security systems and processes
Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses information security for all personnel o The merchant identifies and documents the existence of all cardholder data in their
environment, to verify that no cardholder data exists outside of the currently defined
cardholder data environment (CDE). The results may be a diagram or an inventory of cardholder data locations – see sample on page 9.
o The merchant retains documentation that shows how PCI DSS scope was confirmed and the results, for assessor review and/or reference during the next annual PCI assessment activity.
S e t t i n g u p a N e w M e r c h a n t A c c o u n t Page 7 Sample of Cardflow Process
S e t t i n g u p a N e w M e r c h a n t A c c o u n t Page 8 • PROCESS 3: Merchant determines the Merchant and SAQ level of their payment process.
o Contact UBC’s Qualified Security Assessor (QSA), if necessary through Finance (Raul Ramos) o The merchant is responsible for the cost of the QSA’s fee
o Document a plan for attaining compliance that reasonably meets the compliance objectives for the SAQ
o Submit documentation from Process 2, QSA confirmation of SAQ level and plan of compliance to PCI Working Group for approval
Refer to SAQ description on page 9. Refer to Merchant Levels on page 11.
• PROCESS 4: Merchant passes validation and completes the SAQ
o Merchants are required to complete the Merchant Payment Processing Confirmation form – Refer to Appendix A
o SAQ A and B merchants are required to complete the SAQ but not validated by the QSA o SAQ C and D merchants are required to complete the SAQ and validated by the QSA o Copy of Service Provider agreement – to be countersigned in Finance
Refer to SAQ instructions and documents on page 10.
IMPORTANT: No new account will be opened unless Telus signs off that the merchant payment process is PCI compliant prior to going live.
• PROCESS 5: Merchant account can be activated.
o The new account will be set up by Revenue Accounting (Michele Benitez) after all requirements from Process 1 to 4 are met and satisfied.
o Fill up the UBC Merchant Account Request Form and submit to Michele Benitez - http://www.finance.ubc.ca/ra/documents/UBCMerchantAccountRequestFormv4.pdf
S e t t i n g u p a N e w M e r c h a n t A c c o u n t Page 9 PCI DSS Self- Assessment Questionnaire (SAQ)
https://www.pcisecuritystandards.org/merchants/self_assessment_form.php
Questionnaire Level determines how thorough you need to be to become compliant. SAQ
Validation Type
Description SAQ
1 Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would never apply to
face-to-face merchants.
• Merchant does not store, process, or transmit any cardholder data on merchant premises but relies entirely on third party service
provider(s) to handle these functions.
• The third party service provider(s) handling storage, processing, and/or transmission of cardholder data is confirmed to be PCI DSS compliant.
• Merchant does not store any cardholder data in electronic format, and if Merchant does store cardholder data, such data is only in paper reports or copies of receipts and is not received electronically.
A (13 questions)
2 Imprint-only merchants with no cardholder data storage.
• Merchant uses only an imprint machine to imprint customers’ payment card information and does not transmit cardholder data over either a phone line or the Internet.
B (26 questions) 3 Stand-alone dial-up terminal merchants, no cardholder data storage.
• Merchant uses only standalone, dial-up terminals; and the
standalone, dial-up terminals are not connected to the Internet or any other systems within the merchant environment.
• Merchant does not store cardholder data in electronic format, and if Merchant does store cardholder data, such data is only paper reports or copies of paper receipts and is not received electronically.
B (26 questions)
4 Merchants with payment application systems connected to the Internet, no cardholder data storage.
• Merchant has a payment application system and an Internet or public network connection on the same device.
• The payment application system/Internet device is not connected to any other system within the merchant environment.
• Merchant does not store cardholder data in electronic format, and if Merchant does store cardholder data, such data is only paper reports or copies of paper receipts and is not received electronically.
• Merchant’s payment application software vendor uses secure techniques to provide remote support to merchant’s payment application system.
C (41 questions)
5 All other merchants (not included n descriptions for SAQs A-C above) and all service providers defined by a payment brand as eligible to complete a SAQ.
D (238 questions)
S e t t i n g u p a N e w M e r c h a n t A c c o u n t Page 10 SAQ Documents
SAQ Instructions and Guidelines v2.0 -
https://www.pcisecuritystandards.org/documents/pci_dss_saq_instr_guide_v2.0.pdf SAQ A v2.0 - SAQ B v2.0 - SAQ C v2.0 -SAQ C-VT v2.0 - SAQ D v2.0
-S e t t i n g u p a N e w M e r c h a n t A c c o u n t Page 11 Merchant Levels
Merchant Level determines whether or not you need to be compliant and how much expensive help you must buy to become compliant.
There are four merchant levels, with 1 being the largest/most difficult, and four being the least stringent/easiest to comply with:
Level 1 Any merchant, regardless of acceptance channel, who:
• Processes over 6 million Visa or MasterCard transactions per year • Has suffered a hack or an attack that resulted in data compromise
• Has been identified by Visa, MasterCard, or any other payment card as Level 1 Level 2 Any merchant who processes 1 million to 6 million Visa or MasterCard transactions,
regardless of acceptance channel
Level 3 Any merchant who processes 20,000 to 1 million Visa or MasterCard e-commerce transactions
Level 4 Any merchant who processes fewer than 20,000 Visa or MasterCard e-commerce
transactions or processes fewer than 1 million Visa or MasterCard transactions, regardless of acceptance channel
S e t t i n g u p a N e w M e r c h a n t A c c o u n t Page 12 Guidelines for Cardholder Data Elements
Data Element Storage Permitted Protection Required PCI DSS Req. 3.4 Cardholder Data
Primary Account Number (PAN) Yes Yes Yes
Cardholder Name1 Yes Yes1 No
Service Code1 Yes Yes1 No
Expiration Date1 Yes Yes1 No
Sensitive Authentication Data2
Full Magnetic Stripe Data3 No N/A N/A
CAV2/CVC2/CVV2/CID No N/A N/A
PIN/PIN Block No N/A N/A
1 These data elements must be protected if stored in conjunction with the PAN. This
protection should be per PCI DSS requirements for general protection of the cardholder data environment. Additionally, other legislation (for example, related to consumer personal data protection, privacy, identity theft, or data security may require specific protection of this data, or proper disclosure of a company’s practices if consumer-related personal data is being collected during the course of business. PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted.
2 Sensitive authentication data must not be stored after authorization (even if encrypted). 3 Full track data from the magnetic stripe, magnetic stripe image on the chip, or elsewhere.
S e t t i n g u p a N e w M e r c h a n t A c c o u n t Page 13
Appendix A: Merchant Payment Process Confirmation
UBC PCI-DSS Compliance: Merchant Payment Process Confirmation
Merchant Name
Overall SAQ Level
Contact Payment Processes Merchant Name & Account # PIN pad Connection Chip/PIN Compliant (Y/N) Detail SAQ level
Are the above process(es) and details correct? If not, please make the necessary correction(s) and provide updated process and cardholder data flow documentation if applicable.
If a "telephone dial-out only" PIN pad is specified as SAQ B by the Merchant because they use it as a dial-out device, then there should be no ethernet/network/ cable option. If the Merchant wishes to have the option of high-speed ethernet then the process should be a SAQ C. If the Merchant is a SAQ B, then the high-speed capability "must" be disabled, otherwise, the payment process is a SAQ C.
I hereby confirm that my unit uses the above process(es) to process credit card transactions and complies with PCI DSS requirements.
IMPORTANT NOTE: Any changes to your credit card processes and/or addition of new processes must be communicated to and approved by the PCI Working Committee through UBC Finance. Please contact Raul Ramos in Finance: rramos@finance.ubc.ca or 2-0259.
Process(es) Confirmed By: (print name) Date:
(Signature)