30
Aug
13

Mobile Payments Update

This past week, Bob Russo, General Manager of the PCI SSC, held Webcasts to discuss the changes coming to version 3 of the PCI DSS and PA-DSS.  For the most part, these Webcasts were nothing special.  Just a scripted regurgitation of what was published in the Version 3.0 Change Highlights document release earlier this month.

However, at around 35 minutes into the Webcast I attended, things got very interesting and an actual useful piece of information was shared.  For it was at that point that Mr. Russo launched into a discussion about mobile payments and the use of consumer devices such as smartphones and tablets for the processing of card transactions.  Mr. Russo stated:

“The fact is that many consumer mobile devices simply cannot provide the level of security needed to adequately protect payment card data.  In other words, they cannot create a trusted environment equivalent to the PCI DSS compliant cardholder data environment.”

Whoa!  Now there is a piece of information I was not expecting.  I looked at the slide and these are the bullets on the slide.

  • PCI Standards focus on merchant acceptance
  • Mobile payment acceptance still evolving
  • Understand risk and use PCI SSC resources
  • PCI SSC is working with industry

Mr. Russo went on to say:

“We encourage merchants to understand the risk of using mobile, work with their acquirer and make their own decisions about mobile and whether they are willing to accept that risk.”

“We’re working with others in the industry including: standards bodies, vendors, banks and processors.  But we are unwilling to lower the bar for security by writing a standard that current mobile devices could meet.  If we wrote a secure standard for mobile now, no consumer devices would be able to meet it.”

The bottom line in all of this is that all of you merchants using iPads, iPhones, Android phones and tablets and similar devices are using them at your own risk.  They are not PCI compliant.  Not only that, you should have cleared that decision with your acquiring bank so that they also accepted the risk that you were using mobile devices to accept payments.

Mr. Russo referred Webcast attendees to reference the PCI SSC Information Supplement ‘Accepting Mobile Payments with a Smartphone or Tablet’ for additional information regarding the use of such devices.

Mr. Russo also reminded everyone that mobile payments from the consumer side are not within the purview of the PCI SSC and the PCI standards.  So wallet applications, near field communication (NFC) and the like will not be regulated by the PCI standards.

These statements though leave a lot of questions for QSAs.

  • How are QSAs supposed to reference these non-compliant devices in the merchant’s Report On Compliance (ROC)?
  • Do QSAs mark this in the ROC as non-compliant and which requirements do QSAs flag as non-compliant?  Is it because the devices are not PTS compliant or are their other requirements that are not met?
  • Do QSAs need a compensating control for these devices?  And exactly what would the controls be that would make these devices acceptable?
  • Do QSAs need to obtain a letter from the merchant’s acquiring bank(s) acknowledging the use of these devices and their approval of their use?

I am sure this will create many interesting discussions at the PCI Community Meeting that is just a few weeks out.  So stay tuned.

Advertisements

8 Responses to “Mobile Payments Update”


  1. 1 steve
    May 3, 2016 at 11:42 AM

    It’s not strictly a PCI requirement but in the UK, VISA has made it clear that using a card not present method, e.g. merchant provided tablet giving access to the web site when in a card present setting, e.g. in the shop, would never be acceptable unless a P2PE reader was used to input the card data i.e. making it a card present method.

    • May 4, 2016 at 5:38 AM

      Thanks for the update.

  2. 3 QSAsteve
    December 4, 2013 at 3:53 AM

    The most common implementation would seem likely to be using the smartphone/tablet to access a payment gateway service via https. I’m not clear why this should be much different to an SAQ-C-VT scenario. Indeed since there is no connection to any other merchant infrastructure it might be more secure. Why has the PCI SSC not explicitly commented on this approach?

    • December 5, 2013 at 7:01 AM

      A customer accessing a Web site though any devices’ browser via SSL/TLS/etc. is never in scope.

      Where this changes is when the merchant or their third party is accessing a Web site via a browser to process payments such as with a call center. The risk is that a piece of malware could end up on the call center workstations that records their keystrokes. Since they process volumes of potential credit/debit card transactions, the number of PANs collected is large. That is why the PCI SSC tells us to ensure that these workstations are protected and included in the scope of the assessment.

      • 5 Ash
        April 26, 2016 at 8:10 AM

        Hi Mate,

        Even those devices are provided by the merchant themselves e.g. PC based kiosks directing customers to their website to make a payment (similar to if they were doing it from their own devices at home)?

        Cheers,
        Ash

      • April 28, 2016 at 2:57 PM

        If you are providing the mechanism (PC, tablet, whatever) for your customers to use. Who do you think is liable if a keyboard logger or memory scraper gets installed and captures your customers’ cardholder data? That would be your organization. So I would highly recommend that you heavily secure any such devices and patch them regularly.

  3. 7 Grant Owens
    November 18, 2013 at 4:42 AM

    Asking as a developer, does this mean that there taking card payments through a mobile app is dead in the water unless I want to fall foul of PCI? Or is there any way that I can take a card payment through a mobile app other than using an IFrame to a PSP form?

    • November 18, 2013 at 6:37 AM

      It just means you do not want to develop the card transaction processing solution. You want to use the processors’ or acquirers’ solution for processing mobile payments.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

August 2013
M T W T F S S
« Jul   Sep »
 1234
567891011
12131415161718
19202122232425
262728293031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,862 other followers


%d bloggers like this: