Since our last post, we have received some queries from other companies asking us about their PCI compliance. Just to be clear, we do not charge a fee for replying to your email and assisting you make sense of this compliance. We know how frustrating it is, and no, anyone that tells you that PCI is easy as 1-2-3 isn’t really letting you know the full picture. This is because some emails had been – “I have this question, but wait, if you are going to respond and charge me a fee, then don’t bother.” What are we, mercenaries? Yes we are a company requiring profits and not an NGO, but over the 7 years we have been involved in PCI, we have actually done a fair bit of advisory without charge, just to get PCI awareness out there into the market.
So, to save the trouble, I’ll put up a public post here to sort some of the questions out. This question, we have been getting a fair bit: What if the company has a multiple processing environment? What does this mean?
Let’s say, a retailer. It has a POS environment whereby they run standalone terminals connecting to the bank for purchases in their store. Credit card is used here – card present transactions. Then they launch their e-commerce site, which redirects all card non-present transactions to a PCI certified payment gateway, where the card collection page is hosted by the gateway.
You see here – there are two different channels for credit card interaction. The traditional POS, and the e-commerce site. Both are completely outsourced – one is direct dial up to the bank, the other to the payment gateway. So how do you deal with this?
You have two options – one is to do separate SAQs for both environments. Yes, you can. In the example above, doing an SAQ B for your POS environment and an SAQ A for your ecommerce environment (assuming you are level 3 or 4 merchant) should be able to suffice. The second option is to combine these channels into one SAQ. Once you do that however, you won’t be able to go through the ‘specialised’ SAQs. Specialised SAQs are like A, A-EP, B, B-IP, C, C-VT – meaning they have conditions in which you need to adhere to in order to use them. For instance for A, it says that this will only apply to merchants with card non-present business. And likewise for B, it has condition that you do not store card information electronically and is not applicable to e-commerce merchants. So when you don’t fall into any of these SAQ buckets, you end up with SAQ D-MER, which basically covers everything in PCI. But don’t worry, you a lot of the SAQ would be non-applicable in this case, and only those related to outsourced e-commerce and POS facilities would apply.
Now another related question, and one that I ended up having a 2 hour discussion with a client on = can an entity be both merchant and service provider?
The short answer is yes, you can.
An example would be a telco. Telcos generally have massive merchant business. They accept payments for their pre-paid, post-paid etc from end customers through e-commerce, POS channels etc. But the Telco could also support a manage services and hosting environment whereby other merchants are hosting their payment sites on. Then, now you have a service provider environment.
Or, it could even be within the same organisation, you have your merchant business of a payment portal, Mobile POS, or mobile app, connecting to an outsourced payment gateway. Suddenly you decide you want to set up your own payment gateway and channel all the transactions of your merchant business to your own payment gateway.
In the first instance, if you have separate environments and businesses isolated from each other – you can again opt for separate compliance. You could be a Level 3 Merchant filling up an SAQ B form, and also a Level 1 Service Provider doing an ROC with a QSA.
In the second example where your merchant business connects to your own payment gateway, it’s a little more complicated because in all likelihood, the systems utilised by both business would be common. In this case, isolation and demarcation of type of business is more difficult to attain. Assuming you are eligible for Level 2 service provider, you can technically fill that up and ensure that it includes your payment channels within that SAQ. If you are doing a Level 1, then similarly, the QSA would likely include your payment channels (previously what you would call your merchant business) into your service provider certification efforts. Otherwise, you can still opt for a separate PCI compliance program, whereby you fulfill your merchant compliance, and for your service provider compliance program you do it separately.
For the latter option, the advantage is that if you launch your payment gateway and you provide options for other companies (not just your own) to connect to you, your compliance isn’t dependent on your payment channels (your merchant business). You would treat your own payment channels as just another merchant out of many, that are connecting to you. The downside of this is that you would likely need a clear demarcation and separation of systems between your merchant and service provider business.
Again, there are many ways to skin PCI. The best way (on paper at least) is to get your acquirer on the table or your payment service provider to ask them what is applicable to your business. Unfortunately, around 99% of the time in this region, the acquirers aren’t too knowledgeable themselves and either give wrong information or just tell our clients to do a Level 1 Certification with a QSA.
As part of our job scope – we will assess our client’s environment and provide the options on the table, and in some cases even be present on the table in the discussion with their acquirer – to obtain a clear indication on how to move forward and what PCI options are acceptable.
As always, drop us a note at pcidss@pkfmalaysia.com and we will do our best to accommodate your inquiries!
