I wish to verify a receipt of in-app purchase in an app through google play using a php page.
How should i do it?
I'm no PHP expert so I'm not going to post any code, but the overall process is very straight forward and it should be dead easy to port to PHP. You need three things to verify a purchase:
Your app's public key (from Services & APIs in Google Play Developer
console)
The original JSON of the purchase
The purchase signature
If you implement in-app billing on Android using the IabHelper classes you'll get a Purchase object when you make a successful purchase or when you query the inventory. The Purchase object contains two methods that you need: Purchase.getOriginalJson() and Purchase.getSignature().
Securely store your app's public key on your server and POST the signature and the original JSON (base64 encode it before you send it) to you server. Retrieve the signature and json from $_POST and refer to Google's Java implementation of how to verify a purchase. It seems as though you can use PHPs built in openssl_verify function.
Related
I am interested in writing some basic php to interface with the Poloniex push api.
Their website provides the following info:
https://poloniex.com/support/api/
A php wrapper can be found here:
http://pastebin.com/iuezwGRZ
From what i can determine there are three APIs being push, public and trading. The public and trading APIs provide functions that can be passed parameters etc. The push api stumps me totally as i cannot determine how it works.
The first link above states the API pushes live data and different feeds can be subscribed to.
My questions are:
A) How can php receive a live stream of data?
B) How do i subscribe to a feed?
I may have misunderstood the oush api and my apologies in advance if this is the case.
Edit1:
I believe i need a WAMP client to connect to a WAMP router such as Minion.
https://github.com/Vinelab/minion
Edit2:
Node.js example
http://pastebin.com/dMX7mZE0
The push API is based on Websocket protocol.
Initially you need first to make a connection to the websocket server,
after that you need to register to a data stream (price update stream for example), after that as soon as the server make an update to something (a price ), all connected clients who where previously registred to it will synchronously received the updated price
Finally you got the last price without the need of doublecheck at regular interval if the price has changed
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.
I'm trying to implement a feature to update my server side database when someone purchases a managed item in my Android application.
Basically I want the user to be able to log on to my website when the managed item have been purchased but not before.
Can someone please provide me with details on how to accomplish this.
Someone I would like to send a username/email or similar to the web page that I can use to update the server database. However I need to make sure this cannot be sent by a user that have not purchased the managed item in my Android application
I have read some good post on this subject, but I still don't see how I can apply this in my solution
How do I verify Android In-app Billing with a server with Ruby?
http://crazyviraj.blogspot.se/2011/06/some-notes-on-implementing-in-app.html
Best regards
Google play store sends signed data and signature of each individual purchase. On successful purchase of an item from your android application, the application needs to send in the signed data and signature to your server. This data then needs to be verified against the public key. On successful verification, you can then intimate the android application with the success response and the required credentials for him to login.
EDIT :
Android Inapp Billing Overview
Sample Inapp Billing
Sample BroadcastReceiver
Please check the android sample inapp billing implementation. That has a dungeon's example which implements inapp billing. You need to implement a BroadcastReceiver which gets the data back from GooglePlay. com.android.vending.billing.PURCHASE_STATE_CHANGED intent represents that a purchase has happened. Now you can get the signed data and signature from the intent like
String signedData = intent.getStringExtra("inapp_signed_data");
String signature = intent.getStringExtra("inapp_signature");
Now you may need to pass in this data to your server to identify the user who actually purchased it. Hope it helps.
I'm developing a PHP application to retrieve the list of contacts from a GMail account. I'm looking for a solution which would enable the user of my application to provide the login and password to their Gmail account in my application (as opposed to getting redirected to Google) and then automatically do the retrieval. The retrieval process can be run in PHP or JavaScript (which would then feed the list of contacts back to PHP using Ajax).
Is it possible to do that? Which JavaScript API should I use for that? Can someone point me at the right chapter in Google Contacts Data API documentation?
This is really not advised - google provide OAuth for a reason - so that users won't have to give their credentials to 3'rd parties.
Check out http://code.google.com/apis/accounts/docs/OAuth.html
Speaking only for my self (and all other developers I know), having to hand over my credentials to 3'rd parties is a real no-no.
It would be best to use the Google Contacts Data API using JavaScript for your case.
I haven't tested it myself but it looks nice: http://gmail-lite.sourceforge.net/wordpress/
//edit:
You probably should use: http://code.google.com/apis/contacts/