A hostile environment: payments, the PCI DSS and UK digital businesses

I’ve written in the past about how to avoid hefty charges for the task of checking a few checkboxes when completing your PCI DSS SAQ A. I have been following this process for the last few years without problems. After all, my business never touches a card number. We (and our servers) never see a card number as card payments are taken on a payment page hosted on a Level One Certified PSP here in the UK – Sage Pay. Therefore we fully comply with the requirements for completing SAQ A – Card-not-present Merchants, All Cardholder Data Functions Outsourced.

Enter Barclaycard Data Security Manager

In November I received a letter from Barclaycard – our merchant account provider – stating that from now on I would have to use the Barclaycard Data Security Manager to comply with the PCI DSS.

“Now here’s the good news. We’ve created Barclaycard Data Security Manager, a new programme which helps make it easier for your business to meet PCI DSS requirements.

That’s nice … but perhaps not,

“… There will be a small charge of £5.80 for this service which will be applied to your statement every month.”

I phoned Barclaycard and explained that, as in the past, I would complete my own SAQ A and upload it as we do not take or store any cardholder data and therefore our compliance requirements are very simple. I was told that I could not do this. I either needed to pay another QSA and upload validated documents, or go via the Barclaycard Data Security Manager at a cost of £5.80 per month on to of all the other charges we have to pay to process each payment.

We are already doing the sensible thing by NOT taking card data

I have spent years advising clients that if they can avoid processing card data themselves – and therefore needing to comply with PCI DSS at a higher level – then that is the way to proceed. In my opinion the banks should be making it as easy and inexpensive as possible for people to go that route. If you NEVER see a customer card number and those numbers are NEVER transmitted or stored on your servers then compliance should be a case of stating you do not store or transmit card data and giving the name of your Level 1 certified PSP. That is what SAQ A is intended for.

The banks should be lining up to encourage people down that route and away from storing or processing card data, even via a PSP API, as it is there that there are more chances for dodgy code or poor security practices to enable card data to be compromised.

Back to Barclaycard

Naturally I was going to argue this. I emailed Barclaycard to ask why I needed to pay to tell them I didn’t store card data. I would publish the replies here however Barclaycard have informed me that if I do I am breaching their terms and conditions, I was open about the fact I was not only interested in the answers to these questions for myself – but in order to advise other people. So I shall explain the official line of Barclaycard based on publicly accessible documents.

The line from Barclaycard on PCI DSS self-assessment is that merchants were completing their forms incorrectly and therefore “in unnecessary danger of security breaches and card scheme fines”. This line is detailed in the Barclaycard FAQ, I don’t want to use Barclaycard Data Security Manager online service; where can I get a PCI DSS Self-Assessment Questionnaire (SAQ) from?

When I pressed Barclaycard they simply repeated the above information, in addition referring to a 2010 Visa alert which is something of a strawman as the issue raised would have more to do with the PSP than the merchant in terms of them providing a method for the merchant to identify that they are indeed the server they expect to be talking to. All the recent PSPs I have encountered have such methods in place.

They also inferred that due to the fact a PSP will also usually offer a “virtual terminal”, a web page where a merchant can go to enter phone orders, they may have other compliance issues. The fact remains that businesses selling services or digital products typically do not use a virtual terminal. Surely all we need to do is indicate that we never take card payments in any way other than via the PSP Payment Page?

We have to put up and shut up

If we want to continue processing payments via Barclaycard there is little we can do other than pay their fee and go through the charade of completing their form and being charged for the privilege.

If we ever had our hands on customer card data, even just by way of taking that number over the phone or it being on our servers prior to an API request being made to a third party then I would agree, it should be verified as to how we were keeping that data secure. However, like the majority of businesses like ours we never, ever see or have access to a card number. My argument is that there should be simplified compliance for people who can guarantee that is always the case, as an incentive to outsource complex security requirements to companies who are better placed to deal with them.

Transmitting Card Data, Stripe vs traditional PSPs

This all gets even more strange if we take a look at Stripe. We thought of switching to Stripe but they don’t do true multi-currency. However I’m also a little confused about how they are enabling customers to bypass the PCI DSS as it does appear that a company using Stripe is at the least equivalent to one using a traditional PSP pay page and it could be argued that they are in fact transmitting card data.

The document Navigating PCI DSS states that,

PCI DSS applies wherever account data is stored, processed or transmitted.”

Using our Level One Certified PSP payment page we neither store, process nor transmit card data. It never touches our server or a page hosted on our server. Nor is any code that enables the transmission of card data linked to our server.

Using Stripe, payment data is collected and transmitted using a JavaScript API. Yet Stripe customers are not required to complete any SAQ, despite the fact that there is a higher theoretical risk at least of a compromise. For example could it be argued that there is potential for someone who has access to the server to replace the Stripe code with their own JavaScript? This is the same risk as indicated by the 2010 document sent to me by Barclaycard. I have asked Stripe these questions and they are of course able to comment here, and I’ll publish the clarification.

