How Card Payments work and PCI DSS
How do card payments actually work?
BMS’ systems will derive the BIN from the incoming PAN, work out which issuer and scheme this relates to and send an authorisation over the relevant scheme network to the issuer. In this example therefore, BMS will send an authorisation request over VISA’s VISANet to HSBC. HSBC’s systems will check the bank account associated with my debit card and decide whether or not to allow payment. In my case I’m in luck, the boss has decided to pay me this month so I can have those Converse. HSBC respond with a success and include something called an Authorisation Code.
BMS tell the terminal that the payment was successful, I breath a sigh of relief, remove my card from the machine, collect my little slip of paper (which has the authorisation code on it along with information about the POS terminal id and amount debited) and head out of the shop.
All done right? Nope. The authorisation is only part of the process. No funds have actually been debited at this point. At the end of the day, the merchant will cash up. Through interaction with the POS terminal they perform an upload of the transactions to the acquirer, via the same phone call mechanism. The acquirer receives the transaction list and proceeds to upload settlement batch files to each of the card schemes requesting payment. The card scheme ensures the delivery of this information to the correct issuer who is then responsible for remitting the funds to the card scheme. The card scheme deducts its interchange and sends the remaining funds to the acquirer. The acquirer deducts their fees and the merchant is then paid the remainder. This generally happens over night.
The overall process is the same for an Internet merchant except that the payment service provider takes care of all the interaction with the acquirer (and in many cases actually is the acquirer), including the transaction upload at the end of the day. Many Internet payment service providers maintain what is called a Master Merchant Agreement with an acquirer which allows them to use their merchant account in order to process transactions on other sub-merchants behalf.
A brief history of crime
As with just about any process, criminals look to find a way to abuse it. Right from the start fraudsters realised that copying cards or acquiring card details provided them with a rich revenue stream. The boom in Internet e-commerce in the early 2000’s provided criminals with two significant new attack vectors, end user PCs through malware or viruses and web site databases. It’s fair to say that few e-commerce companies were developing secure sites in those early years, both in terms of code or storage, and it was common for websites taking payments to have databases full of unencrypted card payment details. Criminals quickly worked out ways to infiltrate these databases and walk away with thousands, or even millions of card numbers.
Due to chargeback rules, if a cardholder detects misuse of their account they can contact their card issuer, declare transactions as fraud and the issuer will return the funds or reinstate the credit. The card issuer is then left with the problem of tracking down the fraudster to try and recover the monies. Not an easy task. The card schemes needed to find an approach to deal with this.
The PCI DSS is born
Five of the card schemes, VISA, MasterCard, American Express, JCB and Discover, combined their independent card security programmes in 2004 to create the PCI DSS. Its aim is to provide a baseline level of security for card payment processing. The PCI DSS is a set of six “control objectives” made up of twelve high-level requirements. These high-level requirements are then broken down into nearly three hundered individual low-level requirements.
The control objectives are as follows:
Build and Maintain a Secure Network
Protect Cardholder Data
Maintain a Vulnerability Management Program
Implement Strong Access Control Measures
Regularly Monitor and Test Networks
Maintain an Information Security Policy
You get a feel for the sort of things they are looking for here. I won’t take up any more space on this blog post regurgitating the long list of requirements, they can be found at the PCI DSS website http://www.pcisecuritystandards.org.
The PCI DSS is overseen by the PCI Security Standards Council (PCI SSC), comprised of representatives of each of those card schemes. Other businesses can join the SSC as a Participating Organisation (for a fee of course) and review proposed changes to the DSS.
The PCI DSS applies to all merchants that store, process or transmit cardholder data. The SSC breaks merchants down into levels based on transaction volume with the validation requirements for each level varying as appropriate for their size. The standard itself doesn’t change however, just the process of validation.
Merchants who comply with the PCI DSS are given “safe harbour” from fines and penalties associated with any card data theft which occurs from them, if they are proven to be PCI DSS compliant at the time of the breach. The scope of an assessment can be one of the hardest parts to nail down, before you even start to think about whether you comply or not. If you took the scoping statement literally you could argue that any device with an Internet connection is in scope and herein lies one of the core problems that we shall discuss in a further post, there is an awful lot of interpretation to be done with the PCI DSS and so much of a successful compliance assessment is in correctly understanding the standard and applying it appropriately.
In November 2013, the PCI Security Standards Council released version 3 of the ‘Data Security Standard and Payment Application Data Security Standard’. Our next blog on PCI DSS will cover the major changes introduced as part of version 3.