Develop Reference

Android In App Billing... Why is there contradicting info?

I, like so many others, am just trying to test my in app purchases after verifying that the static responses are working. But as I read the docs, the posts, and the answers, nothing seems to add up. And I'm getting very frustrated.
My ultimate goal is to find out whether I can do testing without being charged.
This doc says I can - link
Once authorized with testing access, those users can side-load your app and test the full merchandising, purchase, and fulfillment flow for your products. 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.
and same link
During a test purchase, users can test the actual merchandising, purchase, and fulfillment flow in your app. During purchase, the inapp item is displayed as a normal item with an actual price. However, Google Play marks test purchases with a notice across the center of the purchase dialog, for easy identification
But then on this page, it say - link
Login to the test device by using a tester account. Test your In-app Billing application by purchasing a few items, and fix any issues that you encounter. Remember to refund the purchases if you don’t want your testers to be actually charged!
WTF... so does anyone know? Can do testing without being charged? And if so, how?

if you are using In App Billing version 3 then you can simply use product id="android.test.purchased". It is dummy product and you should not add it in your developer console. you can buy that product with out any charges.
android.test.purchased
When you make an In-app Billing request with this product ID, Google Play responds as though you successfully purchased an item. The response includes a JSON string, which contains fake purchase information (for example, a fake order ID). In some cases, the JSON string is signed and the response includes the signature so you can test your signature verification implementation using these responses.
Hope it will help you.

Yes: You can make test purchases, involving no payment being made, for real items (SKUs) you have actually defined yourself in the Console. I have just successfully done this myself.
Contrary to the advice given in the presently accepted answer, there is no need to use the dummy SKU android.test.purchased as you would with static testing.
The OP quotes this paragraph:
During a test purchase, users can test the actual merchandising, purchase, and fulfillment flow in your app. During purchase, the inapp item is displayed as a normal item with an actual price. However, Google Play marks test purchases with a notice across the center of the purchase dialog, for easy identification
This, so far, is correct and agrees with what I have been able to achieve.
But the subsequent paragraph the OP quotes:
Login to the test device by using a tester account. Test your In-app Billing application by purchasing a few items, and fix any issues that you encounter. Remember to refund the purchases if you don’t want your testers to be actually charged!
This, as far as I am concerned (particularly the last sentence) is not correct.
What you can do is as per the first paragraph. That is, as long as the test account is added to the Console as a tester, then when attempting to make a purchase, the dialogue (which shows you the price, etc.) should also have a special string across the centre of it (as mentioned in the first paragraph) stating "This is a test order, you will not be charged".
However, to actually make that work, it's also necessary for the actual APK the tester (or test device) is using to be one that is uploaded to the alpha channel.
So, the steps I had taken were as follows:
Create a separate Google Group for the purpose of alpha channel testing.
Add your IAP test user gmail account to that group.
Upload an APK (exported and signed with release certificate) with in-app purchase code to the alpha channel.
Wait perhaps an hour or two for the alpha build to become active.
In the meantime, set up a separate test device with just the test gmail account set up on it.
Opt-in for alpha channel testing by navigating to the opt-in URL on the test device while logged in as the test user.
Sign into Play with that tester account and install the application from Play. At this point (or after an hour or two) the latest alpha you uploaded should be the one now installed.
Attempt to make a purchase. When the dialogue appears with the price, it should have an additional "This is a test order, you will not be charged" string across it.
In fact, to be completely accurate, the test device does not necessarily seem to need to have had the alpha APK installed from Play. From my tests, what is important is that you do have an APK uploaded as alpha, and that the APK you're running on the test device has the same version number. Furthermore, test user needs to be opted-in for alpha builds and added as a tester in the Console (as stated above). I just exported another tweaked version of my APK and loaded into my test device using adb install, and I can still attempt purchases for real SKUs with the "...you will not be charged" message.

You have to Consume Once purchased.
consume.setOnClickListener(new View.OnClickListener() {
#Override
public void onClick(View view) {
Thread t = new Thread(new Runnable() {
#Override
public void run() {
String purchaseToken = "inapp:" + getPackageName() + ":android.test.purchased";
try {
Log.d("","Running");
int response = mService.consumePurchase(3, getPackageName(), purchaseToken);
if(response==0)
{
Log.d("Consumed","Consumed");
}else {
Log.d("","No"+response);
}
}catch (RemoteException e)
{
Log.d("Errorr",""+e);
}
}
});
t.start();
}
});

Test Subscription Feature of In-app Billing

Is it possible to test subscription feature of In-app Billing? I tried using reserved product IDs for testing(android.test.purchased), But it gave error like 'item not found'.I am using In-app Billing Version 3.I could not find a conclusive answer from the web. Any help is appreciated.

