Know more about PCI DSS compliance

The next important step sees the acquirer recognising your card’s long 16 digit permanent account number (PAN) as one that it deals with ie from a card issuer that it recognises. At this point your card’s 16 digit PAN number, the merchant’s identification (MID) number, and the transaction amount are sent via the card scheme to the card issuing company. The card scheme for example could be VISA, Mastercard, AMEX or a host of others that card issuers are able to work with. Once the card issuer, Barclaycard for example, has checked that there is enough credit or balance available to fulfil the purchase an authorisation code is generated which reserves the money against the transaction and is passed back up the chain to the payment service provider (PSP) to notify the merchant or service of the transaction outcome. Ideally the transaction has been authorised but if it’s been unsuccessful then the merchant is also informed and the transaction declined. However, even with an accepted payment no actual money has been moved yet. The payment is still held by the acquirer and hasn’t gone any further.

The PCI DSS standard is surrounded by myth and confusion for both organisations and customers, including the myth that software solutions can be PCI DSS compliant. Vendors that make this claim miss the very thing that PCI DSS is trying to achieve – to maintain a unified standard to which organisations and merchants must adhere. Only organisations can be compliant.

There is also the myth that no one ever gets fined. In fact, the buck stops with the merchant and its contact centre. Plus the cost of data breaches cannot be measured in fines alone – there is also the cost of repetitional damage to consider.

Since 1 October 2010 all contact centres that accept card payments over the telephone are required to comply with PCI DSS. This includes the smallest to the largest, irrelevant of volumes of transactions or industry sector. Your contact centre probably uses multiple technologies so it is also important to understand who does what in the process and who needs to be compliant.

Third-party payment service providers can demonstrate adequate levels of data security and acceptable business practices if they appear on the VISA Europe Merchant Agent List. Merchant services organisations such as Elavon are insisting that only organisations which appear on this list are used by customers. The only way to be truly sure whether a third party vendor is PCI DSS compliant is by checking the VISA list.

The VISA List has two levels of 3rd party payment processor. Level 1, the top level of compliance, only applies to organisations that store, process and/or transmit more than 300,000 Visa transactions per year. To achieve Level 1 status an Attestation of Compliance must be completed by an independent Qualified Security Assessor (QSA) along with a Report on Compliance. Organisations with call centres are seen as particularly vulnerable and should do everything in their power to work with only Level 1 vendors (such as Encoded).

Level 2 is for smaller providers with less than 300,000 Visa transactions annually and organisations are able to submit an annual self-assessment questionnaire, including the Attestation of Compliance, without reference to a QSA.

PCI DSS covers a great many areas in the contact centre. Compliance should address risk and be achievable at a sensible and realistic cost. It can sound like a daunting process, however, the blogs provide tips and technical know-how that will help you along the way and save you some money in the process.

To become compliant there are 300 controls surrounding card holder data to protect consumers and merchants against security breaches. To truly understand the best practices for each of these controls requires a specialist.

However, looking at the key vulnerabilities – namely staff and the choice of third party payments supplier – can result in large reductions in both PCI DSS scope and the price of securing customers’ information.

For example, tokenisation (recurring and stored card payment solutions) means that contact centres can vastly reduce the scope of their PCI DSS audits. The process of tokenisation means that data is not stored in a database, reducing the risk of hacking and cyber theft.

By working with a PCI DSS certified payment service provider with a tokenisation solution, merchant organisations can reduce the scope of the cardholder data environment (de-scope). De-scoping is the process to reduce the number of requirements for compliance. In this way tokenisation increases security of card holder details while minimising the cost and complexity of compliance.

In reality, a contact centre cannot achieve PCI DSS compliance alone. All contact centres, regardless of size, should look to work with a trusted payment service provider to secure telephone and web card payments to reduce scope and the cost of compliance.

There is no one-size-fits-all PCI DSS approach, but working with a certified payments technology provider means you get the most cost effective, secure solution for your own situation.

Our blog compilation won’t provide you with every detail on achieving compliance, but it will give you a good overview on what is involved and what to do next. Or you can talk us directly to help you take the right steps to getting your PCI DSS programme underway.

Robert Crutchington is a director of Encoded.