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

Question

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?

Answer 1

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.

Answer 2

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:

1. Create a separate Google Group for the purpose of alpha channel testing.

2. Add your IAP test user gmail account to that group.

3. Upload an APK (exported and signed with release certificate) with in-app purchase code to the alpha channel.

4. Wait perhaps an hour or two for the alpha build to become active.

5. In the meantime, set up a separate test device with just the test gmail account set up on it.

6. Opt-in for alpha channel testing by navigating to the opt-in URL on the test device while logged in as the test user.

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

8. 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.

Answer 3

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();
        }
    });