I am writing the PHP back-end API for an Android application. The Android sends me purchase token, product name, etc and then I make this call : Purchases.products
I then acknowledge the purchase using : Purchases.products: acknowledge
Then after successfully processing the transaction on PHP API side, I would need to change the 'consumptionState' of the transaction on Google Play side to indicate that this (consumable) product has been been consumed. But nowhere can I find any example of the call needed to change the 'consumptionState'. I use google/apiclient package for the interaction with Google Play.
Can someone point me in the right direction with regards to changing 'consumptionState' for a Google Play Billing purchase?
Related
I have made a php based website and working on payment integration now.
I want to add upi payment option with paytm, google pay, phonepe and bhim.
Once user clicks on icon, appropriate app with predefined VPA and AMOUNT should get loaded
Please help
The way to do this is to follow the UPI linking specification (page 5).
Assuming that the link will be presented on a mobile web browser, your link should look something like: upi://pay?pa=<VPA>&am=<AMOUNT>
You can integrate the UPI intent solution provided by paytm. This will work fine in mobile view, through this integration you will get the deeplink.
You need to call the deeplink provided which will invoke all the UPI PSP Apps on the device and shown to the user with payment amount already filled.
Just for your information UPI intent will not work in web/desktop. You can integrate UPI collect to support web/desktop payment.
I have written a web app in PHP which is an MVP for a product I am launching. Uptake is good and I have active users.
I notify users of certain events right now by integrating with Twilio and sending them an SMS when activity happens on their account.
I would like to release an iOS companion app so that I could notify them via native push message as Twilio SMS costs are decreasing the viability of my product and I do not want increase the monthly price.
I have researched various third party tools such as Pusher, Pushover and Onesignal but none of them seem to fit my need, as far as I can tell.
How could I trigger a custom push notification to an iOS user using my iOS companion app? Ideally I would swap out the Twilio api call and insert something else that called the push message.
Our server uses the PHP SDK to validate subscription purchases.
https://developers.google.com/android-publisher/api-ref/purchases/subscriptions/get
Is it possible to view purchase history on the server side via the SDK, or some endpoint? Basically I'm looking for a way to get the subscription order number.
There is currently no API or endpoint that you can call/use to retrieve subscriptions/purchases history for Google Play.
AFAIK, the expected procedure for this is for developers to keep track of the history on their end by storing and keeping track of the orderIds and purchaseTokens accordingly on their side.
I have a new question. This is my context:
I want to make my own API REST, where I can call this method with information about my product as parameters. My backend method do the typical purchased process but it doesn't show the PayPal screen which show information about my product, just do the process directly and I receive an answer. Is it possible?
I'm using the PayPal SDK for PHP, and looking for at Google I just have gotten that the PayPal page shows, but I'm new in this. Your answer will be so good!
Yes, this is very possible. There are plenty of tutorials online for building your own REST service, and within your service methods you can hit other APIs or do anything you need to do.
Your service can parse the results from the 3rd party service you're hitting (you could hit 10 different services if you wanted to) and then you would generated your own basic response which includes a collection of all that data back to whatever client hits your service.
I was following these articles: Verifying Back-End Calls from Android Apps and Stopping Vampires using License Verification Library (from 24:57 to 25:34) to implement an In-App Purchase verification system for our Android apps.
I am a bit confused about how this works end-to-end and what we can assume about the generated token from calling GoogleAuthUtil.getToken() with the first email address found--when AccountManager returns more than one account. My questions are as follows:
Should we assume that any e-mail address used by the user to buy our
app will generate the same token (i.e., same user + app ==> same
token)?
If the answer to question 1 is no, is there a way to launch in-app
purchase for a particular account/email?
It looks like Google is picking the first e-mail address returned by
AccountManager for its in-app purchase dialog. Can we assume that
this won't be changed by the user after in-app purchase dialog is
launched? How do we find out if this changed after the in-app
purchase returns?
What should we store in our database to identify this user? Is email
address and/or token allowed? When does the token expire?
The java-client library looks very promising and powerful at first
read. But, a number of things remains confusing. Is there an article
that describes the end-to-end scenario--from an app initiating a
call to a back-end server through launching the in-app purchase
dialog, getting the result and closing with commits on the server?
What articles are the most useful for accomplishing this on Android?
The main issue we are trying to solve is to to get the full picture.
We've gotten the idea that we can avoid requiring userid/password by using the java client features and using tokens. We have registers our project (both the web app and android app on the same project) per the instructions for Google API Console. We have the php java-client for Google Play Service on our back-end server. We got our Android app to generate a token using the first email address and then call the in-app purchase dialog and handle the user response at the end of the dialog. We've got the parts. Now, we need to glue everything together. We are at the point of integrating with the back-end server. E.g., What is Redirect URi supposed to point to in our server? We've got a php url that we do http post messages to for our server app. We've included the code example for Google API client example--with client-id, secret, simple api key, etc. filled in--as an include to our php. But, what should we put in the redirect uri (we are missing a usage instruction for the example code)?
Also, we want to avoid having the e-mail used for the in-app purchase be different from what we log on our server database as the address the user used to buy our app; if the address is the correct thing to track, we want it to be the same as what was used for the purchase. This could be frustrating for our user if we make this mistake and prevent them from the features they paid for. We don't want to make this mistake and need some clarification on how Google Play Service works. If we initiated the server part of the workflow to get app Nonce / Payload / Credentials for the first e-mail address on the Android device, we would want that address to be used throughout the workflow. If the user changed this along the line, we want to be aware of this and gracefully recover. So far the articles have been helpful but incomplete. Any insight/suggestion is appreciated.