How does iPayment deal with PCI Compliance?

For a quick video explaining how iPayment deals with the issue of PCI compliance, you can watch this video

For a more detailed explanation of PCI compliance, as well as how iPayment completely eliminates the need for your company to become PCI compliant, please refer to the article below.

The PCI DSS (PCI Data Security Standard) is a standard that all organizations that store, process and/or transmit payment card data must adhere to, regardless of how big or small they are.

It is a common misconception when considering PCI DSS that an application itself can be PCI DSS compliant, or that it can provide some kind of guarantee of PCI DSS compliance. This is absolutely not the case, as a software payment application cannot be PCI DSS compliant – only the merchant or company using the software can actually obtain the certificate of PCI compliance.
A payment application can be PA-DSS (Payment Application Data Security Standard) validated, and if the company using it needs to be classed as PCI compliant then this PA-DSS validation must be in place.

If you’re using a payment application that requires PA-DSS validation and it either does not have that validation, or it has expired, then technically speaking you are in violation of PCI DSS compliance.

Should a data breach occur and your organization is suspected of compromising that data, you will be required to engage with a PCI Forensic Investigator to establish the source of the breach and ensure that any vulnerabilities are removed. You will be liable for the costs associated with the investigation if evidence of a compromise is established. Additionally, there are considerable fines associated with non-compliance following a data breach. The fines are passed from the card provider (VISA, MasterCard, Discover, AmEx and JCB) to the acquirer and then onto the merchant.

Using PA-DSS-certified software may provide your organization with some reassurance, but it will never completely absolve you of your PCI-related responsibility. Ultimately it’s the responsibility of the merchant to make sure that all of the conditions for PCI compliance are fulfilled when implementing a Payment Application.

B1 iPayment and PA-DSS

 PA-DSS is the standard against which Payment Applications need to be tested, assessed, and validated. PCI-DSS compliance is later obtained by the merchant. Although PA-DSS provides industry standards for developing payment applications, not all software applications that play a role in transactions are eligible for review and listing by the PCI SSC under the PA-DSS program.

B1 iPayment does not store, process or transmit cardholder data as part of authorization or settlement. As such it is not classed as a Payment Application, and so is not eligible for PA-DSS validation.

The PCI Security Standard Council has created this document https://www.pcisecuritystandards.org/documents/which_applications_eligible_for_pa-dss_validation.pdf on how to determine whether an application like B1 iPayment is eligible for PA-DSS validation. It contains the following sentence:

If the answer is YES to ANY of the following questions, the application is NOT eligible for validation under PA-DSS.
In the case of B1 iPayment, the answer to question 3 is a resounding YES:

Does the application facilitate authorization or settlement, but has no access to cardholder data or sensitive authentication data?

[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 (e.g., 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.[1]

Similarly, on reviewing the technical guidelines for PCI data storage shown in the table above, B1 iPayment does not store the Primary Account Number (PAN), Full Magnetic Stripe Data, CAV2/CVC2/CVV2/CID or PIN/PIN block and it does not transfer the data. As B1 iPayment does not store the primary account number there is no need to protect the cardholder name, service code or expiration date.
All interaction with payment gateways is done using a token that is representative of the payment card (you can read more about tokenization here). Only this token, generated by the payment gateway, is stored in the system but not the actual PAN, so B1 iPayment is not eligible for validation under the PA-DSS program.

Regarding cardholder data PCI-DSS, this does not apply if PANs are not stored, processed, or transmitted by the payment application, as is the case with B1 iPayment.

B1 iPayment and PCI compliance

See Which Applications are Eligible for PA-DSS Validation? by the PCI Security Standards Council.

What should a merchant or service provider do if they use, or intend to use, applications that store, process or transmit cardholder data and which are not eligible for PA-DSS validation?
Applications that store, process or transmit cardholder data and that are not eligible for PA-DSS validation would be included as part of an entity’s annual PCI DSS assessment to ensure that the application is compliant with all applicable PCI DSS requirements.

What should an application vendor do if their product is not eligible for validation under the PCI SSC’s PA-DSS Program?
If an application is not eligible for validation under the PCI SSC’s PA-DSS program, the PCI SSC recommends that those applications, if intended for use in the cardholder data environment, are developed using PA-DSS as a baseline for protection of payment card data. Merchants and service providers using or wishing to use such applications in their cardholder data environment would include these applications as part of their annual PCI DSS assessment.

B1 iPayment has been developed using PA-DSS as a baseline and uses tokenization to remove sensitive credit card details from the merchant environment. The usage of tokenization reduces the PCI-DSS scope required to be completed by the merchant but it does not remove it entirely.How tokenization reduces merchants individual scope totally depends on the merchant.