My question isn’t whether Stripe is a secure way to take payment or not, or more or less secure than a PSP payment page. The only reason businesses using Stripe and businesses with an acquiring bank and PSP are treated differently – as far as I can see – is because if you have an acquiring bank they can tell you to pay whatever they feel like telling you to pay and you have no option but to pay it.

Could the PSPs put pressure on here?

Stripe seem to be managing to collect and process payments without every customer needing to complete an SAQ. Could other PSPs not do the same? Digital businesses do not need virtual terminals or the ability to take phone orders. If the PSPs offered a digital business only type of account could they put pressure on the banks to allow customers using that service to be flagged compliant by the acquirer?

This would seem to be to the benefit of the traditional PSP companies. If services like Stripe are managing to bypass compliance for their customers they are making it a much more compelling option to go with them. Especially if the acquiring banks are to start charging payment page only customers for compliance, as this makes the relative cost of Stripe (which is slightly higher than PSP/bank once you are at scale) seem a better option.

Is using Stripe a ticking time bomb?

Conversely, should Stripe customers be concerned? What happens if there is a suspected compromise of card data and a Stripe customer is implicated? Will Visa and Mastercard start to look more closely at the operation? Will Stripe customers suddenly find they too need to comply with PCI DSS? Will transmitting card data via a JavaScript API be then treated the same as transmitting it over a SOAP or REST service and leave merchants needing to comply with more stringent security requirements including quarterly security scans?

Please add your thoughts

I don’t know the answers to these questions. I may have things wrong – the lack of transparency in this area means that you really only get to see the bits of the picture revealed by the companies you deal with. So the only way to get a full picture is if enough of us share what we know. My immediate future sees me continuing to use Sage Pay and Barclaycard and paying what I am told to pay, but I would love to see this whole area clarified for all of us selling digital products. At the moment I feel that the whole area of payments is pretty hostile and opaque to UK businesses, and in my experience – despite the arrival of Stripe – getting worse, rather than better.

If you know anymore about any part of this puzzle please comment below. I will reiterate that what I am describing here is only those integrations that would normally allow the merchant to complete the self assessment SAQ A, and the fact that acquiring banks are now pressing their customers for additional fees to indicate compliance.

9 Comments

John December 12, 2013 Reply

Seems like Barclaycard are just bullying your business. Assume that this is another area where there is no competition between banks? Ie they all will bully their customer?

Dan Martin December 12, 2013 Reply

Stripe is certainly a PCI grey area. Conceptually, the data in the form is submitted directly to Stripe servers, and the only thing returned to the merchant is a single-use token. You’re point “that there is potential for someone who has access to the server to replace the Stripe code” is a slippery slope, and I cannot believe anyone is really suggesting that as a PCI concern. Someone with access to any ecommerce server puts that server in unavoidable jeopardy. That person could replace any payment instrument with their own code. They could even add a payment form to the site, even if the site doesn’t take payments. Imagine I gained access to google.com; I could put a payment form on the homepage with an indication that Google searches now cost money, and likely harvest thousands or millions of cards.

However, I don’t understand your repeated mantra “put up or shut up”, “you have no option but to pay it”, “there is little we can do other than pay their fee”. Certainly you have options beyond BarclayCard and Stripe. Full disclosure, I do work for a company that offers competing products, but if any company isn’t living up to your expectations, then I’m not sure why you would stick with them.

Rachel Andrew December 13, 2013 Reply

@Dan the issue of someone replacing code on the merchant site is exactly what Barclaycard are referring to in the document they sent to me as evidence of how such integrations could be compromised. I agree it is nonsense. However I also think that all these things should be treated equally in the eyes of any legislation.

Regarding put up and shut up, I haven’t found any service able to do proper multi-currency transfers into our UK-hosted currency accounts other than to stick with the PSP/acquiring bank route. That was the sticking point with moving to Stripe in the first place, they would have to convert USD > GBP before transfer. If you know or work for such a service then I am all ears!

Pete M March 4, 2014 Reply

I had the same issue with Barclaycard last year as we had previously done our PCI DSS compliance via SecurityMetrics for a flat fee of £11.99 a year. Barclaycard tried to bully us into using their services and in the end it took 5 months of to-ing and fro-ing to get them to mark us as compliant on their system and take us off their mailing list threatening to introduce additional charges for not being compliant! In the end all I have is a verbal promise that these changes have been made as the staff apparently have no facility to send emails or letters to customers. A shambles and an excuse to extort money from customers.

