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?