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.
Related
I'm fairly new to the PayPal API and am a bit confused about using API signatures to attach to the REST API. I'm creating shopping cart software, and I'd like to allow merchants using the software to attach the system to their PayPal account using their API using PayPal username, password, and signature. They'd enter this information into the account settings when setting up their cart.
On the merchant's side, it seems like this is easily possible, and says to do this to grant API access specifically to shopping carts:
htttps://paypal.com/us/cgi-bin/webscr?cmd=_profile-api-access (once logged in as a merchant).
I personally am using PHP to call CURL, though that probably is not important. What I don't understand is that in the REST API documentation, including the "make your first call" doc, it notes I should send my "clientid" and "secret," but not the merchant's "username","password," and "signature".
https://developer.paypal.com/docs/integration/direct/make-your-first-call/
Now, when I originally logged in as a developer, I was able to obtain my "clientid" and "secret," but that was for my application. I've successfully made test calls with them, using PayPal's test pages. But these of course seem to be for me, not for a particular client.
Now the "Classic API" documentation does have information on connecting to the SandBox using the merchant's info.
https://developer.paypal.com/docs/classic/permissions-service/ht_permissions-invoice/
So I think I'm just mentally missing something, or misunderstanding something fundamental. Assuming I have both my developer credentials, and the API credentials of a merchant, what are the general steps in making a payment to the merchant (not me). What's the logical step I'm missing?
Thanks much to anyone who can help.
Unless corrected by Paypal folk, this seems to be the flow (just went through it):
Ask the merchant to add you as a User, I suppose with API access privileges (only)
They will set your user id and pwd, which they should then provide to you.
You'll then login with that User Id (not an email address) into Paypal (at this point, you're a "user" of that merchant/account) with whatever privileges your merchant provided you.
create the App in the developer site for your merchant - you'll notice that when you get there, it's the Merchant's name displayed (it's not "your" developer account)
At this point you should be set (sandbox and live REST credentials of the merchant from the app you created). One thing I noticed (good) is that it somewhat already helps you see what "live privileges" the account has..so it helps guide you as to what to integrate (scope) and/or advise your merchant to do - e.g. may or may not be eligible for direct credit card payments (only Paypal account payments).
Hth..
#EdSF and anyone else looking into this, I just received a response from PayPal merchant help. Turns out you were spot on Ed. They don't have this ready for REST. Seems pretty odd given that they're 1.) pushing REST on their developer site but 2.) showing that the signature set is how to connect to a shopping cart on their merchant side.
So answer is to use the old API for now, or have them go through the extra hoops of the steps you/they mention, instead of following the directions on the PayPayl site :-P Oh well. Their response in full below.
Hi ...
I am writing this email regarding your questions on PayPal Permission Service. Unfortunately the Permission Service is not available in REST API; however I will file feature request to our development team for their further consideration.
It is not possible to use API username, password, and signature in REST API because they are actually not the correct credentials. REST API uses Client ID and Secret for integration. If you develop your application for other merchants, you can ask them to obtain Client ID and Secret by creating apps in PayPal Developer Portal (https://developer.paypal.com). Here's the steps:
1) Go to http://developer.paypal.com and log into the website with PayPal account's login
2) Click 'Dashboard'
3) In the My REST apps page, click "Create App"
4) Enter the App name, and click 'Create app'
5) You should be able to see 'Client ID' and 'Secret' for 'sandbox credentials'. If you want to integrate with your live account, click 'Show' at the Live Credentials section.
Hope the above information helps. Thanks.
Sincerely,
...
Merchant Technical Support
PayPal, an eBay Company
I want to automate BITCOIN payments and i need to make a donate button that sends an aditionally OP_RETURN parameter with the value of the encrypted order id. I just want to send a small message with the payment. I have documented myself a little bit and i saw that OP_RETURN parameter may help me.
OP_RETURN :
http://bitzuma.com/posts/op-return-and-the-future-of-bitcoin/
How do i make that happen? Is there a wallet that does that? Or I have to do it from bitcoin-cli?
I also want to make this in PHP and here is an example that i don't understand :
https://github.com/coinspark/php-OP_RETURN
I mean i need a button that will make a payment with that encrypted order id.
Thanks in advice.
You will want to do that server side via encrypted and authenticated client using BIP 70 - AKA The Bitcoin Payment Protocol.
You can create a browser side client to do as you described but you do not want to trust the data the client sends along without verification and you checking the transaction before it is sent to the network will not make you trustworthy as a merchant but rather a MIM between the user and the blockchain.
For more information on BIP 70 The Payments Protocol
See: https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki
I am trying to develop an android app that verifies a transaction initiated from a browser on a PC. I want the server application to push a notification of a new transaction to the app so the user can confirm to complete the transaction. The tricky bit is the transaction is specific to a particular person (I'm using this as an alternative to sending an SMS for example). Can anyone help on how to go about this? Is it possible to do this with C2DM or GCM?
Using Android GCM is advisable. The complete reference to GCM is available at
http://www.androidhive.info/2012/10/android-push-notifications-using-google-cloud-messaging-gcm-php-and-mysql/
Step by step GCM development is given in there. It is really very helpful. Hope this is helpful to you.
The critical thing you need to keep in mind before making a decision is that when you are using GCM, you need to keep a track of the users by keeping their GCM_ID in your database. You can add a gcm_id column to your users table for this and whenever the user opens your app, the gcm_id should be updated in your database. The gcm_id of the user's phone can change, from the official docs:
Note that Google may periodically refresh the registration ID, so you should design your Android application with the understanding that the com.google.android.c2dm.intent.REGISTRATION intent may be called multiple times
GCM push notifications wont be able to reach your users mobile phone all the time,especially if his phone is not connected to internet or switched off.You are using this for transactions etc, so I assume that the notifications must not fail. You should keep a check in your web application to send an SMS or notify the user that this has failed. You should get a response from GCM to your server through which you can identify a failed case.
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.
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.