I have today received a letter to my (other) business insisting we use their Data Security Manager and this tells me that they no longer their “preferred security partner” and that we will still have to upload documents via the portal to prove our compliance (even though we’re compliant via SecurityMetrics).

This seems like a means to bully e-retailers into paying a larger monthly fee. We were already in the process of swopping over to WorldPay (who include PCI DSS fees in their package and charge less overall) but this has just confirmed that my decision to move our business is the correct one.

Hopefully more businesses will move away from Barclaycard too.

Tim Holman November 1, 2014 Reply

Interesting thoughts and comments. I wonder if you used Barclaycard’s own ePDQ system and payment pages if these charges would still apply…? Maybe that’s their point and they want to onboard more clients directly.

With regards Stripe, it’s definitely in scope for PCI DSS. You’d use SAQ-D up until the end of this year, then SAQ-A-EP for PCI DSS v3.0 / Jan 1st 2015 onwards.

Whilst card numbers might not be touching your own web servers, your web server hosts the Stripe Javascript, and thus could affect the security of payment card data on the consumer’s browser, if it were compromised.

Another fee you’d not mentioned above is the fee the banks charge if you do NOT return the SAQ, or complete a SAQ showing you are not PCI DSS Compliant. I think that’s a bit more substantial – £20 a month or something for smaller merchants?

Greg December 17, 2014 Reply

Just a comment to Tim Holman – your web server does NOT host Stripe Javascript. It’s retrieved from Stripe’s secure servers. No part of the transaction occurs on your servers – not files hosted, or validation. My understanding is the only thing that is on your servers is essentially a link to the stripe order form.

Mark July 2, 2015 Reply

It appears it is now all the processors which are trying to apply monthly charges. HSBC (through Global Payments) now want £3 per month per merchant ID if we fill out the SAQ. We have a PDQ machine and online payments, under seperate merchant ID’s so this is now going to cost us £72 per year……for filling out our own SAQ. They do have an alternative thou, for £3.50 per month per merchant ID they will do everything for us. Whne I asked why they were charging for us filling out a SAQ the response was simply “ all firms are now charging, so are we” I have wondered if the office of fair trading would be interested in this? The Security Council are not, a note on thier website contact page basically says if your card processing firm are charging you its nothing to do with them. Looks as thou they are fed up with receiving complaint and are washing thier hands of the issue. Just the banks way of getting more money for nothing.

Jeremy Quadri July 3, 2015 Reply

The objective of PCI is to decrease the probability of an attacker stealing credit card data from an e-commerce transaction.

Banks make it convenient for us to use cashless payment by credit cards because it is an incredibly profitable business for them, especially since the burden of protecting credit card vital information has been shifted to the merchants.

With PCI, the responsibility of protecting a customer’s valuable information is now firmly placed on the shoulders of the merchants.

In the recent years, two types of attacks against merchants which do not directly process cardholder data have been reported. I believe these attacks were “man-in-the-middle” (MITM) based. Even though, these merchants completed SAQ A since their payment processing was outsourced.

To be eligible for SAQ-A and avoid the fines, your entire e-commerce payment (HTML form) page used to collect cardholder data must be fully outsourced.

No provider will exempt you from PCI compliance; however, they do decrease your PCI scope.

Using Stripe checkout (SAQ A) or stripe.js (raw tokenize —>SAQ A-EP) reduces your exposure. Stripe creates and styles the credit card form for you. All the merchant does is, drop in a JavaScript snippet. The JavaScript is used to encrypt the credit card data, and sent over SSL to be processed by Stripe API. As a merchant, you must ensure your SSL is configured for Strong Encryption using sufficient key length.

Stripe’s JavaScript library will prevent a retailer from processing raw credit card data, thus reducing the merchant’s PCI scope.

SAQ A is extremely challenging to achieve, even if you are using an iframe from a third party (such as Stripe or Braintree) or redirect based checkout (such as PayPal). MITM attack is a possibility because the consumer may be re-directed to the criminal’s payment page, thought this can be detected.

Unless the totality of all payment pages presented to the consumer’s browser starts immediately from a third-party PCI DSS approved service provider”. If any part of a payment page arises from the merchant’s website or a non-compliant service provider, the implementation is not acceptable for SAQ A

Greg Ellis October 25, 2015 Reply

I have just been forced to resign from Worldpay, as a result of making complaints surrounding non-disclosure of certain things like the PCI DSS compliance.

For me, it was hard not to complain after quoting a lady who knew nothing at all about PCI DSS – bear in mind here, she had already been tied into a contract for 3 years. Rather more shockingly, she had been charged £50 a month over 11 months for being non-compliant.

This is just one major issue I have encountered. People not knowing about 4p authorisation fees, the MMSC requirement and/or premium charges all add up to a massive list of short-fallings.

Suffice to say – people are being conned by these businesses and it’s just not right.

Leave a Reply