PCI DSS Compliance with TabaPay Card Processing
About
This section provides PCI requirements to merchants when using TabaPay’s card processing services. TabaPay and TabaPay’s acquiring bank are responsible to the payment networks for the merchant’s PCI compliance. Merchants are required to implement the specified PCI level based on the card entry method and their volume.
1. What is PCI?
The major card networks (American Express, Discover, JCB, MasterCard, and Visa) founded the PCI Security Council in 2006. The Council’s mission is to create a set of standards that participants in the payment card ecosystem must follow to help ensure the safety of payment card data. These standards are the Payment Card Industry Data Security Standards (PCI DSS).
Visit https://www.pcisecuritystandards.org/pci_security/ for more information. A requirement summary follows:
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
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
2. Who makes sure you follow PCI standards?
The merchant’s acquiring bank is responsible to the payment networks to ensure that entities the bank sponsors (merchants and processors) are PCI DSS compliant.
TabaPay is responsible to our bank to make sure merchants using our processing system are compliant with PCI DSS. TabaPay will need the merchant’s attestation of compliance prior to going live.
3. Does every merchant that accepts payment cards have to be PCI DSS compliant?
Yes
4. How hard is it to be PCI DSS compliant?
Two criteria determine the difficulty and expense of becoming PCI compliant:
Volume: Merchants accepting less than 6MM cards in a year do a self-assessment.
Card entry method: Merchants using TabaPay’s entry tools do not have PCI scope for these transactions – TabaPay provides all PCI documentation and scope.
SAQ A is the easiest level of PCI. A merchant that qualifies under SAQ A (using TabaPay web input tools or mobile application flow) receives an SAQ A from TabaPay to sign, without having to do any modifications/monitoring of merchant systems.
SAQ P2PE (point to point encryption, e.g. use of a tamper proof, encrypting swipe or keypad to enter card data) typically requires only policy updates to insure card numbers are only entered into the P2PE device.
SAQ D is a very difficult and expensive process to conform to.
Specific further details below:
Volume criteria
Merchants are categorized by levels: Level 4 merchant accepts less than 20,000 cards in a year; Level 3 merchant accepts less than 1MM cards in a year; a Level 2 merchant accepts 6MM cards or less in a year; a level 1 merchant accepts more than 6MM cards in a year.
A level 4, 3, or 2 level a merchant can do a self-assessment, providing their attestation of compliance (AOC) annually. If the merchant is storing cards or card numbers are flowing through a merchant system then the merchant must also do a quarterly scan by an Approved Scan Vendor (ASV).
A level 1 merchant must hire a qualified security assessor (QSA) and conduct an onsite audit, providing their AOC and Report on Compliance (ROC) annually.
PCI card entry criteria and SAQ
The PCI requirements vary by how a merchant accepts cards. Merchants that qualify to do a self-assessment questionnaire (SAQ) A, receive all the documentation prefilled from TabaPay annually. A merchant that does not electronically process, store, or transmit cardholder data on or through a merchant system typically qualifies for an SAQ A.
The SAQ A attests that the merchant does not receive, store, or process any card holder data, rather uses a PCI DSS compliant service provider’s card entry tools. Additionally the attestation states that the merchant’s systems do not create any web pages that directly accept cardholder data (if yes then an SAQ A-EP will need to be provided, which puts increased burden on the merchant. The TabaPay iFrame, SSO web page, and iOS/Android support do NOT require an SAQ A-EP, rather an SAQ A).
The SAQ type, based on card entry methods supported by the merchant, is listed in the table below with the relevant TabaPay tool.
| Card entry method | Party entering card number | PCI requirement | Notes |
|---|---|---|---|
| TabaPay hosted iFrame, TabaPay hosted web page, or TabaPay one time payment portal | Customer | SAQ A | Easy – TabaPay automatically creates an SAQ A and AOC for the merchant. |
| Merchant iOS, Android mobile app using TabaPay public key and card handling flow | Customer | SAQ A | No card info flowing through merchant system; No card entry web page built by merchant. |
| TabaPay keypad w/ TabaPay administration portal | Merchant call center | SAQ P2PE | Requires no merchant technical PCI scope, rather just policy and procedure |
| TabaPay administration portal without keypad | Merchant call center | SAQ C-VT | SAQ C-VT increases PCI technical and procedural scope. |
| Card acceptance through merchant technology invoking the TabaPay API | Customer or Merchant call center representative | SAQ D or SAQ A-EP | A merchant that uses TabaPay’s public key to encrypt card number in web page, encrypted card info on customer machine, will need to submit their SAQ A-EP |
| SAQ | TabaPay entry method | Roles | Merchant requirements |
|---|---|---|---|
| A | iFrame, mobile toolkit | TabaPay provides SAQ A for merchant to sign | No other requirements |
| P2PE | TabaPay administrator console with P2PE keypad | TabaPay provides SAQ P2PE for merchant to review, confirm and sign | Merchant needs to confirm card handling and call center policies. |
| C-VT | TabaPay administrator console without P2PE keypad (or another vendor console without P2PE keypad) | Merchant must complete SAQ C-VT | Requires quarterly scan, virus scan on CSR machines, network scanning/monitoring, etc. |
| A-EP | Merchant web page accepting card holder data using TabaPay RSA key to encrypt card data within web page on customer browser. | Merchant must complete SAQ A-EP | Requires quarterly scan, virus scan on CSR machines, network scanning/monitoring, etc. |
| D | Merchant web page accepting card holder data, or merchant system storing card holder data. | Merchant must complete SAQ D | Requires quarterly scan, external penetration test,virus scan on CSR machines, network scanning/monitoring, etc. Level 2, 3, and 4 merchants must supply their penetration test AOC by a qualified party. |
5. TabaPay Tools for PCI
TabaPay card entry tools offload PCI scope from the merchant while allowing seamless card entry within merchant applications or the merchant call center.
5a. TabaPay PCI-Compliant iFrame
Refer PCI-Compliant iFrame
Implementing the TabaPay iFrame to capture cardholder data does not increase PCI scope on the Merchant. The Merchant qualifies to use an SAQ A as prefilled by TabaPay for their PCI compliance.
The TabaPay iFrame allows a merchant to collect card information without having the card information flow through or be stored on a merchant system. The iFrame is hosted by TabaPay, imbedded in a Merchant web page, and allows a customer to enter their card data directly into the TabaPay system. The iFrame is not used to process a payment, rather just for collecting card information. The Merchant must process a subsequent payment after receiving an AccountID back from the iFrame (using the AccountID as a token for the cardholder data).
The iFrame provides the merchant significant control over their user interface. TabaPay can change the colors, words, text style, box style, and background to match the merchant web page.
iFrame sample pages can be accessed at PCI-Compliant iFrame
If the CVV2 is requested by Merchant then the prompt for security code is included in the iFrame as well as a card authorization.
The Merchant can then use the returned encrypted card account information and keyID to query a card, create an account, and/or process a payment.
5b. iOS and Android Card Entry
Implementing the TabaPay card entry application flow with the TabaPay RSA key support (“Mobile OS Support”) as shown to capture cardholder data within the merchant’s iOS/Android data does not increase PCI scope on the Merchant. The Merchant qualifies to use an SAQ A as prefilled by TabaPay for their PCI compliance.
The TabaPay Mobile OS Support allows a merchant to use their own mobile application, prompt for card information without having the card information flow through or be stored on a merchant system. The merchant mobile application takes the user through the entire payment flow. The merchant must transmit the encrypted card information from the merchant mobile application on the customer phone directly to TabaPay, encrypted with TabaPay’s public key. These criteria allow merchants to qualify for an SAQ A (no card data flowing through, processed, or stored on a merchant system and the merchant does not render a web page used to capture card data).
The application flow follows:
The public key(s) should be hardcoded in the mobile app. The Mobile App should not go back to the server to retrieve the public key (and/or) go to the TabaPay server to retrieve the key!
5c. Customer Service: Key Entered Card Payments
If CSRs need to accept card information from customers in the call center then TabaPay provides a tamper proof device to enter card numbers, the IDTech m100 https://www.idtechproducts.com/products/pos-peripherals/securekey-m100-m130-bluetooth-payment-terminal-with-magstripe-chip-and-pin. The IDTech m100 is tamper proof, encrypts the card number on the device, and provides the TabaPay web page entry screen with an encrypted card number package for subsequent payment processing.
The IDTech m100 is a PCI P2PE (point to point encryption) certified device. The PCI scope is simplified dramatically, using a PCI SAQ P2PE. The SAQ P2PE requires only PCI requirements 3, 9 and 12 (of the 12 PCI requirements). Further, if cardholder data is not written down, but just keyed into the IDTech m100 then only requirement 12 is required. The IVR/telephone system is not in PCI scope as cardholder data is not electronically received through the IVR (voice is not considered electronically received).
If the CSR phone calls are recorded then the recoding needs to be paused while the customer provides their card number to the CSR for entry into the IDTech m100.
No software is required to be installed on the CSR computer, rather the IDTech m100 connects to the computer’s USB port.
The CSR uses a TabaPay page with the IDTech m100.
5d. Entering Card Data Directly into a Vendor Hosted Web Page
Customer Service Representatives (CSRs) entering cardholder data (eg. card number) directly into the merchant’s application or even a processor’s hosted virtual terminal, without the use of a P2PE device, brings the CSRs, their location (call center), and location’s systems into PCI scope.
This typically requires an SAQ C-VT (virtual terminal), assuming the cardholder data is entered into a vendor hosted screen. SAQ C-VT includes technical and process PCI scope items and can be quite burdensome. If the cardholder data is entered into a merchant hosted screen then an SAQ D is required, which is the most burdensome SAQ.
Updated 2 months ago