4

Currently I'm developing an iOS application which has an option to pay an order (clothes cleaning) via scanning credit card info using device camera. I can't use Apple In-App Purchases (IAP) for this, because it is a physical good not a virtual one:

11.3 Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected

These payments are future payments in the PayPal terminology, so I can't charge user's card immediately. Unfortunately, current version of the PayPal Mobile SDK doesn't have an option to use a credit card for this:

When you integrate your mobile app with PayPal Mobile SDK 2.0, your customers can give permission to be billed multiple times in the future without logging into their PayPal account. PayPal payments (not credit cards) are supported.

So I implemented next approach: an app scans user's card and then I send scanned PAN/ccv/owner's name/expiration date via HTTPS (SSL) to my server, which,in turn, sends them directly to PayPal to obtain an OAuth token for future payment. I don't store this info anywhere. In the 4.1 and 4.2 paragraphs of the PCI DSS spec I saw:

" Never send unprotected PANs by end-user messaging technologies"

But in my scenario it is not an end-user messaging technology. PCI DSS says that if the browser uses SSL it is ok to send data through it:

Requirement 4: Encrypt transmission of cardholder data across open, public networks

As I understood there is no difference what client i'm using: browser or mobile app if I encrypt my data, right?

My question is this process a valid one or my app violates some rules of PCI DSS?

  • Probably a worthless question for iOS development: Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected – Dave Oct 23 '15 at 15:57
  • 1
    @Dave IAP is for virtual content –  Oct 23 '15 at 15:58
  • 1
    @Dave See my edits –  Oct 23 '15 at 15:59

1 Answers1

1

Your PAN data is encrypted in HTTPS and meets the requirement as long as your API is sending via HTTPS and using TLS. SSL is no longer supported as of PCI 3.1. In June 2016, TLSv1.0 (and possibly TLSv1.1) will no longer be supported either. That being said, your server is the area of concern for most PCI auditors. The server has the ability to read and decrypt the data for processing. You will need to review the large list of requirements for systems where cardholder data is stored. One of the areas you will definitely need to address is the following:

Technical Guidelines for Protecting Stored Payment Card Data At a minimum, PCI DSS requires PAN to be rendered unreadable anywhere it is stored – including portable digital media, backup media, and in logs. Software solutions for this requirement may include one of the following:

  • One-way hash functions based on strong cryptography – also called hashed index, which displays only index data that point to records in the database where sensitive data actually reside.
  • Truncation – removing a data segment, such as showing only the last four digits.
  • Index tokens and securely stored pads – encryption algorithm that combines sensitive plain text data with a random key or “pad” that works only once.
  • Strong cryptography – with associated key management processes and procedures. Refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations and Acronyms for the definition of “strong cryptography.”

See: https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf

Community
  • 1
pr-
  • 782
  • 1
  • 4
  • 21
  • Thanks! So as I understood there is no difference from the point of PCI-DSS either I'm using a browser or mobile app as a client, right? The most important I should use HTTPS (TLS) and respect other PCI requirements you poined ? –  Oct 23 '15 at 16:08
  • The reason that rule exists in PCI is so that cardholder data isn't sent over non-secure protocols (Such as text message). Your program is performing POSTs to an HTTPS site. That will meet the rule you have identified. – pr- Oct 23 '15 at 16:13