As of February/March 2015, in-app subscriptions can also be tested on Android. Now, Google accounts with testing access (configured in the Settings Menu of the Developer Console) will receive the message
This is a test subscription. It will recur daily. You will not be charged when trying to buy in-app subscriptions.
This also means that all subscriptions seem to be "billed" daily. You will still receive a normal Google Play Order Receipt Email but it will be prefixed by the word Test:
Test: Your Google Play Order Receipt from Mar 12, 2015
Also, if you look inside this email, you will notice that the order number is a random string of letters, instead of a regular order number as described at http://developer.android.com/google/play/billing/billing_subscriptions.html#payment.
Order number: lhjelkffelbnmmcmklbkhkbd

Some points that may help.
If your published application does not have in-app, you dont need to publish your next inapp version to test it.
You need to upload the apk with in app feature to your developer console (dont hit publish), install the same app on your phone
Create in app products (unmanaged) and ensure that the code refers to these unmanaged product id's
Make the product cheap for testing purpose
Purchase your product from your application
From your merchant account refund yourself (you wont be charged if you refund before 24 hours, and you get a full refund. (i think, just confirm this, it keeps changing).
After you are happy, hit publish.
You can add email id's of friends as test accounts, to help them purchase the product and not get charged. Infact you can also mock them for "failure" :)
I hope this helps.

This is the answer from my personal experience.
There's not a proper way to test inapp with a dev sandbox.
This is how I really test inapp.
Create a test application to test inapp and configure it.
Remember to put your developer public key where needed and all manifest permission needed
Add some inapp purchase to test with
Make the app NOT debuggable
Upload it on android market as draft
Now you have to wait some hours because Android Market need to push all changes or you will get an error when you try to make purchases
Now launch the app locally on your device (you have to put debuggable false) and test your inapp purchase buying something.
After all tests I go into my google wallet merchant account and I also make all other purchase flow test for:
Refund
Cancel Inapp-Subscription
If you find a better way to test it with a real sandbox please tell me :)

Use android.test.purchased as a product ID.

Create a class to mock out the apis you are using from Google Play services.

Can I turn my own Google Play account into a test account without any problems?

I'm developing our first app that uses in app purchases, and need to test that it's working correctly.
Currently if I try to make a purchase on the "android.test.purchased" item, I get an error message back saying "invalidClient". I'm led to believe that this is because my account is not a test user.
I found this page:
http://developer.android.com/google/play/billing/billing_admin.html#billing-testing-setup
which tells me how to set up a test user. I could set up a new user account, but I only have the one Android device to hand, which means doing a factory reset to make this the primary account, and I'd rather avoid that if possible.
Alternatively, can I make my own personal account double up as a test user?
The link above says that test users have limitations, one of which is:
Test accounts can only be used to purchase items that are listed (and
published) in an application's product list.
That seems to imply that I could only use my account to buy things in my in-development apps, and not from other apps as normal.
So can I turn my own personal account into a test user, without any problems when using the account to purchase other apps as normal?

It won't affect your abilities to use the test account as a normal account for other apps on Google Play.
So simply you can use your own account as a test account. (Actually if your account is the publisher account, you don't need to add it as a test account.)
The limitations mentioned in the documentation is a comparison to the publisher account.

Unfortunately there's no way around it. If you just have one device you have to wipe the device and then first sign in with the email address that you want to use as a test account. Only then will you be able to test in-app billing. You can also download other items from the Google Play store. I've done this without any problems.

Android In-app billing version 2 subscription static response not working

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!!!

Get the Google ID used in an in-app billing purchase

It has come to my attention that a device may have multiple Google accounts logged into it simultaneously. I understand that pre-Honeycomb, there is a primary ID; from Honeycomb on you can simply plug in several. I currently have two IDs logged into my test tablet.
When purchasing from Google Play you can choose which account is used to make a purchase. I want to add in-app billing to an application I'm writing, and I want to make sure each Google ID gets its purchases on any device, which means I need to know which ID was used to make the purchase in the first place. This means I need to do one of the following:
Force Google Play to use one of the Google IDs chosen from within my app by the user;
Retrieve the ID that Google Play used to make the purchase.
The documentation seems to have been written with the assumption that only one purchaser would ever be active on one device. Is it possible to do this?

This seems to be an issue with the Google PlayStore application. The same has been reported at
https://code.google.com/p/marketbilling/issues/detail?id=76

I guess the app will be tied to the google account you used to download the application.You might have to use the same google id to make the purchase. Otherwise, restore of purchases could be an issue.