I see some apps direct user to their website to buy a serial number from paypal, and some apps may need a username also.
Then user can return back to app and input the serial number and username if needed into to get some pro features like removing ads.
I want to do the same thing in my app, can someone help explain how to make it work ? is there any third part library to use?
To be clear, I do not want to use the in app purchase in google play.
You will have to write your own back-end that handles all transactions.
Then when the user has done a transaction your app will have to communicate with your back-end to confirm that the bought codes are correct. There is a lot of security that should be implemented aswell.
I would say that since you have to ask the question, you should use the in-app purchase in google play since its already implemented and streamlined.
Related
I am building a website for a client that is promoting an App on Kickstarter. As one of the rewards this client wants to reward sponsors with in-app purchases. I have searched Apple and posted on other forums but I can't find out if this is possible and if it is possible, how it is done.
Thanks.
You need to implement a promo-code dialog inside your app to do that, then send promo-codes to your Kickstarter users.
I don't think It's possible.
Here's the only Google documentation I could find.
You could make the app free for a short period until all backers have their copy and then raise the price but non backers will be able to download it too.
It would be possible however to use the alpha/beta functionality in the Google Play store to release the app to backers who have joined specific circles setup by you. I don't know if Google would have a problem with you using it like this.
It might be possible to distribute the app outside of the Play Store but I suspect that will become a big support problem as users struggle to get the app installed and keep it up to date.
For iOS part we haven't this functionality with Store Kit. This framework was created to securely process payments from users. You don't need to work with payments. Just deliver some product or an extra functionality to user with promo code. Implement a dialogue in your app where user can enter his code, send this code to your server, check it and give an access for user, if code was right. That's all you need. After making the product available, your app needs to make a persistent record of the "purchase" like you do with normal in-app purchases.
I am working on an app that would require an activation code in order to be used after being downloaded (user will get the code by postal mail). I understand that Apple will be rejecting the App, but can someone confirm if that functionality (activation code for an app) would be valid for Android? And that it could be used.
Before building up a prototype I would need to confirm this fact.
Anyhow, I will limit the audience of my App to Android users as I see that I have no options with MAC.
You should read the Google Play Developer Policies as your starting point (in particular the section "Paid and Free Apps").
If you are using activation codes to bypass app payments or in-app payments, you will be in violation of Google's policies. If the activation code is an integral part of your app's functionality (for example you are sending it by post to verify a user's address) then you should generally be okay.
Disclaimer: I am not a lawyer.
I was using an app once that was later pulled from the Play store because you could purchase some premium features over PayPal (without Google Play). If you intend on charging for this code it might and probably will be an issue, however, if you will distribute the code free of charge to select customers it might work.
But, a better way of doing it would be with a Google Play group. You'd mark your app as beta and make a test group, that would only include the people you want.
But if you want to limit your audience there is really no reason to put your app on Google Play, just distribute your .apk file through your website, and have a serial code as a backup.
is that OK and safe to set a value in SharedPreference to flag that the user have purchased this item? What if user hack this value in SharedPreference. Or I need to connect IAP service everytime to check that before user can use it?
(1) What is the best practice when I use Google Android IAP V3?
(2) And also if user's device have no Google Play installed, I may want to use paypal to make the payment, but how to track the purchase and unlock the features for users if I ask user to use simple paypal payment to get a license key? I do not want to use any other billing SDK, if with Paypal web page to buy the license, How to implement this?
(1) What is the best practice when I use Google Android IAP V3?
--> official document says that only payment transaction will be handle by google play itself, but in the application you have to set your business logic how you handle UI integration and other things after product purchase. You can also go with the in app purchase v3.
(2) And also if user's device have no Google Play installed, I may want to use paypal to make the payment, but how to track the purchase and unlock the features for users if I ask user to use simple paypal payment to get a license key? I do not want to use any other billing SDK, if with Paypal web page to buy the license, How to implement this?
--> You can ask user to update google play version dynamically. Google developer doc says more than 90% device using 2.2 os with installed google play store. I could not say any thing about paypal transaction because I haven't use it before, but yes in app purchase using v3 is very simple to implement and understand the payment process.
How to use in your application
Three way to manage your application's product data.
1) SharedPrefrence:
you can use the share prefrence value and check whether it is purchased or not. if in case user uninstalled the app and then re-install the app then you can check whether user has purchased or not, at this you get the item is already purchased. And you have to manage the user to access your application data.
2) local database:
you can also use local sqlite database to store the purchase detail and purchase status. and same as above if user clear data or uninstall the app then request for the purchase item again and check whether user purchased item or not.
or
2) Server database:
It is the better way compare to above if you are using web server to store the user data. In this type, you doesn't even need to manage for the second time for the case if user uninstall the app or clear the application data.
3) obfuscation: (Most efficient way compare to shared prefrence)
EDIT:
is that OK and safe to set a value in SharedPreference to flag that the user have purchased this item? What if user hack this value in SharedPreference. Or I need to connect IAP service everytime to check that before user can use it?
While I am searching on internet I found Nikolay Elenkov's answer like below:
If you just save a flag in shared preferences, any user with a rooted
device can flip the flag at will and be 'subscribed' without paying.
So you should at least do some obfuscation. Here's a sample way to do
it. Additionally, there is an API to check for subscription state, so
you should check periodically to make sure the subscription is valid.
more information check Nikolay Elenkov's answer
What is the best for billing Either In app purchase or Paypal?
It is depends on the product type,
--> In app billing: Best for google in app billing,
For the digital products including downloadable content such as media
files or
photos, virtual content such as game levels or potions, premium
services and features, and more.
http://developer.android.com/google/play/billing/index.html
--> Paypal: Best for Paypal billing,
For physical content or product do you want to share. You are not
permitted to sell physical goods or services using 'In-App Purchasing'
since the goods purchased via this method must relate directly to the
app using them.
Purchase physical product from iPhone app without Apple in app purchase
Hope it will help you.
from the documentation:
Because the Google Play client now caches In-app Billing information
locally on the device, you can use the Version 3 API to query for this
information more frequently, for example through a getPurchases call.
Unlike with previous versions of the API, many Version 3 API calls
will be serviced through cache lookups instead of through a network
connection to Google Play, which significantly speeds up the API's
response time.
Which basically means you can look up the purchase each time and the Play Store app will respond pretty much right away.
From my experience I can assure you of one thing.
** In fact it's bad to put a flag with a bool saying if it's premium or not **.
What I do is obfuscate the shared code
After I create some strange strings or numbers that only identify through the code inside the app if the user is a premium user.
Along with this, except for a numeric code within the database that identifies the type of purchase. So by checking both I can make sure the user is premium.
At this point if they want to cheat me with the root of the phone they should first understand how the code of my app works and then understand where to interact, because if only the shared preferences change, nothing will change and they will be whipped.
** This doesn't translate to high security, but at least the security level is higher and the root won't be able to get a reward that easily. Also because they should understand what are the exact codes to insert in the shared, in the database and look for them by removing the obfuscation. I honestly don't think it's worth it for them. **
As what Kuffs has mentioned, it is best to query the app-side implementation of the In-App Billing library which in turn queries the device's Google Play client. This will ensure that the purchase history most recently obtained from the Google Play servers would be reliable and relatively fresh information.
Also, keep in mind that if you are distributing the app on Google Play you MUST use the Google Play payment mechanism via In-App Billing. As it stands, Google Play and Wallet do NOT yet support Paypal or wire/bank transfer methods so you should not integrate the option if you are releasing it on Play.
http://play.google.com/about/developer-content-policy.html#payments
I need to check, using APPLE ID/GOOGLE Android ID, if the user really has paid to buy my app.
I have to avoid an user use a cracked app (jailbreak)
Is there a "public key" unique for each app? I can use that (if exist) to check the unifier of my app
In short: No. You do not have access to this information via the API, but as others have said, you can roll your own solution via in-app purchases and your own server. If your concern is that unlicensed users will consume server bandwidth or other expensive resources, I'd suggest doing this.
If your end goal is just to prevent piracy, though, I'd suggest googling some of the off-the-shelf anti-piracy solutions available today. Even then, however, I would not expect miracles. I have implemented as many anti-piracy techniques as I can develop within a few of my own clients' apps, but to date, none of them remain "uncracked."
You could do something creative involving in-app-purchase and pinging your own server when the purchase is completed. This assumes you want to put content behind the IAP paywall and that you want to run your own server which perhaps isn't the case.
On Android, use the license verification library.
You could make it available for free on the AppStore, and then use a licensing or in-app purchases to deliver more content (full-content) to the users !
We are about to release an application on the Android Market, with In-app Billing for subscription that unlocks certain features for a the subscription period.
My boss now wants me to implement varying number of "free subscriptions" in the sense that:
The "lucky user" downloads & installs the application from the Android Market like any other customer (always free to install, but premium features require payment via In-app Billing).
The "lucky user" receives some key via email that allows him or her to avoid going through the In-app Billing checkout process (i.e. actually pay).
The key can only be used once.
Entering the key via a menu item, enables subscription for X months, as if he actually paid via In-app Billing.
The "key" basically acts like a coupon, but I haven't found any such option in the Publisher's Console.
Do you know of any such feature or a simple way to implement the above without duplicating the customer database on our (the publishers) server?
I actually dove into this subject maybe 2, 3 months ago. My conclusion was that currently there's no way of setting up this system, without using your own server.
Generating unique coupon-codes and expiring them on use is pretty straightforward. Let the user enter the code, send a POST-request to your server, hash the code both client- and server-side and see if they match. Next, expire the code serverside and you're set. It does however make your app vulnerable to piracy (if it isn't already); if you have a high-profile app, make sure to implement security checks (e.g. check SSL certificates to prevent a man-in-the-middle attack).
The hard part is reinstating previously acquired 'freebies' when users reinstall your app or change phones/firmware. For this purpose you're going to need a stable and reliable (cross-device) form of identification (e.g. access to the user's main Google-account on the phone). If you use user-provided e-mailaddresses, it's too easy to just enter someone else's e-mailaddress. If you were to implement a coupon-system, I would advise against reinstating 'freebies'.
I know this is a really old thread, but I had a similar need and found an official solution. For anyone who comes here for a solution:
Google introduced Promotional Codes couple of years ago and that is exactly what you're looking for.
You can create Promo Codes on the Play Console under Your App -> User Acquisition -> Promotion.
You can use promotions to give users a paid app or in-app product for free with a promo code. You can create promotions to reward loyal fans, acquire new users, and reconnect with previous users. Learn more.
yuo can add a screen for enter a coupons.
and the user can go in there and insrert his code and if it is correct you can give him whatever you want.