I'm developing a simple in-app billing library. It works with static responses from google, but now I'd like to test this lib with real in-app products.
I have created a test account and I'm trying to buy a product, but google Play is asking me for a credit card. Is there any way to test in-app billing without using a real credit card (a sandbox environment, fake credit card, etc)?
I have read here that the only way to test this is using a real credit card with a test account (so you don't have to pay google taxes) and once you have bought the product, refund it again, but it seems not to be a very 'developer-friendly' way.
Thanks.
Nope it absolutely SUCKS
You have to use a real credit card, then go into Google Play , select View Merchant Account and hit the individual order then refund to get your money back.
sorry!
As of today (or yesterday) Google has finally allowed "sandbox" testing of in app purchases, it goes through all the steps of an in app purchase except the actual charging of the credit card.
Although you will probobly have to wait for the cancelations/refunds like you did before.
More info here and here
Got this info from my developers console.
... and to add to Blundell's answer, it will take close to 6 hrs for refund to be posted, and then you'll probably want to give it another 6 hours before attempting the purchase.... or else.... Or else, what? Oh, I don't know, something like the "you already own this item" bug/glitch/bane of my existence
You can test in-app purchase subscription using testing accounts. For reference please go through the link-
You may use sandbox testing by adding you testers account to play console.
Go to the play console main screen--> setting--> search for license testers--> add your testers email-id there.
Then go to your app release-> go for your beta/alpha release.
Tap on manage testers and share opt-in URL with testers to accept an invite.
https://cheesecakelabs.com/blog/google-play-iap-first-setup-test-sandbox/
Related
I am working on an Android 4+ app that is free and includes some In-App Purchase items. Some testers are participating in the current beta-test and once the final version is published I would like to let these testers use the IAP items for free.
Is there some "easy" or official way to do this?
This will be my first app in the Play Store (only worked for iOS so far) and I do not know if there is any possibility to create promo codes or something like this to let users purchase non-free IAP items for free.
The only solution I found so far would be some kind of back door within the app, e.g. "Go to page XY, click twice on image A to bring up the unlock screen, enter your username and key..."
Of course this would work but I do not like this solution. Beside the additional work to implement such a solution it would not be really save. I do not know most of my testers in person and if one decides to publish his unlock key on the internet I cannot prevent all kind users from unlocking the app for free (at least not in the current version).
So, is there any way within the Play Store API to get this working?
Short answer: No!
Detailed answer and a possible way to do this:
Right in the Developer Console --> Settings --> License Testing Panel. There you can add up to 400 eMail adresses. Anyone who's using one of those eMail adresses is able to make test-purchases, this means they won't be charged but the Google Server will respond with something like "Yeah he/she bought this item".
Limitation: It's meant test purchases, mainly for applications that aren't published.
From the docs:
You can use any Google account as a test account. Test accounts are
useful if you want to let multiple people test In-app Billing on
applications without giving them access to your publisher account's
sign-in credentials. If you want to own and control the test accounts,
you can create the accounts yourself and distribute the credentials to
your developers or testers.
Though it's still possible to make test-purchases in published application. But there's one major drawback: The purchase will be cancelled automatically after 14 days.
Quote from the docs:
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.
To sum it up: The In-App Billing API doesn't offer an official way to do something like this. If you wanna do this you have to implement your own solution.
See also this SO-Post "Coupons for In-App Billing" which discusses this topic as well.
I don't want to input my credit card for Google Play test. Is there any way I can do this like what we did in iOS IAP testing?
Or is it possible to create Redeem code for testing?
The reason is I'm not feeling comfortable to add my Credit Card number. One of my friends once was stolen about $600 through Google wallet (although Google paid him back later).
Another bad case is my another friend received the bill from his Credit Card company to pay for the testing of Google Play's In App Billing although Google said it's safe to do so.(He told me he even saw "This is a test order, you will not be charged" when he did testing)
Thanks
I think he was talking about the Google Play's In App Billing. So I don't think it's possible to use sandbox for testing.
Follow the documentation here. It will give you access to a group that will automatically input test cards into your current google account you're using within the sandbox https://developers.google.com/pay/api/android/guides/resources/test-card-suite
I have implemented subscriptions in my app and have the product listed on my developer Console. Test purchases are not currently supported for subscription in-app items so I need to test using a real credit card - no problem for me. Also I'm testing on a phone other than my developer phone because we are not allowed to test on our developer phone (can you make it any harder Google?) Previously I successfully tested consumable products using this phone using a bogus -0999 credit card and this worked well.
Now when I try to buy a subscription, Google Play wants to use the -0999 credit card and it fails to be approved. So I would like to change it to use a real credit card but I can't figure out how to do the. How can I test with a real credit card?
Thanks,
Dean
When you were testing your consumables, Google Play put that phoney credit card number into your Google Wallet Account. Going into Google Wallet, deleting the phoney CC and entering a valid CC solves the problem.
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.
I've followed the steps to upload the In-App Billing Sample App as an unpublished, draft app on the Market for testing purposes. I have my google account set up as a Test Account under my Market credentials and was wondering if my credit card will actually be charged when I purchase the potion or sword?
I know that I should refund the purchase from my Google Checkout Merchant account but will it actually charge my card if I don't?
Okay, after actually trying it, my card is really charged. Just an fyi for anybody that was wondering. The four android.test.xxx product IDs are the only test transactions that are possible that won't use your real account info and card.