PCI DSS Compliance with TabaPay Card Processing

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.

See https://www.pcisecuritystandards.org/documents/SAQ-InstrGuidelines-v3_2.pdf?agreement=true&time=1503584025859

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. The iframe can be customized to 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. Once the user enters card details, the merchant's mobile application encrypts this data with TabaPay’s RSA key and securely transmits the encrypted information to the merchant application server. The encrypted data is then sent to TabaPay to process the payment, ensuring that raw card details never pass through the merchant’s systems. 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:

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.