I would like to implement in-app billing in my android app, but I am not sure how should I create for a developer payload. I don't have any information about user, only unique identifier created in the app to recognize it.
Is it possible to restore the purchase when the user buy a product, then uninstall the app and install it again? How to test it, because I didn't get any events when I tried to test it?
Yes, you can check the completed purchase after uninstall app and install it again.
All purchased items stored on the Play Server and particularly in your installed Google Play app. So after item is purchased once the information about purchase is stored and you can request it at any time untill you "consume" this purchase. "Consume" means reset the information about purchase to allow make new purchase with same ID. This is only for v3 if Android Billing Library, because all purchases in v3 are one-off (you can buy it only once) and have to be "consumed" to be purchased again.
The identifier of the purchase item is a simple string that you define in the Google Developer Console. You should login to the developer console, create new project for the future app, upload signed .apk (necessary), after that you have to select the project, move to "In-App products" section and there you can create necessary purchase items with purchase IDs. While purchase action in the application you should pass the matched purchaseID to the launchPurchaseFlow() method on the IabHelper object (these are all from v3 Billing Library). The information about purchased items can also be received by using matched purchaseID.
Official Google developer documentation has pretty decent amount of information about implementing and using Billing Library:
Implementing billing library guide
Administering In-App products in the developer console
Testing In-app billing. Sorry, cannot post link because of lack of reputation (2 links in answer only), but you can also find this section in the official android documentation. This section also has information about testing with special android test purchase IDs which doesn't require signed and uploaded .apk or any actual money-transfers
Related
I've developed an Android app and need clarity on what is required to offer it, via Google Play Store, as a subscription app (i.e. offer use of the app for a monthly fee). For now, no in-app purchases or in-app subscriptions are planned; the only subscription is for use of the app itself. All of the documentation I've read about subscriptions from the Google Play Store seems only to discuss in-app subscriptions.
My questions:
1) Is an overall app subscription treated/processed the same as an in-app subscription (i.e. via the app)?
2) If not, what portions of the Google documentation/guides on subscriptions do I implement? Everything that isn't expressly mentioned as being for in-app subscriptions/purchases?
3) Do I need a back-end server to manage/track app subscription info, or can subscriptions at the app level be managed via Google Play Console?
4) Is there a guide/example/tutorial somewhere that clearly explains how to implement what seems like a basic solution, a subscription app with no in-app purchases?
Examples of what I found during research:
Create a subscription - Play Console Help indicates:
Create a subscription
Using Google Play Billing, you can offer in-app products that charge users for content or services on a recurring basis, known as subscriptions. Subscriptions can include items like a collection of apps, games, or other content for a recurring fee within your app on Google Play.
In Google Play Console, subscriptions are only mentioned (from what I can see) under Store presence->In App Products->Subscriptions
I reviewed other questions on SO related to subscriptions, but virtually all appear to be focused on in-app subscriptions. One exception was Implementing a Yearly Subscription. Per the answer from GNUzilla, I understand the need to create a payment profile in Play Console. The second part of GNUzilla's answer references the now deprecated AIDL interface, so I instead reviewed the guide page for its replacement, Use the Google Play Billing Library | Android Developers. However, this also appears focused on in-app subscriptions. For example,
Enable the purchase of an in-app product
...
To start a purchase request from your app, call the launchBillingFlow() method from the UI thread. Pass a reference to a BillingFlowParams object containing the relevant data to complete the purchase, such as the product ID (skuId) of the item and product type (SkuType.INAPP for a one-time product or SkuType.SUBS for a subscription).
Is an overall app subscription treated/processed the same as an in-app subscription (i.e. via the app)?
There is no such app subscription feature Google has implemented. It always will be in-app subscriptions. User will download the app free/paid and login/signup into the app then the developer will show the subscriptions plan based upon the business case.
If not, what portions of the Google documentation/guides on subscriptions do I implement? Everything that isn't expressly mentioned as being for in-app subscriptions/purchases?
In-App subscriptions. Check here https://developer.android.com/google/play/billing/billing_subscriptions
Do I need a back-end server to manage/track app subscription info, or can subscriptions at the app level be managed via Google Play Console?
Yes, you need the backend for managing the real-time notifications. If you don't want to have the backend then you will miss lots of scenarios like your app don't what is the current subscription status. It is also good from a security point of view to verify the purchase in the backend.
Is there a guide/example/tutorial somewhere that clearly explains how to implement what seems like a basic solution, a subscription app with no in-app purchases?
You can check google documentation here. In the future, I will also publish the blog regarding this.
I want to add an android in-app payment method, so I followed instructions by this page using AIDL
I successfully added it and tried to do an effective payment using my personal google account. The payment was successful but I didn't receive the money.
I know that, implementing this type of purchase, a user can buy add-on app features or simply make a small donation. Isnt' it? Is there a better method to do that?
As Google say in billing testing: To test your Google Play Billing implementation with actual in-app purchases, you must use a test account. By default, the only test account registered is the one that's associated with your developer account.
Money not charged if you account equivalent to you Google Play account.
Also you can try to use more convenient library from google for in-app billing
When I try to use a in-app billing item its api show that: “The publisher cannot purchase this item”
I want to check in my app if the user is myself, a google Play Store user and the publisher of app, to put all inapp billings items free for me, so how could I check programmatically if the who user is trying to buy in-app billing item is its publisher?
A developer cannot purchase anything from herself. To fully test, you will need to create a test account in the Developer Console and then install your app on a device where that is the primary account. There is no other way. See
http://developer.android.com/google/play/billing/billing_testing.html
In my game I have InApp Purchases. I want to test my game before publishing, so I uploaded it to alpha. I would love to test it on my phone, but google refuse, saying a developer can't buy his own products. Google also refuse to allow emulators to purshase items.
Yesterday I added a google account to my phone, and added it to the list of people allowed to download my app (Gmail accounts with testing access).
My problem is that I can't access my game (We're sorry, the requested URL was not found on this server). My game is available (I checked it from another phone and its good). I simply can't access it from my test account.
What can I do? Should I do something, or I will not be able to test my game on my phone no matter what?
Here is the android developer help for testing in-app purchases. The second account you added should be able to access the game shortly. In my experience, it usually takes up to about 24 hours to access alpha/beta testing once a user has been added.
Here's some specific stuff from that post:
Test Purchases (In-app Billing Sandbox)
Test purchases offer a secure, convenient way to enable larger-scale testing of your In-app Billing implementation during development or in preparation for launch. They let authorized user accounts make purchases of your in-app products through Google Play without incurring any actual charges to the user accounts.
Once authorized for testing access, those users can make purchases without being charged. Test purchases are real orders and Google Play processes them in the same way as other orders. When purchases are complete, Google Play prevents the orders from going to financial processing, ensuring that there are no actual charges to user accounts, and automatically canceling the completed orders after 14 days.
We recommend that you first test your In-app Billing implementation using static responses from Google Play. This enables you to verify that your application is handling the primary Google Play responses correctly and that your application is able to verify signatures correctly. You can do this even if the app hasn't been published yet.
To test your implementation with static responses, you make an In-app Billing request using a special item that has a reserved product ID. Each reserved product ID returns a specific static response from Google Play. No money is transferred when you make In-app Billing requests with the reserved product IDs. Also, you cannot specify the form of payment when you make a billing request with a reserved product ID.
In Android In-app billing version 2 subscription static response is not working, This static response like android.test.purchased is working for inapp products, but the same is not working for subscriptions
1) IS there any other of testing it( we would like to do a static response testing which save our time
2) Can any please share a working code of in-app billing subscription
Testing inapp subscription billing is horrible. You can test out of your SDK for the adroid.test.purchased to make sure you are parsing responses properly. To test the subscription, add a test product to the subscription products on the developer console and publish the product. You must publish the products for this to work. Get up google groups and add test email accounts to the group. Invite the testers. THEN upload your .apk to an ALPHA and publish it. you must publish it as an alpha for the test phones and logins to find it.
Go to the link provided under the ALPHA tab to set up testers and log in from the phone using one of the test emails. Buy the inapp product to make sure all your code works. You can cancel the test product purchases in the Google Wallet and re-use the products until the code is correct. THEN set up a test subscription product. You will only be able to test the subscription once per test email. There is no way to remove the test subscription. Be sure to change the product names in your apk before you upload. Also, change the version code in the AndroidManifest, and turn off debugging.
If you try to install the app twice on a device, you may need to clear the data from these apps under settings in the phone: chrome, play store, play services, or it will continue to think you have it installed and won't download it. You must access the test .apk from a browser, NOT through the play store.
This is the most onerous testing I have ever experienced. Also, watch for errors from Google IABilling response, since the "already owned" response for a product is different for a subscription. I am still trying to figure out what the response is for the already owned subscription. Will update if I find out. This explanation is the ONLY information available anywhere that I have found, and this was weeks of trial and error. If you have more data on this, please share!!!