I want to be able to sell products (via credit card) to people using my app. It's easy enough to put some EditTexts in and get them to give me their details but the issue is security of course. What is a good way to go about doing secure credit card transactions in app?
My Big Concern - Someone else makes a fake app that looks the same, with the same icon and app name and gets potential users to download their fake app and steal their credit card information. (Can people maybe even have the same developer account name?)
What I know so far - The package names of apps served off Google Play are unique so a user could identify if the package name is not what it should be. This isn't a good solution for the typical user though.
I'm not planning on storing the credit card details or anything. I just want to be able to do once-off card transactions securely. Any advice would be super welcome and receive much upvoting.
All you need to do is be able to work with Authorize.Net's, or any payment gateways, API to make payment.
Authorize.Net - Android SDK
Boku Mobile Billing
Since you stated that you would be selling products to users using your apps I'm assuming you will have the user details stored somewhere in a database yea? Moreover, you will have some sort of authentication using a username and a password so this means that even if someone else makes the exact same app as you did they will not have the user's username and password (assuming you hash your usernames and their passwords) or the real name of the user which he/she provided during sign-up into your app. Even if the hackers are smart and just use a dummy login page, i.e irrespective of the username and password entered you are logged in I'm sure users will be wary if they don't see a message saying "Hi X (real name of the user)" when they sign into your app (provided you have some functionality where you display the user's real name when they are signed into the app, this is pretty easy to implement). Having said all this, I haven't heard of a case where someone duplicated an entire app (which is no mean feat if you make a sophisticated app) simply to steal user's information.
Regarding the issue of securely accepting credit card information from users and charging it, one of the most trusted, industry-accepted and secure way of accepting user details is using Stripe.com . What's more is that they have a nice RESTful API through which you can make calls and charge the requisite amount from a user's credit card in the safest manner possible. The advantage of this is that you don't have to store the credit card information anywhere and simply use it once to make a call to the Stripe API (which is available in Java btw).
Related
I have an app that has in-app purchases where users can purchase set of videos and there are ten of these sets. Now, before they do this they have to sign up for this app using their personal e-mail (not necessarily their phone's primary e-mail).
Since they have to log in this app, I was planning that they get the right to open the app and the set of videos they purchased from whatever device they use.
Problem:
After thinking about this and since this app is only directed towards local audience, I am afraid that users will pass their accounts to each other and my customer number will decrease.
Solution I thought about:
I will put a message when the users buy the set of videos that says: "These videos will only be viewed from the device you download it on". Which means I will use certain flags to ensure that an account will download them once. So that if someone is to share an account s/he won't be able to download because they where already downloaded.
Question:
If I do like this then if the user uninstalls this app, s/he will lose all the videos they purchased. Thus, if they install it again, they will have to buy the set of videos again. I am not sure if professional apps let the users have what they purchased back if they reinstalled the app or not.
So, is there a way that I can still use the solution that I thought about and still have my users regain what they bought before they uninstalled the app? Or do you have a completely different suggestion that can solve my problem.
Account sharing is a big topic. Daily business for Netflix and Amazon.
I'm not a big fan of your solution because of all the restrictions. I would suggest following approach:
User signs up in your App
You create a unique ID on the device (GUID - https://developer.android.com/training/articles/user-data-ids)
You store this data on the database plus the GUID on the device
You can now verify that the user has valid access.
I would suggest adding another field like max_guids=2. So that if the user looses the device he can still access his data (yes, this also means 1 single device sharing is possible, therefore you can detect irregularity with login sessions and ban the user).
Sounds better?
Im developing an android application for the first time (no prior experience whit coding....). Mainly the app is going to be used at work as a tool for service technicians. The app is almost ready for field testing, but there is one thing i need the app to do before that. I need the app to force the user to log in every time its opened. This is because some of the info on the app is confidential, and only people that currently works for the company is allowed to have this info. Whit firebase i can then block the users that leave the company, or users that are not verified. Currently the users sign in whit google and they stay signed in until they clear the app data or delete it.
I have looked far and wide for the answer to this, but i have only come across different use of timers.
If anyone has a better solution to this "safety" issue, im open to anything.
If you are using Google Sign-In for authentication, there is no out of the box support for forcing your user to authenticate with Google every time they use your app.
This makes sense, because the user is still authed with Google on your phone. A login system only authenticates the user; it doesn't inherently protect data stored on the device. As long as Google has a valid access token, the user won't have to type a username and password again (and simply clicking "login with Google" again doesn't really provide extra protection here).
If your primary concern is blocking access to users who have left the company, you should be covered if you are using Google Apps for your company. If you disable the user's account, their access tokens should become invalid. Google Apps admins can also manually revoke access to specific apps for specific users.
If you don't use Google Apps (e.g. your users are using #gmail.com accounts or accounts from a domain outside fo your control), you might want to consider implementing a list of users allowed to access the application, and verify the current user has access by checking that list via an API call on launch.
If the goal is really protecting the confidential information in the application, you might want to take an approach similar to Android Pay in which you require your user to set and enter a PIN number to access the application. As an added benefit, you can then use that PIN to encrypt any confidential data you are storing locally.
I will suggest you take a look into shared preferences and every time when the user is back into the app you send them to the login activity.
I develop mobile cross-platform games (for iOS,Android and WP).
I want to know the email or the phone number of the people who bought my app from the iOS,Android or WP store, for using these informations for authentication purpose.
Waiting for your valuable comments and sugessions
Thanks.
You don't have that information unless people authorize you or give it to you.
Under no circumstances should you be able to get the information of the people who are buying your apps unless they opt into it and it’s made crystal clear to them that you are getting this information.
This was in the news last year because you shouldn't have that data.
This counts for iOS and Android.
options
Ask users for their personal information in the app and send it to
your servers.
Make your app need registration and login ( This is very strict on iOS, make sure you have some kind of offerable service which actually need registration)
You can link their personal information with device numbers, but these are spoofable on rooted and jailbroken devices
To get the device information on android:
You want to call android.telephony.TelephonyManager.getDeviceId().
This will return whatever string uniquely identifies the device (IMEI on GSM, MEID for CDMA).
You'll need the
<uses-permission android:name="android.permission.READ_PHONE_STATE" />
permission to do this.
On iOS look at this answer: How to get IMEI on iPhone?
I can only speak for iOS:
You can't get email address nor phone number using iOS APIs. If you want this, you need to ask the user yourself.
Then you'd need a way to verify them:
Email by sending a link they need to click.
Phone number by sending the user an SMS (with link they need to click, or code they need to type in UI), or by calling them and asking them to dial/DTMF a code they see in the app, or on the app enter a code they hear.
If you want to keep users apart, without needing any info from them:
Have a non-consumable in-app payment item (which you could call 'account' for example). Since these items can only be bought once per user, and because Apple's in-app purchase receipt contains a unique ID, you can use this as a user identifier. (If this does not make sense, you need to read Apple's documentation about in-app purchases.)
If you are asking the user for mail/no then just store temperorly and use webservice to retrive in background
If you want the details without knowing to user Use analytics and catch maild id's of user (flurry , google analytics)
I dont think this is possible currently. The playstore console displays information like number of download, carriers, devices, etc. You may want to consider building in those features and requesting the info from the user via the valid permissions. Aside there is an unofficial playstore API that lets you pull data viz. app info, comments, etc. You can find it here
In my approach, at first time user wants to pay by credit card, he must reenter his login password and full credit card info.
after success paid, I generate a random key, pack it as a keystore, finally store keystore file at internal storage, this keystore file is locked by user's login password. on the other hand, credit card info will be encrypted by this key and turn into a Base64 encoded string, finally write into a file in internal storage.
at next time pay by credit card, user also must reenter his login password, so I can use it to unlock the keystore file and extract key. at this point, I has ability to decrypt user's credit card info.
above is my approach to secure credit card info stored on device, is it secure?
DO NOT save user credit card data on a device! There's just no way to make it secure. Rooted phones can be a even more easier way for apps to access sensitive data. A device can get lost or stolen. You'll have to implement a secure user login to your server and store the CC data there.
Try using this http://developer.authorize.net/downloads/
It seems my approach in my post is finally my answer.
because andriod provide access limit on internal storage(see this link)
, even device get lost or stolen, hacker still can't access the keystore and break it by brute-force method.
But there is another issue.
In a rooted phone, 'bad program' is possible to listen soft keyboard, there are some other study work I should do.
You should never store a credit card number on a user device.
PCI requires a quarterly key change for your ciphered elements - so how would you accomplish that? Force the user to change his/her password every 3 months? What if they never log in to change it?
You method is extremely vulnerable to an attacker becoming a 'customer' in order to try to break your system - he'll be able to do it right on his own device without his attacked being detected or resisted. Then he can use what he learns to attack your other customers' accounts. Please let us know what web site you are working on - I want to stay far, far away from it when you are done if you follow this design method.
I'm creating an Android application for a fantasy league as part of a college project. It's a paid application, and requires each download to be associated with only one team.
I'm confused as to how best go about it. If a user goes to settings and clears the data from there, all files, settings and databases would be deleted rendering a locally stored indicator for "The app has already run before and hence user is registered" as pointless.
Another option that had come to my mind was to store the IMEI no on a remote database (with SHA1 encryption to protect the data) but the problem with this is that, if a user loses or changes his phone, his further participation would be impossible. Additionally, users understandably don't like to share IMEI numbers and it's acceptable.
The best solution in my mind was to restrict usage of the app to the Google account that was used to download the application. With this, even a change of handsets would allow further participation of the user. However, I've not been able to find a way to obtain the Android Market account (only require E-mail) which resulted in the download.
So, my question is, how do I best go about with the problem that I face? Is there a way to get the Android Market username? Or is there a worthy alternative?
The server-side option is what you want, you can get a unique id from each phone and use that as your identifier.