According to this topic: Can I use Purchase Status API to validate if app was bought via Play Store the Google Play Developer API provides a Purchase Token which can be fetched any time. So I imagine to send this purchase token to my backend server to ensure this user has already paid for my app, like it is written here: https://developer.android.com/google/play/developer-api.html#practices
Since the first comment on the posted anwer (see above first link) is, that there is no way to check if the playstore confirms the purchase I am confused.
I dont want to use InApp Purchases. I want my users to be able to buy an app and receive a piece of information for validating this google user has purchased it - in order to store set a flag in my own backend: "UserA: has_paid = true"
How can I achieve this?
Related
I would like to know if there is an API or endpoint that I can call/use to retrieve active subscriptions or the purchase history for a user and only to a specific app. To explain what I want to achieve, I am going to tell you what I currently have developed:
An Android app that has an active subscription that users can subscribe to.
Once a user pays and Google Play calls onPurchasesUpdated(), to deliver the result of the purchase operation, the app handles the purchase.
To handle the purchase, the app sends the sku, purchaseToken and other relevant information to our server.
As soon as the server returns a 200 OK to the app HTTPS POST request, the app acknowledges that subscription based on the purchaseToken.
If a user wants to check their active subscriptions that information is available through the following url: https://play.google.com/store/account/subscriptions
If a user wants to check their purchase history that information is available through the following url: https://play.google.com/store/account/orderhistory
So based on this information, I would like to know how can I obtain information about all the purchases (or the last one), either with the Google Play Billing Library or the Google Play Developer API (or other), so that I can access the purchaseToken information. My objective is to have a way to access, from within the app, a list of that user's subscriptions or just it's last purchaseToken. Note that I do not want to get access to a list that includes other apps purchases or history. Only the info about my app.
I'm trying to implement the backend of payment processor with google play in-app billing.
Google play billing api is tottally built for serveless scenario and is being a hell of a work to make it work for a normal world situation where apps have backends that need to validate and process payment logic.
i'm following this tutorial: https://developer.android.com/google/play/billing/getting-ready#configure-rtdn
but only after implementing the whole logic i read the small line
Real-time developer notifications (RTDN) is a mechanism to receive
notifications from Google whenever there is a change in a user's
entitlement within your app. RTDN leverages the use of Google Cloud
Pub/Sub, which allows you to receive data that is either pushed to a
URL that you set or is polled using a client library. These
notifications allow you to react immediately to subscription state
changes, avoiding the need to poll the Google Play Developer API. Note
that inefficient use of the Google Play Developer API can lead to API
quota restrictions.
so my logic integration is well done, the test message in play console works but google play billing is not sending the real notifications because my app deals with in-app products and not with subscriptions
then i read this tutorial https://developer.android.com/google/play/billing/rtdn-reference and it says
Note: A OneTimePurchaseNotification is sent only for some types of
one-time purchases. For more information, see Integrate.
but the link that was: https://developer.android.com/google/play/integrate goes to 404
does anyone know how to make google play console send notification for payment status on in-app purchases?
also how to get notifications for refunded purchases
OneTimeProductNotification was introduced in 2019-05-07 and its main purpose of handling cash purchases
https://developer.android.google.cn/google/play/billing/release-notes#release-2_0
As release notes says:
"This notification type is sent only for purchases associated with delayed forms of payment, such as cash"
+1 for your question becuase this is a weird scenario with lack of docs from google.
When I tested the notification from google play console by clicking "Send test notification" it works, but when I'm trying do so from my android app using testing client billing IT DOES NOT WORK!
but this screenshot says that
...for updates to your in-app products and subs...
In order to get refund purchases, you can try Voided Purchases API
The Google Play Voided Purchases API provides a list of orders that are associated with purchases that a user has voided. You can use information from this list to implement a revocation system that prevents the user from accessing products from those orders.
This API applies to one-time in-app orders and App Subscriptions.
A purchase can be voided in the following ways:
The user requests a refund for their order.
The user cancels their order.
An order is charged back.
Developer cancels or refunds order. Note: only revoked orders will be shown in the Voided Purchases API. If developer refunds without setting the revoke option, orders will not show up in the API.
Google cancels or refunds order.
Just copy and paste the below line of code to the permissions input box and then add this to the members.
google-play-developer-notifications#system.gserviceaccount.com
Next give permission to pub/sub publisher and you are good to go.
The mistake you would have done is you would have added a service account already present in your google cloud account which is not correct.
Above solution works perfectly fine for me!
I didn't find any definitive answer for my situation as all of this kind of questions revolve around server-side verification, which is irrelevant to me.
I'm trying to implement in-app billing in my app in order to offer the option of a premium upgrade. I've followed the guides in the developer documentation and done most of the work.
The problem is purchase verification:
The documentation suggests I shoud pass a developer payload to each purchase to uniquely identify the user - but my app doesn't have or need a user system - how can I uniquely identify a user without requiring user input or extra permissions?
Further and more important problem:
When the user makes a purchase, or opens the app after making a purchase in a different time, I need to verify this purchase - I don't have a server where I can send the purchase data to so it can verify it itself or using the Google Developer API.
It is my understanding that I shouldn't verify the purchase locally on the device (using the Google Developer API).
What is the best way for my situation to verify in-app purchases?
Is there a way to do it without a server? (I do not have the knowledge nor resources to have my own server)
I do not know how you would go about verifying a digital purchase without a network connection. Thankfully though, you do not need a user account system nor do you need the knowledge and resources to have a dedicated server because that is what Google Play services is meant for.
After setting up Google Play services; each user will be signed in through their Google Play account and be able to use their registered payment methods within your app when you implement the In-app Billing API. And you can test and manage all of this information from the Google Play Developer Console.
I'm creating an Android application that implements subscriptions to digital content on my backend server. What I wish to do is obtain the name and email associated with the Play account that made the purchase, namely the same information I can get if I go to my Merchant account and view an order.
Using the TrivialDrive in-app billing example, I'm able to access the INAPP_PURCHASE_DATA and send that information to my backend server as the "Checking Subscription Documentation" recommends: http://developer.android.com/google/play/billing/v2/billing_subscriptions.html
The documentation lists a typical implementation workflow and says:
When the user successfully purchases a new subscription, your app
notifies a backend server, which stores the purchase token, user name,
and other information in a secure location.
Although I can store the purchase token, and other INAPP_PURCHASE_DATA how do I obtain the user name or email for that matter. From what I can piece togehter I suspect the account details like user name, email, subscripion expiration date must be requested from my back end server. It seems using the purchase token on my backend server is the key to accessing order information, but at this point I haven't found any clear way to go about doing this.
Any suggestions would be appreciated.
Regards
There is an example on the Android Developer site here: Google Play In-app Billing
Testing In-app Billing
Administering In-app Billing
After that Adding items one at a time to a product list
like this
In-app Billing Reference
Then review this Agreement
Helpful links refund policy, In-app Billing, Implementing In-app Billing
Pls tell if you still facing the some problem :)
Thanks
I would like to setup subscription based billing for an app that will be sold through Google Play. Is it possible to sell the same subscription to the same user but on a different devices? So that every device that user tries to use the app on would need an active subscription?
I was thinking I could store the device id and user id on my own server and authenticate it that way, but is it correct that a user can't purchase the same subscription more than once? So would I need a pool of basically the same subscriptions if the user wishes to purchase multiple "licenses"? Can Google Play Billing handle any of this natively?
Thanks
The documentation from Google initially seems to make this impossible to achieve but digging deeper, I uncovered the following...
In the Google Play API version 2.0, you could create what was called an "unmanaged" product type that allowed the user to purchase the same thing multiple times. That seems to have partly disappeared in API 3.0 although the Gooogle Developer Console clearly supports this. I assume it's still supported because apps that used the 2.0 API are still out there and Google just can't drop support for that.
In 3.0 however, the "unmanaged" product type is not listed in the API docs but the docs state the following about making multiple purchases for the same product type (one-time purchase or subscription):
If you are using the Version 3 API, you can also consume managed items
within your application. You would typically implement consumption for
items that can be purchased multiple times (such as in-game currency,
fuel, or magic spells). Once purchased, a managed item cannot be
purchased again until you consume the item, by sending a consumption
request to Google Play. To learn more about in-app product consumption,
see Consuming Items
http://developer.android.com/google/play/billing/api.html#consume
IMPORTANT: Subscriptions CANNOT be consumed which means that if you want the customer to periodically renew their license, you will have to contact them and tell them that they must purchase the license again. That's a downside if your service requires a periodic renewal.
To obtain what you are after, you will need a backend server to handle the registration of devices and store tokens the apps receive from Google Play when purchasing. When a user wants to purchase your license, feature, service (or whatever) from another device, the other device MUST first release its "ownership" of the product with Google Play, through a process known as "consuming". It would work something more or less like this:
The first device makes a purchase and receives a purchaseToken
string from Google Play.
The purchaseToken along with the device ID is sent from the app to your server and stored.
The user goes to the second device and wants to purchase the license as well for that device. The app first needs to go to your server and obtain the purchaseToken (that the first device uploaded) and then call Google Play with consumePurchase which releases the "ownership" of the product from the user.
The app then purchases the new license (or whatever) from Google Play, gets a new purchaseToken and stores it on your server along with its device ID.
In essence, Google Play won't keep track of which device has the product. It only associates the Google Account with the product being purchased. It's up to your app and server to manage the licenses.
There is one potential problem I see that you need to address. If for some reason the app fails to send the purchaseToken back to your server (your server is down, the user dropped their device and broke it, your app crashes before it saves the token on the device, etc.), then you may not know if the user paid for the service. Google does provide a server API that lets your backend server query Google Play on Google's server for information about purchases, but I'm not familiar with it nor its limitations.
You will need to implement in app purchases as you would for any other in app item.
Make sure when you create your item in the Dev Console, it is unmanaged, as managed items can only be purchased once per account.
When you receive a confirmation on purchase of your unmanaged item, send the details like the unique ID to your server and store them there.
Now whenever your app starts, check with your server if it is an authorized device. If it isn't, prompt the user to buy it. If it is, let them continue to the app.
This only works if you need a one time payment. If you need a subscription, you will have to make it up of multiple one time payments, as subscriptions are like managed purchases and can only be paid for once by any account.