Considering I use SSL the whole process.

I have an IOS client that I want to use to enter the user's credit card details. I want to do the whole charging and processing on the server side, so I send the credit card details to the server where it is being used to process. I don't save the details there on any permanent storage.

Is this okay / enough ?


3 Answers 3


No. You can not handle PCI without meeting PCI-DSS requirements for handling PCI. Not storing it just means you don't have to worry about storage requirements, but things like network segmentation and server security still apply, even if it only transits across your server.

  • Can you elaborate about the network segmentation part ? A lot of payment SDKs allow you to create tokens on the client just by sending the card details over https to a 3rd party server.
    – Michael
    Feb 3, 2014 at 20:39
  • @Michael - yes, the third party works because the client talks to the third party (who is PCI-DSS compliant) and only non-PCI information is ever shared with the vendor's systems. This allows them to avoid falling under PCI-DSS. You could use a similar setup with your iOS application by coordinating through a third party. Basically, the iOS app would tell your server what it wanted to buy, you would tell the payment service provider what to charge and get a token to give the user, the user's device would then connect to the service provider, complete the purchase and then the service Feb 3, 2014 at 20:42
  • provider would either inform you directly or provide the client with a token that could be used as proof of payment. (An electronic receipt if you will.) Feb 3, 2014 at 20:43
  • @AJHenderson I think the iOS app itself would still fall under PCI compliance requirements if it's accepting credit card data and transmitting it to the payment vendor to receive a token. I'm not sure if this is what you were suggesting, or if you were suggesting handing off the entire transaction (including accepting the user's credit card) to a payment vendor's application.
    – Johnny
    Feb 3, 2014 at 20:56
  • @Johnny - the iOS app is being run by the client. I don't believe it would fall under PCI requirements for the same reason a web browser does not. The point of PCI-DSS is to ensure that third parties protect an individual's credit information. What a person does with their own (by using an application on their phone for example) is not covered. Feb 3, 2014 at 20:57

Difficult to know your exact set up but using language like 'send the credit card details' raises alarms. I'd suggest that fits into the 'Store Process and transmitting' of data. I'd be VERY suspicious of any answer to the contrary and bare in mind 90% plus of businesses that think they don't store data actually do once scanned and tested. Sorry it may not have been the answer you wanted but it's honest

PCI DSS applies to all entities ... that store, process or transmit cardholder data.

(PCI DSS v2 Introduction)

If you process credit card details, you're subject to PCI.

If you transmit credit card details, you're subject to PCI.

SSL / network encryption is one of the requirements for meeting PCI DSS (Requirement 4). There are others; you'll need to assess what you're doing in order to determine which you need to pay attention to. You should look at the Self Assessment Questionnaires to determine which scope likely applies to you.

If the server is outside your scope and you're only concerned with the app on your iDevice, you're probably writing a Payment Application, and you need to worry about PA-DSS compliance instead. That's more serious, there are no self-assessments for Payment Applications, and no organization can use an un-approved Payment Application without being in violation of the PCI DSS.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .