We’re developing a mobile app (iOS and Android) for a client which has its own payment processing solution. The app is public-facing, and will be used by individual consumers on their own phones.
The app has to interface with the payment processing solution over a SOAP API. We need to accept the input of the user’s payment card details, and pass them across that API. We don’t have the option of embedding their website within an iframe, or anything like that; we have to use this specific API, which means that our app will unavoidably have to (briefly) possess and process the user’s payment card details.
All the app needs to do is to collect the details (by having the user tap them in on the phone’s keyboard), send them across the API, and then discard them as quickly as it possibly can. It won’t store the data beyond the time taken to complete the transaction, and it won’t send the data anywhere except across the API to the client’s server. We will never have the data on our own servers, we will be careful never to write it into logs, and generally we will be treating it like radioactive waste for the brief period it’s in the app’s possession.
We can safely assume (at least for now) that the client’s systems already do whatever they need to do with regard to PCI DSS. And of course the traffic between the app and the payment server is encrypted.
We’re struggling to get to grips with what we need to do regarding PCI DSS, and we’d appreciate any pointers to help us get started. We’re perfectly happy to (indeed want to) use a consultant to help us achieve compliance – but we don’t really even know who we’d talk to. Everything we can easily find online (including material from the PCI itself) seems to relate to subtly different scenarios, or advises us to sidestep the problem by using something like an iframe, which isn’t an option for us.
To be honest, we’re surprised by how hard it’s proving to find some clear pointers. Lots of apps do process card details! This surely must be a common problem.
So, our questions:
Where should we go to get expert advice relevant to our particular scenario?
Completely informally, and on the understanding that we are going to get properly qualified advice later… how much of a nightmare should we expect this to be? We’ve got to the point of wondering whether we need to worry about key loggers installed on the phone. Is that really the case, or are we going too far?
Is there a magic bullet we’re missing – a library that’s already known to be compliant, for example?
I am a PCI QSA.
Like a lot of things with PCI there are several gray areas in the scenario. You can ask 10 QSAs the same question and will likely get 10 different answers, which is a sad reality of the lack of clear guidance around such scenarios (and there are many oddball scenarios).
So, in my professional opinion (I said opinion), a mobile app where 100% of the card ingestion, processing and transmission is handled on the mobile device AND the cards used on said mobile device belongs to a single user, the risk is very low. If I read the question right, you are the app developer. You are not the merchant, and if all you are doing is writing the code for some merchant or service provider, this problem sits more with them.
They will likely need to have an application penetration test performed and some traffic analysis to confirm the cardholder data flows straight from the device to the acquirer (the processor). You as the software developer are not on the hook for anything PCI, unless you are selling this app on the App Store or some such way. In that case, the above answer is more accurate. You would likely need to put this application through a PA-DSS review with a PA-QSA. Assuming it passes, it would be listed on the PCI SSC website under PA-DSS validated applications. This does not make the processor PCI compliant, but it can help with the assessment process.
As for the magic bullet, there is nothing. However, if you use Stripe as the processor and their mobile SDK to handle and transmit the cardholder data, then Stripe will assume the PCI responsibility after you complete a short questionnaire on their website each year.
I realize this question is pretty old, but I thought the answer could help someone downstream struggling with this issue. Also, I have no connection with Stripe, but I recently encountered this problem and was surprised to see how Stripe handles it. Pleasantly surprised I might add.
I don't think the above replies answer the question accurately. I would urge anyone who needs information specifically about mobile application development and PCI to read the following, taken from the Security Standard Councils documentation:
If the consumer is also the cardholder and is using the device solely for his/her own cardholder data entry, and the application can only be used by that cardholder using his own credentials, then the device is treated similarly to a cardholder’s payment card: The consumer’s environment in which the application runs is outside the scope of PCI DSS, and the consumer-facing application is not eligible for PA-DSS listing.
and this:...
PCI SSC agreed (see PA-DSS and Mobile Applications FAQs) that mobile payment-acceptance applications that qualify, as Category 3 will not be considered for PA-DSS validation until the development of appropriate standards to ensure that such applications are capable of supporting a merchant’s PCI DSS compliance. The PCI SSC recommends that mobile payment-acceptance applications that fit into Category 3 be developed using PA-DSS requirements and the guidance provided in this document as a baseline.
Read the last paragraph of page 2 and first paragraph of page 3. In a nutshell, at this point (17 Sep 2019) there is no validation for PCI compliance for mobile applications - only recommendations and guidance from the Security Standards Council.
I feel your pain, you'd think with something as ubiquitous as taking credit card details there would be a wealth of clear concise information to help you guide you through the process, sadly not the case.
For your first question you need to find a QSA, check out the PCI council website for a list of those and all the official information. I would recommend shopping around a bit, quality and pricing does vary, you'll want someone familiar with your scenario. As you say you should get official guidance before using the views I provide.
For your second question, the first thing to say is PCI is contract based. It's completely your client's responsibility (depending on the agreement they have with their merchant bank or payment processor). So if your contract doesn't say you need to provide a PCI compliant solution, you don't have to...though I would be careful this could be a matter for the lawyers if you've implied it or fit purpose etc. Pragmatically there's a few options depending on the situation, it gets a little tricky here so i'll try my best:
If the client has no control over the code or the system, they just receive the results of it, you'd likely be considered a service provider and you would need SAQ D for service providers at the minimum.
If you just give the client the source code and they implement, then they are fully responsible for, they would have to do code reviews, penetration testing etc etc if that's in scope.
If your client want's to plug your app into their system, and they don't want to be responsible for the PCI details of it then you would need to be PA-DSS compliant.
Ultimately it'll depend on what PCI scope your client can take on, they will likely need SAQ A at the very minimum (yes you may both need to prove PCI compliance), regardless of what course you take.
In terms of the nightmare, I'm not sure for native apps but for web apps if the PAN (cc number) touches your server it's full scope, SAQ D, in a nutshell yes that's a nightmare if you don't already have a secure setup. The best scenario would be SAQ A, but you would need a iFrame for that, if that's not possible then perhaps SAQ A-EP, you can use that with a direct POST so might be ok with the SOAP interface if that is directly from your app. I'm not sure if an app is considered 'e-commerce' which can use SAQ A and A-EP, if not you may need SAQ C. Take a look at requirement 6 at least, it covers software development.
For your last question, check out spreedly.com, they provide a PCI compliant connection to multiple gateways may be useful.
Good luck! And it'd be great to hear what you eventually decided to do.
This FAQ may help: https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/If-a-merchant-develops-an-application-that-runs-on-a-consumer-s-device-e-g-smartphone-tablet-or-laptop-that-is-used-to-accept-payment-card-data-what-are-the-merchant-s-obligations-regarding-PCI-DSS-and-PA-DSS-for-that-application?q=mobile&l=en_US&fs=Search&
This basically says that you are just responsible for following a "Secure Software Development Lifecycle", with such controls outlined in Req 6.3, 6.4, & 6.5.
I am thinking of building an Android app that fetches Notes and Reminders associated with an Apple ID. Is it possible to access them with http requests somehow? icloud.com uses their data, so I thought maybe it is exposed via some API, but I cannot find any documentation.
There is none. The only thing exposed so far is the CloudKit api which is for accessing key value data that you created yourself.
If you want to access reminders, then you can use the iOS native api:
https://developer.apple.com/library/ios/documentation/DataManagement/Conceptual/EventKitProgGuide/ReadingAndWritingReminders/ReadingAndWritingReminders.html
A hacky solution that I use for getting the reminders I create or mark as done is IFTTT (https://ifttt.com/). You can download it on your phone. This has the option to get the reminders values out to a google document, google sheet or other place that you can later easily grab from with the google API. That is what I am currently doing. In addition if your intention is to create reminders you can use pyicloud (https://github.com/picklepete/pyicloud). Its small project that I am also using. Feel free to contribute!
I know that some may not like this answer, as it may be a very gray area, but assuming you had the user’s permission, you might be able to make your own API with a scraper tool that can expose an API to the data. This way you can make an Android app that accesses the user’s iOS data via the icloud.com site and then allows them to use it/manage it via your app on their Android devices.
Do a search for scrape tools and you’ll find loads of them available now. Their pricing often includes a free tier that may or may not be adequate for your purposes. ParseHub is a great one. There’s others out there that can get around certain troublesome limitations of the browser that ParseHub has if you find yourself stuck.
If the app you make has good success then it may be a good investment to pay for the upgrades.
I want to build an app that sends data from device to device (android-to-android or android-to-iOS etc.) and I was starting to look at the server side aspect.
I was thinking to myself, should I use an MBaaS platform of some kind or build the backend myself?
is it better to use MBaaS because its less time consuming?
is it better to implement it all by myself because it will require less financial resources?
any thoughts on the matter?
Please advise.
I would do look at MBaas as a starting place. You can always decide later to 'port' your application later. Start with your basic requirements: Authentication, Role-Based Access Control, REST API, Business Logic and Event programming. The best part of MBaas is there dozens of vendors that will give you a free trial (like Espresso Logic). Make sure the pricing plan meets your long-term objectives. I have built services from scratch and trying to get all the services right and integrated takes a lot longer. Time is money - so balance the two.
Some may feel that this is a general question, but I don't believe that. I believe that this is a very important aspect of development and I am trying to learn from others.
Let's say I am making a clone of the twitter app.
Now, the front end is very do-able through traditional android code, however I don't know how to design the backend of the app.
I could use a database - but that seems better suited for older more traditional in house software applications.
I read a little about google app Engine, but I am not sure if that is a solution that should really be used for something like this. Realistically I do not know what options I have and I could use some direction for my research - because I don't want to make a mistake in my architecture only to have to go back and redesign the backend.
I would like to know what types of things I should be researching so that I can evaluate my options appropriately.
Thanks
In this case, you are looking at accessing the Twitter APIs to meet your functionality. You should look at an approach like the following:
Do you want to clone the Twitter App as is ? or certain functionality of it ? Identify that stuff.
Research the Twitter API in detail. For all your Twitter app needs, the requirement could be met directly by your API. Any local functionality for composing, replying, offline, etc can be met by your Android client itself and you do not necessarily need any backend functionality.
If you are looking at providing more value added services (some examples are below) :
Analyze the Tweets to provide enhanced information
Combine Twitter Data with information from other data sources
Provide metrics for all users of your Twitter App
Set User Preferences such that you can sync these preferences to multiple devices if the user logs in from anywhere
In such scenarios, doing work on the Server side will make things easier. Google App Engine is a great backend with which you can achieve a lot of the above functionality. It provides you a PaaS where you can use various services (datastore, networking, email) to boost your productivity, along with choices of languages (Java, Python, PHP and Go).
I tried to give the main idea in the title as good as i could. I am a good programmer in Java and i studied the android sdk. I posted my question here because i believe you can guide me.
Two companies need to send text messages(not sms) in the same android app. The number of users of this app is not known but it could be 500 to 200k. Can Gwt and app engine help me to make it possible. To make it clear i didn't studied these services, but i know if i use them it will have no cost.
The other solution is to make my own server and a web app with another language.
Your answers will save me time.
Thanks in advance.
GWT and App Engine are front end and backend platforms which can be used to build use cases which fit a different need.
App Engine provides a PAAS stack with limitations of hardened sandbox, GWT takes the pain out of Javascript programming but restricts the customization.
If you are using http to communicate with servers then GAE should do the job