This version of the application is not configured for billing through Google Play
When I try to run my application with in-app billing I am getting the error: "This version of the application is not configured for billing through Google Play. Check the help center for more information".
I have the billing permission already in the Manifest file and I have a signed .apk uploaded as a draft onto Google Play and I have also installed that same signed apk onto my phone.
Any help on how to solve this issue?
add a comment |
When I try to run my application with in-app billing I am getting the error: "This version of the application is not configured for billing through Google Play. Check the help center for more information".
I have the billing permission already in the Manifest file and I have a signed .apk uploaded as a draft onto Google Play and I have also installed that same signed apk onto my phone.
Any help on how to solve this issue?
add a comment |
When I try to run my application with in-app billing I am getting the error: "This version of the application is not configured for billing through Google Play. Check the help center for more information".
I have the billing permission already in the Manifest file and I have a signed .apk uploaded as a draft onto Google Play and I have also installed that same signed apk onto my phone.
Any help on how to solve this issue?
When I try to run my application with in-app billing I am getting the error: "This version of the application is not configured for billing through Google Play. Check the help center for more information".
I have the billing permission already in the Manifest file and I have a signed .apk uploaded as a draft onto Google Play and I have also installed that same signed apk onto my phone.
Any help on how to solve this issue?
asked Jun 17 '12 at 3:20
GatekeeperGatekeeper
3,76062237
3,76062237
add a comment |
add a comment |
18 Answers
18
active
oldest
votes
This error may be caused by several reasons.
Here is the list of requirements for the Google IAB testing.
Prerequisites:
- AndroidManifest must include "com.android.vending.BILLING" permission.
- APK is built in release mode.
- APK is signed with the release certificate(s).
- APK is uploaded to alpha/beta distribution channel (previously - as a draft) to the developer console at least once. (takes some time ~2h-24h).
- IAB products are published and their status set to active.
Test account(s) is added in developer console.
Testing requirements:
- Test APK has the same versionCode as the one uploaded to developer console.
- Test APK is signed with the same certificate(s) as the one uploaded to dev.console.
Test account (not developer) - is the main account on the device.
Test account is opted-in as a tester and it's linked to a valid payment method. (@Kyone)
P.S: Debugging with release certificate: https://stackoverflow.com/a/15754187/1321401 (Thnx @dipp for the link)
P.P.S: Wanted to make this list for a long time already.
Thnx @zlgdev, @Kyone for updates
1
that's a nice little round up of the many conditions needed for IAP. +1
– georgiecasey
Apr 18 '14 at 18:05
2
This should be the accepted answer for this question!
– SARose
Jan 26 '15 at 6:04
6
The best answer here, it's a shame that Google's own docs don't have such a round up. Working with Google Play Store has been frustrating due to poor and scattered documentation.
– enobayram
Apr 24 '15 at 7:20
10
How wonderful it would be if google could provide such nice and condensed lists instead of hiding the information in massive blocks of texts spread out over half a dozen pages.... Have a +1
– Olof Hedman
Nov 12 '15 at 13:53
5
Don't forget to make sure the account you're using to test IAB is opted-in as a tester using the "opt-in URL" generated once you've uploaded a build; AND that it's linked to a valid payment method.
– Kyone
Nov 17 '15 at 0:21
|
show 15 more comments
Ahh found the solution after trying for a couple of hours.
- Google takes a while to process applications and update them to their servers, for me it takes about half a day. So after saving the apk as a draft on Google Play, you must wait a few hours before the in-app products will respond normally and allow for regular purchases.
- Export and sign APK. Unsigned APK trying to make purchases will get error.
64
Wow, is this serious? Just ran into the same problem. Did everything Google asked me to do in order to test in-app billing, but still getting the same evasive error message. I guess I'll have to wait and see. But does Google really expect us developers to wait hours each time we need to update our app in order to implement in-app billing? It seems quite inappropriate to me, to say the least.
– Simon
Aug 6 '12 at 20:16
5
Can you test while connected to Android Studio / running while connected to the debugger? Or do you need to install the release apk via USB?
– Alfie Hanssen
Aug 1 '13 at 19:37
3
Is there an easier way to test the purchase process other than, Android Tools > Export signed project... etc, then manually copy APK across to device, Test, .... repeat? I must be missing something?
– wired00
Aug 28 '13 at 4:23
4
Seriously, I cannot use the application with debug certificate and test In-App Billing?
– TacB0sS
Sep 12 '13 at 5:28
8
Note that you CAN use debug builds, straight from your IDE as you are working. You just need to change the debug keystore to one that matches your release store. See this post for more information on how: stackoverflow.com/questions/10886814/…
– cottonBallPaws
May 14 '14 at 4:23
|
show 6 more comments
The same will happen if your published version is not the same as the version you're testing on your phone.
For example, uploaded version is android:versionCode="1", and the version you're testing on your phone is android:versionCode="2"
2
can u tell please me what if uploaded version isandroid:versionCode="1"and phone isandroid:versionCode="2"dose it ok or i have to change my apk google play ?.
– Youddh
Dec 17 '12 at 7:35
1
What you need to do is to bump down the local version to "1" so it matches the current live version, as least temporarily for testing.
– Gromix
Feb 12 '13 at 13:30
2
Looks like there are 2 common fixes to this error depending on your situation. In my case it was this one.
– Matt
May 20 '13 at 12:44
This one also fixed my problem.
– Justin Smith
Nov 5 '13 at 14:10
1
Agree depends on situation there are two fixes, This one solved my issue. thanks
– Yasitha Chinthaka
Feb 18 '14 at 16:21
|
show 3 more comments
You need to sign your APK with your live certificate. Then install that onto your test device. You can then test InAppBilling. If you are testing your application by direct run via eclipse to device(In debug mode) then you will get this error.
If you are using android.test.purchased as the SKU, it will work all the way, but you won't have the developerPayload in your final response.
If you are using your own draft in app item you can test all the way but you will be charged and so will have to refund it yourself afterwards.
You cannot buy items with the same gmail account that you use for the google play development console.
1
+1 Running from debugger uses debug certificate. After exporting the app and creating a new public key (and installing it in the developer console), just email yourself the apk and install it from your gmail inbox.
– cdavidyoung
Feb 19 '13 at 0:41
If I want to try "android.test.purchased" am I then going to change the SKU in both my code and in the developer console?
– Rocologo
May 10 '14 at 7:07
you're a ***** genius man! s2
– Victor R. Oliveira
Dec 31 '16 at 0:41
add a comment |
If you're here from 2018, you need to download the APK directly from Play Store and install the "derived" APK. Maybe it is because of Google's Play Store has a feature "App Signing by Google Play".
Thanks Law. You have saved my time. I made some changes in code I was so worried why my code was not working. pheww..
– Manish Gupta
May 18 '18 at 11:04
Glad to help out @ManishGupta
– Law Gimenez
May 29 '18 at 13:26
1
Which APK? I am using AIDL do i still need to do that?
– Zhen Liu
Aug 22 '18 at 3:10
@ZhenLiu I guess not needed
– Law Gimenez
Dec 11 '18 at 1:50
add a comment |
In the developer console:
Settings -> Account details -> License Testing -> Gmail accounts with testing access
and type here your accounts
add a comment |
Let me just add what happened with me, may help some one.
It was mainly due to signing.
Since I have added the signing details in the Project structure, I was thinking that every time when I run, expected signed apk is getting installed. But build type 'debug' was selected.
Below fix solved the problem for me.
- Generated signed apk of build type 'release'.
- Manually installed the apk.
add a comment |
This will happen if you use a different version of the apk than the one in the google play.
add a comment |
In my case I saw the same message due to the different signatures of the installed apk and an uploaded to the market apk.
add a comment |
If you want to debug IAB what do you have to do is:
Submit to google play a version of your app with the IAB permission on the manifest:
Add a product to your app on google play: Administering In-app Billing
Set a custom debug keystore signed: Configure Eclipse to use signed keystore
add a comment |
Contrary to many answers and comments on SO and other sites, you do NOT have to perform preliminary tests with an alpha/beta version of your product that has been downloaded from Google Play onto your test device (the alpha/beta publication process often eats up half a day). Neither do you have to load and re-load a signed release apk from your developer studio to your test device.
You CAN debug preliminary Google Play in app billing services using the debug app as loaded from your developer studio directly to your test device via ADB. If you are experiencing errors that prevent this, likely you have done something wrong in your code. Pay especially close attention to the CASE of your SKU's (product ids) and their format (for example, if you load your APK as com.mydomain.my_product_id, be sure your try to purchase it this way - providing the same case and domain). Also, pay especially close attention to your itemType - this should be either "inapp" or "subs" for managed/unmanaged in app purchases or subscriptions, respectively.
As suggested by Chirag Patel, provided you have your billing code properly established, perform all testing using the android.test.purchased Sku (product ID) during your preliminary tests. Check for this ID throughout your billing operations to pass it through signature, token and payload checks, since this data is not provided by the Google test system. Additionally, give one of your test products this ID to test its purchase, unlock/load and presentation all the way through your schema. To CLEAR the purchase, simply consume it, passing the same Sku AND a token string formatted this way - no other fields are relevant :
"inapp:"+appContext.getAppContext().getPackageName()+":android.test.purchased";
Once you have completed this phase of testing, move to semi-live testing with your alpha/beta product. Create a Google group (essentially a mailing list), add your test users emails to it, and add/invite this group to test your device in this phase (performed at the "APK" portion of your app's Google developer listing). Purchases will be simulated but not actually charged - however to clear and re-test the purchases, Google indicates that you must refund them from your Google wallet. THIS is the only phase of testing that requires the time-consuming process of using alpha/beta loads and test users.
add a comment |
Had the same problem, and it was not solved before i read the post from DZDomi. It suddenly occurred to be that there is a setting in the Google Developer Console that you need to enable. In the "In app purchases" section, there's a line for your product and to the far right there's a status for it. It should be ACTIVE!
add a comment |
my problem was that i tried to check it with the debug.keystore , i mean running it through eclipse.I exported it with the keystore with which i published in alpha mode(it must be published before you can test it).installed it in my phone and than i could test it normally.
add a comment |
The problem also occurs, when you have added an in-app purchase after you uploaded the apk, but you have not published the application in the play store (alpha, beta and production).
Which basically means, that you have to add the In-App purchase AFTER you have published the apk in the Play store (alpha, beta and production). Otherwise you wont be able to purchase or query for the In-App purchase.
add a comment |
Another reason not mentioned here is that you need to be testing on a real device.
With the emulator becoming really good, it's an easy mistake to make.
add a comment |
SOLUTION
Just hold on a while after uploading your app on play store because google takes some time to update app versions.It will work !
add a comment |
I have same problem in moto c2+ in my case it is device problem once i restart then it will rune perfect...
add a comment |
Recently google has implemented a change on their systems, and since you have uploaded at least one APK to your console, you can test your in-app requests with your app with any version code / number.
Cross reference LINK
Configure
gradleto sign your debug build for debugging.
android {
...
defaultConfig { ... }
signingConfigs {
release {
storeFile file("my-release-key.jks")
storePassword "password"
keyAlias "my-alias"
keyPassword "password"
}
}
buildTypes {
debug {
signingConfig signingConfigs.release
...
}
}
}
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f11068686%2fthis-version-of-the-application-is-not-configured-for-billing-through-google-pla%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
18 Answers
18
active
oldest
votes
18 Answers
18
active
oldest
votes
active
oldest
votes
active
oldest
votes
This error may be caused by several reasons.
Here is the list of requirements for the Google IAB testing.
Prerequisites:
- AndroidManifest must include "com.android.vending.BILLING" permission.
- APK is built in release mode.
- APK is signed with the release certificate(s).
- APK is uploaded to alpha/beta distribution channel (previously - as a draft) to the developer console at least once. (takes some time ~2h-24h).
- IAB products are published and their status set to active.
Test account(s) is added in developer console.
Testing requirements:
- Test APK has the same versionCode as the one uploaded to developer console.
- Test APK is signed with the same certificate(s) as the one uploaded to dev.console.
Test account (not developer) - is the main account on the device.
Test account is opted-in as a tester and it's linked to a valid payment method. (@Kyone)
P.S: Debugging with release certificate: https://stackoverflow.com/a/15754187/1321401 (Thnx @dipp for the link)
P.P.S: Wanted to make this list for a long time already.
Thnx @zlgdev, @Kyone for updates
1
that's a nice little round up of the many conditions needed for IAP. +1
– georgiecasey
Apr 18 '14 at 18:05
2
This should be the accepted answer for this question!
– SARose
Jan 26 '15 at 6:04
6
The best answer here, it's a shame that Google's own docs don't have such a round up. Working with Google Play Store has been frustrating due to poor and scattered documentation.
– enobayram
Apr 24 '15 at 7:20
10
How wonderful it would be if google could provide such nice and condensed lists instead of hiding the information in massive blocks of texts spread out over half a dozen pages.... Have a +1
– Olof Hedman
Nov 12 '15 at 13:53
5
Don't forget to make sure the account you're using to test IAB is opted-in as a tester using the "opt-in URL" generated once you've uploaded a build; AND that it's linked to a valid payment method.
– Kyone
Nov 17 '15 at 0:21
|
show 15 more comments
This error may be caused by several reasons.
Here is the list of requirements for the Google IAB testing.
Prerequisites:
- AndroidManifest must include "com.android.vending.BILLING" permission.
- APK is built in release mode.
- APK is signed with the release certificate(s).
- APK is uploaded to alpha/beta distribution channel (previously - as a draft) to the developer console at least once. (takes some time ~2h-24h).
- IAB products are published and their status set to active.
Test account(s) is added in developer console.
Testing requirements:
- Test APK has the same versionCode as the one uploaded to developer console.
- Test APK is signed with the same certificate(s) as the one uploaded to dev.console.
Test account (not developer) - is the main account on the device.
Test account is opted-in as a tester and it's linked to a valid payment method. (@Kyone)
P.S: Debugging with release certificate: https://stackoverflow.com/a/15754187/1321401 (Thnx @dipp for the link)
P.P.S: Wanted to make this list for a long time already.
Thnx @zlgdev, @Kyone for updates
1
that's a nice little round up of the many conditions needed for IAP. +1
– georgiecasey
Apr 18 '14 at 18:05
2
This should be the accepted answer for this question!
– SARose
Jan 26 '15 at 6:04
6
The best answer here, it's a shame that Google's own docs don't have such a round up. Working with Google Play Store has been frustrating due to poor and scattered documentation.
– enobayram
Apr 24 '15 at 7:20
10
How wonderful it would be if google could provide such nice and condensed lists instead of hiding the information in massive blocks of texts spread out over half a dozen pages.... Have a +1
– Olof Hedman
Nov 12 '15 at 13:53
5
Don't forget to make sure the account you're using to test IAB is opted-in as a tester using the "opt-in URL" generated once you've uploaded a build; AND that it's linked to a valid payment method.
– Kyone
Nov 17 '15 at 0:21
|
show 15 more comments
This error may be caused by several reasons.
Here is the list of requirements for the Google IAB testing.
Prerequisites:
- AndroidManifest must include "com.android.vending.BILLING" permission.
- APK is built in release mode.
- APK is signed with the release certificate(s).
- APK is uploaded to alpha/beta distribution channel (previously - as a draft) to the developer console at least once. (takes some time ~2h-24h).
- IAB products are published and their status set to active.
Test account(s) is added in developer console.
Testing requirements:
- Test APK has the same versionCode as the one uploaded to developer console.
- Test APK is signed with the same certificate(s) as the one uploaded to dev.console.
Test account (not developer) - is the main account on the device.
Test account is opted-in as a tester and it's linked to a valid payment method. (@Kyone)
P.S: Debugging with release certificate: https://stackoverflow.com/a/15754187/1321401 (Thnx @dipp for the link)
P.P.S: Wanted to make this list for a long time already.
Thnx @zlgdev, @Kyone for updates
This error may be caused by several reasons.
Here is the list of requirements for the Google IAB testing.
Prerequisites:
- AndroidManifest must include "com.android.vending.BILLING" permission.
- APK is built in release mode.
- APK is signed with the release certificate(s).
- APK is uploaded to alpha/beta distribution channel (previously - as a draft) to the developer console at least once. (takes some time ~2h-24h).
- IAB products are published and their status set to active.
Test account(s) is added in developer console.
Testing requirements:
- Test APK has the same versionCode as the one uploaded to developer console.
- Test APK is signed with the same certificate(s) as the one uploaded to dev.console.
Test account (not developer) - is the main account on the device.
Test account is opted-in as a tester and it's linked to a valid payment method. (@Kyone)
P.S: Debugging with release certificate: https://stackoverflow.com/a/15754187/1321401 (Thnx @dipp for the link)
P.P.S: Wanted to make this list for a long time already.
Thnx @zlgdev, @Kyone for updates
edited May 24 '17 at 7:53
answered Mar 18 '14 at 2:24
LutenLuten
4,09121720
4,09121720
1
that's a nice little round up of the many conditions needed for IAP. +1
– georgiecasey
Apr 18 '14 at 18:05
2
This should be the accepted answer for this question!
– SARose
Jan 26 '15 at 6:04
6
The best answer here, it's a shame that Google's own docs don't have such a round up. Working with Google Play Store has been frustrating due to poor and scattered documentation.
– enobayram
Apr 24 '15 at 7:20
10
How wonderful it would be if google could provide such nice and condensed lists instead of hiding the information in massive blocks of texts spread out over half a dozen pages.... Have a +1
– Olof Hedman
Nov 12 '15 at 13:53
5
Don't forget to make sure the account you're using to test IAB is opted-in as a tester using the "opt-in URL" generated once you've uploaded a build; AND that it's linked to a valid payment method.
– Kyone
Nov 17 '15 at 0:21
|
show 15 more comments
1
that's a nice little round up of the many conditions needed for IAP. +1
– georgiecasey
Apr 18 '14 at 18:05
2
This should be the accepted answer for this question!
– SARose
Jan 26 '15 at 6:04
6
The best answer here, it's a shame that Google's own docs don't have such a round up. Working with Google Play Store has been frustrating due to poor and scattered documentation.
– enobayram
Apr 24 '15 at 7:20
10
How wonderful it would be if google could provide such nice and condensed lists instead of hiding the information in massive blocks of texts spread out over half a dozen pages.... Have a +1
– Olof Hedman
Nov 12 '15 at 13:53
5
Don't forget to make sure the account you're using to test IAB is opted-in as a tester using the "opt-in URL" generated once you've uploaded a build; AND that it's linked to a valid payment method.
– Kyone
Nov 17 '15 at 0:21
1
1
that's a nice little round up of the many conditions needed for IAP. +1
– georgiecasey
Apr 18 '14 at 18:05
that's a nice little round up of the many conditions needed for IAP. +1
– georgiecasey
Apr 18 '14 at 18:05
2
2
This should be the accepted answer for this question!
– SARose
Jan 26 '15 at 6:04
This should be the accepted answer for this question!
– SARose
Jan 26 '15 at 6:04
6
6
The best answer here, it's a shame that Google's own docs don't have such a round up. Working with Google Play Store has been frustrating due to poor and scattered documentation.
– enobayram
Apr 24 '15 at 7:20
The best answer here, it's a shame that Google's own docs don't have such a round up. Working with Google Play Store has been frustrating due to poor and scattered documentation.
– enobayram
Apr 24 '15 at 7:20
10
10
How wonderful it would be if google could provide such nice and condensed lists instead of hiding the information in massive blocks of texts spread out over half a dozen pages.... Have a +1
– Olof Hedman
Nov 12 '15 at 13:53
How wonderful it would be if google could provide such nice and condensed lists instead of hiding the information in massive blocks of texts spread out over half a dozen pages.... Have a +1
– Olof Hedman
Nov 12 '15 at 13:53
5
5
Don't forget to make sure the account you're using to test IAB is opted-in as a tester using the "opt-in URL" generated once you've uploaded a build; AND that it's linked to a valid payment method.
– Kyone
Nov 17 '15 at 0:21
Don't forget to make sure the account you're using to test IAB is opted-in as a tester using the "opt-in URL" generated once you've uploaded a build; AND that it's linked to a valid payment method.
– Kyone
Nov 17 '15 at 0:21
|
show 15 more comments
Ahh found the solution after trying for a couple of hours.
- Google takes a while to process applications and update them to their servers, for me it takes about half a day. So after saving the apk as a draft on Google Play, you must wait a few hours before the in-app products will respond normally and allow for regular purchases.
- Export and sign APK. Unsigned APK trying to make purchases will get error.
64
Wow, is this serious? Just ran into the same problem. Did everything Google asked me to do in order to test in-app billing, but still getting the same evasive error message. I guess I'll have to wait and see. But does Google really expect us developers to wait hours each time we need to update our app in order to implement in-app billing? It seems quite inappropriate to me, to say the least.
– Simon
Aug 6 '12 at 20:16
5
Can you test while connected to Android Studio / running while connected to the debugger? Or do you need to install the release apk via USB?
– Alfie Hanssen
Aug 1 '13 at 19:37
3
Is there an easier way to test the purchase process other than, Android Tools > Export signed project... etc, then manually copy APK across to device, Test, .... repeat? I must be missing something?
– wired00
Aug 28 '13 at 4:23
4
Seriously, I cannot use the application with debug certificate and test In-App Billing?
– TacB0sS
Sep 12 '13 at 5:28
8
Note that you CAN use debug builds, straight from your IDE as you are working. You just need to change the debug keystore to one that matches your release store. See this post for more information on how: stackoverflow.com/questions/10886814/…
– cottonBallPaws
May 14 '14 at 4:23
|
show 6 more comments
Ahh found the solution after trying for a couple of hours.
- Google takes a while to process applications and update them to their servers, for me it takes about half a day. So after saving the apk as a draft on Google Play, you must wait a few hours before the in-app products will respond normally and allow for regular purchases.
- Export and sign APK. Unsigned APK trying to make purchases will get error.
64
Wow, is this serious? Just ran into the same problem. Did everything Google asked me to do in order to test in-app billing, but still getting the same evasive error message. I guess I'll have to wait and see. But does Google really expect us developers to wait hours each time we need to update our app in order to implement in-app billing? It seems quite inappropriate to me, to say the least.
– Simon
Aug 6 '12 at 20:16
5
Can you test while connected to Android Studio / running while connected to the debugger? Or do you need to install the release apk via USB?
– Alfie Hanssen
Aug 1 '13 at 19:37
3
Is there an easier way to test the purchase process other than, Android Tools > Export signed project... etc, then manually copy APK across to device, Test, .... repeat? I must be missing something?
– wired00
Aug 28 '13 at 4:23
4
Seriously, I cannot use the application with debug certificate and test In-App Billing?
– TacB0sS
Sep 12 '13 at 5:28
8
Note that you CAN use debug builds, straight from your IDE as you are working. You just need to change the debug keystore to one that matches your release store. See this post for more information on how: stackoverflow.com/questions/10886814/…
– cottonBallPaws
May 14 '14 at 4:23
|
show 6 more comments
Ahh found the solution after trying for a couple of hours.
- Google takes a while to process applications and update them to their servers, for me it takes about half a day. So after saving the apk as a draft on Google Play, you must wait a few hours before the in-app products will respond normally and allow for regular purchases.
- Export and sign APK. Unsigned APK trying to make purchases will get error.
Ahh found the solution after trying for a couple of hours.
- Google takes a while to process applications and update them to their servers, for me it takes about half a day. So after saving the apk as a draft on Google Play, you must wait a few hours before the in-app products will respond normally and allow for regular purchases.
- Export and sign APK. Unsigned APK trying to make purchases will get error.
edited Nov 13 '12 at 0:15
Community♦
11
11
answered Jun 18 '12 at 1:19
GatekeeperGatekeeper
3,76062237
3,76062237
64
Wow, is this serious? Just ran into the same problem. Did everything Google asked me to do in order to test in-app billing, but still getting the same evasive error message. I guess I'll have to wait and see. But does Google really expect us developers to wait hours each time we need to update our app in order to implement in-app billing? It seems quite inappropriate to me, to say the least.
– Simon
Aug 6 '12 at 20:16
5
Can you test while connected to Android Studio / running while connected to the debugger? Or do you need to install the release apk via USB?
– Alfie Hanssen
Aug 1 '13 at 19:37
3
Is there an easier way to test the purchase process other than, Android Tools > Export signed project... etc, then manually copy APK across to device, Test, .... repeat? I must be missing something?
– wired00
Aug 28 '13 at 4:23
4
Seriously, I cannot use the application with debug certificate and test In-App Billing?
– TacB0sS
Sep 12 '13 at 5:28
8
Note that you CAN use debug builds, straight from your IDE as you are working. You just need to change the debug keystore to one that matches your release store. See this post for more information on how: stackoverflow.com/questions/10886814/…
– cottonBallPaws
May 14 '14 at 4:23
|
show 6 more comments
64
Wow, is this serious? Just ran into the same problem. Did everything Google asked me to do in order to test in-app billing, but still getting the same evasive error message. I guess I'll have to wait and see. But does Google really expect us developers to wait hours each time we need to update our app in order to implement in-app billing? It seems quite inappropriate to me, to say the least.
– Simon
Aug 6 '12 at 20:16
5
Can you test while connected to Android Studio / running while connected to the debugger? Or do you need to install the release apk via USB?
– Alfie Hanssen
Aug 1 '13 at 19:37
3
Is there an easier way to test the purchase process other than, Android Tools > Export signed project... etc, then manually copy APK across to device, Test, .... repeat? I must be missing something?
– wired00
Aug 28 '13 at 4:23
4
Seriously, I cannot use the application with debug certificate and test In-App Billing?
– TacB0sS
Sep 12 '13 at 5:28
8
Note that you CAN use debug builds, straight from your IDE as you are working. You just need to change the debug keystore to one that matches your release store. See this post for more information on how: stackoverflow.com/questions/10886814/…
– cottonBallPaws
May 14 '14 at 4:23
64
64
Wow, is this serious? Just ran into the same problem. Did everything Google asked me to do in order to test in-app billing, but still getting the same evasive error message. I guess I'll have to wait and see. But does Google really expect us developers to wait hours each time we need to update our app in order to implement in-app billing? It seems quite inappropriate to me, to say the least.
– Simon
Aug 6 '12 at 20:16
Wow, is this serious? Just ran into the same problem. Did everything Google asked me to do in order to test in-app billing, but still getting the same evasive error message. I guess I'll have to wait and see. But does Google really expect us developers to wait hours each time we need to update our app in order to implement in-app billing? It seems quite inappropriate to me, to say the least.
– Simon
Aug 6 '12 at 20:16
5
5
Can you test while connected to Android Studio / running while connected to the debugger? Or do you need to install the release apk via USB?
– Alfie Hanssen
Aug 1 '13 at 19:37
Can you test while connected to Android Studio / running while connected to the debugger? Or do you need to install the release apk via USB?
– Alfie Hanssen
Aug 1 '13 at 19:37
3
3
Is there an easier way to test the purchase process other than, Android Tools > Export signed project... etc, then manually copy APK across to device, Test, .... repeat? I must be missing something?
– wired00
Aug 28 '13 at 4:23
Is there an easier way to test the purchase process other than, Android Tools > Export signed project... etc, then manually copy APK across to device, Test, .... repeat? I must be missing something?
– wired00
Aug 28 '13 at 4:23
4
4
Seriously, I cannot use the application with debug certificate and test In-App Billing?
– TacB0sS
Sep 12 '13 at 5:28
Seriously, I cannot use the application with debug certificate and test In-App Billing?
– TacB0sS
Sep 12 '13 at 5:28
8
8
Note that you CAN use debug builds, straight from your IDE as you are working. You just need to change the debug keystore to one that matches your release store. See this post for more information on how: stackoverflow.com/questions/10886814/…
– cottonBallPaws
May 14 '14 at 4:23
Note that you CAN use debug builds, straight from your IDE as you are working. You just need to change the debug keystore to one that matches your release store. See this post for more information on how: stackoverflow.com/questions/10886814/…
– cottonBallPaws
May 14 '14 at 4:23
|
show 6 more comments
The same will happen if your published version is not the same as the version you're testing on your phone.
For example, uploaded version is android:versionCode="1", and the version you're testing on your phone is android:versionCode="2"
2
can u tell please me what if uploaded version isandroid:versionCode="1"and phone isandroid:versionCode="2"dose it ok or i have to change my apk google play ?.
– Youddh
Dec 17 '12 at 7:35
1
What you need to do is to bump down the local version to "1" so it matches the current live version, as least temporarily for testing.
– Gromix
Feb 12 '13 at 13:30
2
Looks like there are 2 common fixes to this error depending on your situation. In my case it was this one.
– Matt
May 20 '13 at 12:44
This one also fixed my problem.
– Justin Smith
Nov 5 '13 at 14:10
1
Agree depends on situation there are two fixes, This one solved my issue. thanks
– Yasitha Chinthaka
Feb 18 '14 at 16:21
|
show 3 more comments
The same will happen if your published version is not the same as the version you're testing on your phone.
For example, uploaded version is android:versionCode="1", and the version you're testing on your phone is android:versionCode="2"
2
can u tell please me what if uploaded version isandroid:versionCode="1"and phone isandroid:versionCode="2"dose it ok or i have to change my apk google play ?.
– Youddh
Dec 17 '12 at 7:35
1
What you need to do is to bump down the local version to "1" so it matches the current live version, as least temporarily for testing.
– Gromix
Feb 12 '13 at 13:30
2
Looks like there are 2 common fixes to this error depending on your situation. In my case it was this one.
– Matt
May 20 '13 at 12:44
This one also fixed my problem.
– Justin Smith
Nov 5 '13 at 14:10
1
Agree depends on situation there are two fixes, This one solved my issue. thanks
– Yasitha Chinthaka
Feb 18 '14 at 16:21
|
show 3 more comments
The same will happen if your published version is not the same as the version you're testing on your phone.
For example, uploaded version is android:versionCode="1", and the version you're testing on your phone is android:versionCode="2"
The same will happen if your published version is not the same as the version you're testing on your phone.
For example, uploaded version is android:versionCode="1", and the version you're testing on your phone is android:versionCode="2"
answered Jul 9 '12 at 12:31
sandalonesandalone
23k54182295
23k54182295
2
can u tell please me what if uploaded version isandroid:versionCode="1"and phone isandroid:versionCode="2"dose it ok or i have to change my apk google play ?.
– Youddh
Dec 17 '12 at 7:35
1
What you need to do is to bump down the local version to "1" so it matches the current live version, as least temporarily for testing.
– Gromix
Feb 12 '13 at 13:30
2
Looks like there are 2 common fixes to this error depending on your situation. In my case it was this one.
– Matt
May 20 '13 at 12:44
This one also fixed my problem.
– Justin Smith
Nov 5 '13 at 14:10
1
Agree depends on situation there are two fixes, This one solved my issue. thanks
– Yasitha Chinthaka
Feb 18 '14 at 16:21
|
show 3 more comments
2
can u tell please me what if uploaded version isandroid:versionCode="1"and phone isandroid:versionCode="2"dose it ok or i have to change my apk google play ?.
– Youddh
Dec 17 '12 at 7:35
1
What you need to do is to bump down the local version to "1" so it matches the current live version, as least temporarily for testing.
– Gromix
Feb 12 '13 at 13:30
2
Looks like there are 2 common fixes to this error depending on your situation. In my case it was this one.
– Matt
May 20 '13 at 12:44
This one also fixed my problem.
– Justin Smith
Nov 5 '13 at 14:10
1
Agree depends on situation there are two fixes, This one solved my issue. thanks
– Yasitha Chinthaka
Feb 18 '14 at 16:21
2
2
can u tell please me what if uploaded version is
android:versionCode="1" and phone is android:versionCode="2" dose it ok or i have to change my apk google play ?.– Youddh
Dec 17 '12 at 7:35
can u tell please me what if uploaded version is
android:versionCode="1" and phone is android:versionCode="2" dose it ok or i have to change my apk google play ?.– Youddh
Dec 17 '12 at 7:35
1
1
What you need to do is to bump down the local version to "1" so it matches the current live version, as least temporarily for testing.
– Gromix
Feb 12 '13 at 13:30
What you need to do is to bump down the local version to "1" so it matches the current live version, as least temporarily for testing.
– Gromix
Feb 12 '13 at 13:30
2
2
Looks like there are 2 common fixes to this error depending on your situation. In my case it was this one.
– Matt
May 20 '13 at 12:44
Looks like there are 2 common fixes to this error depending on your situation. In my case it was this one.
– Matt
May 20 '13 at 12:44
This one also fixed my problem.
– Justin Smith
Nov 5 '13 at 14:10
This one also fixed my problem.
– Justin Smith
Nov 5 '13 at 14:10
1
1
Agree depends on situation there are two fixes, This one solved my issue. thanks
– Yasitha Chinthaka
Feb 18 '14 at 16:21
Agree depends on situation there are two fixes, This one solved my issue. thanks
– Yasitha Chinthaka
Feb 18 '14 at 16:21
|
show 3 more comments
You need to sign your APK with your live certificate. Then install that onto your test device. You can then test InAppBilling. If you are testing your application by direct run via eclipse to device(In debug mode) then you will get this error.
If you are using android.test.purchased as the SKU, it will work all the way, but you won't have the developerPayload in your final response.
If you are using your own draft in app item you can test all the way but you will be charged and so will have to refund it yourself afterwards.
You cannot buy items with the same gmail account that you use for the google play development console.
1
+1 Running from debugger uses debug certificate. After exporting the app and creating a new public key (and installing it in the developer console), just email yourself the apk and install it from your gmail inbox.
– cdavidyoung
Feb 19 '13 at 0:41
If I want to try "android.test.purchased" am I then going to change the SKU in both my code and in the developer console?
– Rocologo
May 10 '14 at 7:07
you're a ***** genius man! s2
– Victor R. Oliveira
Dec 31 '16 at 0:41
add a comment |
You need to sign your APK with your live certificate. Then install that onto your test device. You can then test InAppBilling. If you are testing your application by direct run via eclipse to device(In debug mode) then you will get this error.
If you are using android.test.purchased as the SKU, it will work all the way, but you won't have the developerPayload in your final response.
If you are using your own draft in app item you can test all the way but you will be charged and so will have to refund it yourself afterwards.
You cannot buy items with the same gmail account that you use for the google play development console.
1
+1 Running from debugger uses debug certificate. After exporting the app and creating a new public key (and installing it in the developer console), just email yourself the apk and install it from your gmail inbox.
– cdavidyoung
Feb 19 '13 at 0:41
If I want to try "android.test.purchased" am I then going to change the SKU in both my code and in the developer console?
– Rocologo
May 10 '14 at 7:07
you're a ***** genius man! s2
– Victor R. Oliveira
Dec 31 '16 at 0:41
add a comment |
You need to sign your APK with your live certificate. Then install that onto your test device. You can then test InAppBilling. If you are testing your application by direct run via eclipse to device(In debug mode) then you will get this error.
If you are using android.test.purchased as the SKU, it will work all the way, but you won't have the developerPayload in your final response.
If you are using your own draft in app item you can test all the way but you will be charged and so will have to refund it yourself afterwards.
You cannot buy items with the same gmail account that you use for the google play development console.
You need to sign your APK with your live certificate. Then install that onto your test device. You can then test InAppBilling. If you are testing your application by direct run via eclipse to device(In debug mode) then you will get this error.
If you are using android.test.purchased as the SKU, it will work all the way, but you won't have the developerPayload in your final response.
If you are using your own draft in app item you can test all the way but you will be charged and so will have to refund it yourself afterwards.
You cannot buy items with the same gmail account that you use for the google play development console.
edited Dec 7 '13 at 3:12
Evan Leis
479512
479512
answered Feb 6 '13 at 12:08
Chirag PatelChirag Patel
8,88632034
8,88632034
1
+1 Running from debugger uses debug certificate. After exporting the app and creating a new public key (and installing it in the developer console), just email yourself the apk and install it from your gmail inbox.
– cdavidyoung
Feb 19 '13 at 0:41
If I want to try "android.test.purchased" am I then going to change the SKU in both my code and in the developer console?
– Rocologo
May 10 '14 at 7:07
you're a ***** genius man! s2
– Victor R. Oliveira
Dec 31 '16 at 0:41
add a comment |
1
+1 Running from debugger uses debug certificate. After exporting the app and creating a new public key (and installing it in the developer console), just email yourself the apk and install it from your gmail inbox.
– cdavidyoung
Feb 19 '13 at 0:41
If I want to try "android.test.purchased" am I then going to change the SKU in both my code and in the developer console?
– Rocologo
May 10 '14 at 7:07
you're a ***** genius man! s2
– Victor R. Oliveira
Dec 31 '16 at 0:41
1
1
+1 Running from debugger uses debug certificate. After exporting the app and creating a new public key (and installing it in the developer console), just email yourself the apk and install it from your gmail inbox.
– cdavidyoung
Feb 19 '13 at 0:41
+1 Running from debugger uses debug certificate. After exporting the app and creating a new public key (and installing it in the developer console), just email yourself the apk and install it from your gmail inbox.
– cdavidyoung
Feb 19 '13 at 0:41
If I want to try "android.test.purchased" am I then going to change the SKU in both my code and in the developer console?
– Rocologo
May 10 '14 at 7:07
If I want to try "android.test.purchased" am I then going to change the SKU in both my code and in the developer console?
– Rocologo
May 10 '14 at 7:07
you're a ***** genius man! s2
– Victor R. Oliveira
Dec 31 '16 at 0:41
you're a ***** genius man! s2
– Victor R. Oliveira
Dec 31 '16 at 0:41
add a comment |
If you're here from 2018, you need to download the APK directly from Play Store and install the "derived" APK. Maybe it is because of Google's Play Store has a feature "App Signing by Google Play".
Thanks Law. You have saved my time. I made some changes in code I was so worried why my code was not working. pheww..
– Manish Gupta
May 18 '18 at 11:04
Glad to help out @ManishGupta
– Law Gimenez
May 29 '18 at 13:26
1
Which APK? I am using AIDL do i still need to do that?
– Zhen Liu
Aug 22 '18 at 3:10
@ZhenLiu I guess not needed
– Law Gimenez
Dec 11 '18 at 1:50
add a comment |
If you're here from 2018, you need to download the APK directly from Play Store and install the "derived" APK. Maybe it is because of Google's Play Store has a feature "App Signing by Google Play".
Thanks Law. You have saved my time. I made some changes in code I was so worried why my code was not working. pheww..
– Manish Gupta
May 18 '18 at 11:04
Glad to help out @ManishGupta
– Law Gimenez
May 29 '18 at 13:26
1
Which APK? I am using AIDL do i still need to do that?
– Zhen Liu
Aug 22 '18 at 3:10
@ZhenLiu I guess not needed
– Law Gimenez
Dec 11 '18 at 1:50
add a comment |
If you're here from 2018, you need to download the APK directly from Play Store and install the "derived" APK. Maybe it is because of Google's Play Store has a feature "App Signing by Google Play".
If you're here from 2018, you need to download the APK directly from Play Store and install the "derived" APK. Maybe it is because of Google's Play Store has a feature "App Signing by Google Play".
edited May 18 '18 at 12:37
answered May 11 '18 at 0:36
Law GimenezLaw Gimenez
1,56132437
1,56132437
Thanks Law. You have saved my time. I made some changes in code I was so worried why my code was not working. pheww..
– Manish Gupta
May 18 '18 at 11:04
Glad to help out @ManishGupta
– Law Gimenez
May 29 '18 at 13:26
1
Which APK? I am using AIDL do i still need to do that?
– Zhen Liu
Aug 22 '18 at 3:10
@ZhenLiu I guess not needed
– Law Gimenez
Dec 11 '18 at 1:50
add a comment |
Thanks Law. You have saved my time. I made some changes in code I was so worried why my code was not working. pheww..
– Manish Gupta
May 18 '18 at 11:04
Glad to help out @ManishGupta
– Law Gimenez
May 29 '18 at 13:26
1
Which APK? I am using AIDL do i still need to do that?
– Zhen Liu
Aug 22 '18 at 3:10
@ZhenLiu I guess not needed
– Law Gimenez
Dec 11 '18 at 1:50
Thanks Law. You have saved my time. I made some changes in code I was so worried why my code was not working. pheww..
– Manish Gupta
May 18 '18 at 11:04
Thanks Law. You have saved my time. I made some changes in code I was so worried why my code was not working. pheww..
– Manish Gupta
May 18 '18 at 11:04
Glad to help out @ManishGupta
– Law Gimenez
May 29 '18 at 13:26
Glad to help out @ManishGupta
– Law Gimenez
May 29 '18 at 13:26
1
1
Which APK? I am using AIDL do i still need to do that?
– Zhen Liu
Aug 22 '18 at 3:10
Which APK? I am using AIDL do i still need to do that?
– Zhen Liu
Aug 22 '18 at 3:10
@ZhenLiu I guess not needed
– Law Gimenez
Dec 11 '18 at 1:50
@ZhenLiu I guess not needed
– Law Gimenez
Dec 11 '18 at 1:50
add a comment |
In the developer console:
Settings -> Account details -> License Testing -> Gmail accounts with testing access
and type here your accounts
add a comment |
In the developer console:
Settings -> Account details -> License Testing -> Gmail accounts with testing access
and type here your accounts
add a comment |
In the developer console:
Settings -> Account details -> License Testing -> Gmail accounts with testing access
and type here your accounts
In the developer console:
Settings -> Account details -> License Testing -> Gmail accounts with testing access
and type here your accounts
edited Jul 11 '18 at 12:59
answered Jul 11 '18 at 12:21
Pablo CegarraPablo Cegarra
3,15032744
3,15032744
add a comment |
add a comment |
Let me just add what happened with me, may help some one.
It was mainly due to signing.
Since I have added the signing details in the Project structure, I was thinking that every time when I run, expected signed apk is getting installed. But build type 'debug' was selected.
Below fix solved the problem for me.
- Generated signed apk of build type 'release'.
- Manually installed the apk.
add a comment |
Let me just add what happened with me, may help some one.
It was mainly due to signing.
Since I have added the signing details in the Project structure, I was thinking that every time when I run, expected signed apk is getting installed. But build type 'debug' was selected.
Below fix solved the problem for me.
- Generated signed apk of build type 'release'.
- Manually installed the apk.
add a comment |
Let me just add what happened with me, may help some one.
It was mainly due to signing.
Since I have added the signing details in the Project structure, I was thinking that every time when I run, expected signed apk is getting installed. But build type 'debug' was selected.
Below fix solved the problem for me.
- Generated signed apk of build type 'release'.
- Manually installed the apk.
Let me just add what happened with me, may help some one.
It was mainly due to signing.
Since I have added the signing details in the Project structure, I was thinking that every time when I run, expected signed apk is getting installed. But build type 'debug' was selected.
Below fix solved the problem for me.
- Generated signed apk of build type 'release'.
- Manually installed the apk.
answered Jan 2 '16 at 15:48
Shree Harsha SShree Harsha S
415512
415512
add a comment |
add a comment |
This will happen if you use a different version of the apk than the one in the google play.
add a comment |
This will happen if you use a different version of the apk than the one in the google play.
add a comment |
This will happen if you use a different version of the apk than the one in the google play.
This will happen if you use a different version of the apk than the one in the google play.
answered Nov 25 '13 at 7:49
AmalkaAmalka
711
711
add a comment |
add a comment |
In my case I saw the same message due to the different signatures of the installed apk and an uploaded to the market apk.
add a comment |
In my case I saw the same message due to the different signatures of the installed apk and an uploaded to the market apk.
add a comment |
In my case I saw the same message due to the different signatures of the installed apk and an uploaded to the market apk.
In my case I saw the same message due to the different signatures of the installed apk and an uploaded to the market apk.
answered Nov 6 '13 at 22:37
goRGongoRGon
3,2713240
3,2713240
add a comment |
add a comment |
If you want to debug IAB what do you have to do is:
Submit to google play a version of your app with the IAB permission on the manifest:
Add a product to your app on google play: Administering In-app Billing
Set a custom debug keystore signed: Configure Eclipse to use signed keystore
add a comment |
If you want to debug IAB what do you have to do is:
Submit to google play a version of your app with the IAB permission on the manifest:
Add a product to your app on google play: Administering In-app Billing
Set a custom debug keystore signed: Configure Eclipse to use signed keystore
add a comment |
If you want to debug IAB what do you have to do is:
Submit to google play a version of your app with the IAB permission on the manifest:
Add a product to your app on google play: Administering In-app Billing
Set a custom debug keystore signed: Configure Eclipse to use signed keystore
If you want to debug IAB what do you have to do is:
Submit to google play a version of your app with the IAB permission on the manifest:
Add a product to your app on google play: Administering In-app Billing
Set a custom debug keystore signed: Configure Eclipse to use signed keystore
edited May 23 '17 at 12:02
Community♦
11
11
answered Dec 31 '14 at 12:21
PabloPablo
1,1151117
1,1151117
add a comment |
add a comment |
Contrary to many answers and comments on SO and other sites, you do NOT have to perform preliminary tests with an alpha/beta version of your product that has been downloaded from Google Play onto your test device (the alpha/beta publication process often eats up half a day). Neither do you have to load and re-load a signed release apk from your developer studio to your test device.
You CAN debug preliminary Google Play in app billing services using the debug app as loaded from your developer studio directly to your test device via ADB. If you are experiencing errors that prevent this, likely you have done something wrong in your code. Pay especially close attention to the CASE of your SKU's (product ids) and their format (for example, if you load your APK as com.mydomain.my_product_id, be sure your try to purchase it this way - providing the same case and domain). Also, pay especially close attention to your itemType - this should be either "inapp" or "subs" for managed/unmanaged in app purchases or subscriptions, respectively.
As suggested by Chirag Patel, provided you have your billing code properly established, perform all testing using the android.test.purchased Sku (product ID) during your preliminary tests. Check for this ID throughout your billing operations to pass it through signature, token and payload checks, since this data is not provided by the Google test system. Additionally, give one of your test products this ID to test its purchase, unlock/load and presentation all the way through your schema. To CLEAR the purchase, simply consume it, passing the same Sku AND a token string formatted this way - no other fields are relevant :
"inapp:"+appContext.getAppContext().getPackageName()+":android.test.purchased";
Once you have completed this phase of testing, move to semi-live testing with your alpha/beta product. Create a Google group (essentially a mailing list), add your test users emails to it, and add/invite this group to test your device in this phase (performed at the "APK" portion of your app's Google developer listing). Purchases will be simulated but not actually charged - however to clear and re-test the purchases, Google indicates that you must refund them from your Google wallet. THIS is the only phase of testing that requires the time-consuming process of using alpha/beta loads and test users.
add a comment |
Contrary to many answers and comments on SO and other sites, you do NOT have to perform preliminary tests with an alpha/beta version of your product that has been downloaded from Google Play onto your test device (the alpha/beta publication process often eats up half a day). Neither do you have to load and re-load a signed release apk from your developer studio to your test device.
You CAN debug preliminary Google Play in app billing services using the debug app as loaded from your developer studio directly to your test device via ADB. If you are experiencing errors that prevent this, likely you have done something wrong in your code. Pay especially close attention to the CASE of your SKU's (product ids) and their format (for example, if you load your APK as com.mydomain.my_product_id, be sure your try to purchase it this way - providing the same case and domain). Also, pay especially close attention to your itemType - this should be either "inapp" or "subs" for managed/unmanaged in app purchases or subscriptions, respectively.
As suggested by Chirag Patel, provided you have your billing code properly established, perform all testing using the android.test.purchased Sku (product ID) during your preliminary tests. Check for this ID throughout your billing operations to pass it through signature, token and payload checks, since this data is not provided by the Google test system. Additionally, give one of your test products this ID to test its purchase, unlock/load and presentation all the way through your schema. To CLEAR the purchase, simply consume it, passing the same Sku AND a token string formatted this way - no other fields are relevant :
"inapp:"+appContext.getAppContext().getPackageName()+":android.test.purchased";
Once you have completed this phase of testing, move to semi-live testing with your alpha/beta product. Create a Google group (essentially a mailing list), add your test users emails to it, and add/invite this group to test your device in this phase (performed at the "APK" portion of your app's Google developer listing). Purchases will be simulated but not actually charged - however to clear and re-test the purchases, Google indicates that you must refund them from your Google wallet. THIS is the only phase of testing that requires the time-consuming process of using alpha/beta loads and test users.
add a comment |
Contrary to many answers and comments on SO and other sites, you do NOT have to perform preliminary tests with an alpha/beta version of your product that has been downloaded from Google Play onto your test device (the alpha/beta publication process often eats up half a day). Neither do you have to load and re-load a signed release apk from your developer studio to your test device.
You CAN debug preliminary Google Play in app billing services using the debug app as loaded from your developer studio directly to your test device via ADB. If you are experiencing errors that prevent this, likely you have done something wrong in your code. Pay especially close attention to the CASE of your SKU's (product ids) and their format (for example, if you load your APK as com.mydomain.my_product_id, be sure your try to purchase it this way - providing the same case and domain). Also, pay especially close attention to your itemType - this should be either "inapp" or "subs" for managed/unmanaged in app purchases or subscriptions, respectively.
As suggested by Chirag Patel, provided you have your billing code properly established, perform all testing using the android.test.purchased Sku (product ID) during your preliminary tests. Check for this ID throughout your billing operations to pass it through signature, token and payload checks, since this data is not provided by the Google test system. Additionally, give one of your test products this ID to test its purchase, unlock/load and presentation all the way through your schema. To CLEAR the purchase, simply consume it, passing the same Sku AND a token string formatted this way - no other fields are relevant :
"inapp:"+appContext.getAppContext().getPackageName()+":android.test.purchased";
Once you have completed this phase of testing, move to semi-live testing with your alpha/beta product. Create a Google group (essentially a mailing list), add your test users emails to it, and add/invite this group to test your device in this phase (performed at the "APK" portion of your app's Google developer listing). Purchases will be simulated but not actually charged - however to clear and re-test the purchases, Google indicates that you must refund them from your Google wallet. THIS is the only phase of testing that requires the time-consuming process of using alpha/beta loads and test users.
Contrary to many answers and comments on SO and other sites, you do NOT have to perform preliminary tests with an alpha/beta version of your product that has been downloaded from Google Play onto your test device (the alpha/beta publication process often eats up half a day). Neither do you have to load and re-load a signed release apk from your developer studio to your test device.
You CAN debug preliminary Google Play in app billing services using the debug app as loaded from your developer studio directly to your test device via ADB. If you are experiencing errors that prevent this, likely you have done something wrong in your code. Pay especially close attention to the CASE of your SKU's (product ids) and their format (for example, if you load your APK as com.mydomain.my_product_id, be sure your try to purchase it this way - providing the same case and domain). Also, pay especially close attention to your itemType - this should be either "inapp" or "subs" for managed/unmanaged in app purchases or subscriptions, respectively.
As suggested by Chirag Patel, provided you have your billing code properly established, perform all testing using the android.test.purchased Sku (product ID) during your preliminary tests. Check for this ID throughout your billing operations to pass it through signature, token and payload checks, since this data is not provided by the Google test system. Additionally, give one of your test products this ID to test its purchase, unlock/load and presentation all the way through your schema. To CLEAR the purchase, simply consume it, passing the same Sku AND a token string formatted this way - no other fields are relevant :
"inapp:"+appContext.getAppContext().getPackageName()+":android.test.purchased";
Once you have completed this phase of testing, move to semi-live testing with your alpha/beta product. Create a Google group (essentially a mailing list), add your test users emails to it, and add/invite this group to test your device in this phase (performed at the "APK" portion of your app's Google developer listing). Purchases will be simulated but not actually charged - however to clear and re-test the purchases, Google indicates that you must refund them from your Google wallet. THIS is the only phase of testing that requires the time-consuming process of using alpha/beta loads and test users.
edited Aug 18 '16 at 13:44
answered Jul 23 '14 at 0:20
Epsilon3Epsilon3
551414
551414
add a comment |
add a comment |
Had the same problem, and it was not solved before i read the post from DZDomi. It suddenly occurred to be that there is a setting in the Google Developer Console that you need to enable. In the "In app purchases" section, there's a line for your product and to the far right there's a status for it. It should be ACTIVE!
add a comment |
Had the same problem, and it was not solved before i read the post from DZDomi. It suddenly occurred to be that there is a setting in the Google Developer Console that you need to enable. In the "In app purchases" section, there's a line for your product and to the far right there's a status for it. It should be ACTIVE!
add a comment |
Had the same problem, and it was not solved before i read the post from DZDomi. It suddenly occurred to be that there is a setting in the Google Developer Console that you need to enable. In the "In app purchases" section, there's a line for your product and to the far right there's a status for it. It should be ACTIVE!
Had the same problem, and it was not solved before i read the post from DZDomi. It suddenly occurred to be that there is a setting in the Google Developer Console that you need to enable. In the "In app purchases" section, there's a line for your product and to the far right there's a status for it. It should be ACTIVE!
answered Mar 31 '17 at 6:50
SørenSøren
111
111
add a comment |
add a comment |
my problem was that i tried to check it with the debug.keystore , i mean running it through eclipse.I exported it with the keystore with which i published in alpha mode(it must be published before you can test it).installed it in my phone and than i could test it normally.
add a comment |
my problem was that i tried to check it with the debug.keystore , i mean running it through eclipse.I exported it with the keystore with which i published in alpha mode(it must be published before you can test it).installed it in my phone and than i could test it normally.
add a comment |
my problem was that i tried to check it with the debug.keystore , i mean running it through eclipse.I exported it with the keystore with which i published in alpha mode(it must be published before you can test it).installed it in my phone and than i could test it normally.
my problem was that i tried to check it with the debug.keystore , i mean running it through eclipse.I exported it with the keystore with which i published in alpha mode(it must be published before you can test it).installed it in my phone and than i could test it normally.
answered Sep 28 '14 at 10:04
Gal RomGal Rom
3,62312324
3,62312324
add a comment |
add a comment |
The problem also occurs, when you have added an in-app purchase after you uploaded the apk, but you have not published the application in the play store (alpha, beta and production).
Which basically means, that you have to add the In-App purchase AFTER you have published the apk in the Play store (alpha, beta and production). Otherwise you wont be able to purchase or query for the In-App purchase.
add a comment |
The problem also occurs, when you have added an in-app purchase after you uploaded the apk, but you have not published the application in the play store (alpha, beta and production).
Which basically means, that you have to add the In-App purchase AFTER you have published the apk in the Play store (alpha, beta and production). Otherwise you wont be able to purchase or query for the In-App purchase.
add a comment |
The problem also occurs, when you have added an in-app purchase after you uploaded the apk, but you have not published the application in the play store (alpha, beta and production).
Which basically means, that you have to add the In-App purchase AFTER you have published the apk in the Play store (alpha, beta and production). Otherwise you wont be able to purchase or query for the In-App purchase.
The problem also occurs, when you have added an in-app purchase after you uploaded the apk, but you have not published the application in the play store (alpha, beta and production).
Which basically means, that you have to add the In-App purchase AFTER you have published the apk in the Play store (alpha, beta and production). Otherwise you wont be able to purchase or query for the In-App purchase.
answered Aug 22 '16 at 13:54
DZDomiDZDomi
1,4411211
1,4411211
add a comment |
add a comment |
Another reason not mentioned here is that you need to be testing on a real device.
With the emulator becoming really good, it's an easy mistake to make.
add a comment |
Another reason not mentioned here is that you need to be testing on a real device.
With the emulator becoming really good, it's an easy mistake to make.
add a comment |
Another reason not mentioned here is that you need to be testing on a real device.
With the emulator becoming really good, it's an easy mistake to make.
Another reason not mentioned here is that you need to be testing on a real device.
With the emulator becoming really good, it's an easy mistake to make.
answered Jan 22 '18 at 15:58
JDenaisJDenais
2,03511427
2,03511427
add a comment |
add a comment |
SOLUTION
Just hold on a while after uploading your app on play store because google takes some time to update app versions.It will work !
add a comment |
SOLUTION
Just hold on a while after uploading your app on play store because google takes some time to update app versions.It will work !
add a comment |
SOLUTION
Just hold on a while after uploading your app on play store because google takes some time to update app versions.It will work !
SOLUTION
Just hold on a while after uploading your app on play store because google takes some time to update app versions.It will work !
answered Jun 4 '18 at 9:46
Ali AkramAli Akram
7211618
7211618
add a comment |
add a comment |
I have same problem in moto c2+ in my case it is device problem once i restart then it will rune perfect...
add a comment |
I have same problem in moto c2+ in my case it is device problem once i restart then it will rune perfect...
add a comment |
I have same problem in moto c2+ in my case it is device problem once i restart then it will rune perfect...
I have same problem in moto c2+ in my case it is device problem once i restart then it will rune perfect...
answered Nov 26 '18 at 6:34
Sagar PithiyaSagar Pithiya
56114
56114
add a comment |
add a comment |
Recently google has implemented a change on their systems, and since you have uploaded at least one APK to your console, you can test your in-app requests with your app with any version code / number.
Cross reference LINK
Configure
gradleto sign your debug build for debugging.
android {
...
defaultConfig { ... }
signingConfigs {
release {
storeFile file("my-release-key.jks")
storePassword "password"
keyAlias "my-alias"
keyPassword "password"
}
}
buildTypes {
debug {
signingConfig signingConfigs.release
...
}
}
}
add a comment |
Recently google has implemented a change on their systems, and since you have uploaded at least one APK to your console, you can test your in-app requests with your app with any version code / number.
Cross reference LINK
Configure
gradleto sign your debug build for debugging.
android {
...
defaultConfig { ... }
signingConfigs {
release {
storeFile file("my-release-key.jks")
storePassword "password"
keyAlias "my-alias"
keyPassword "password"
}
}
buildTypes {
debug {
signingConfig signingConfigs.release
...
}
}
}
add a comment |
Recently google has implemented a change on their systems, and since you have uploaded at least one APK to your console, you can test your in-app requests with your app with any version code / number.
Cross reference LINK
Configure
gradleto sign your debug build for debugging.
android {
...
defaultConfig { ... }
signingConfigs {
release {
storeFile file("my-release-key.jks")
storePassword "password"
keyAlias "my-alias"
keyPassword "password"
}
}
buildTypes {
debug {
signingConfig signingConfigs.release
...
}
}
}
Recently google has implemented a change on their systems, and since you have uploaded at least one APK to your console, you can test your in-app requests with your app with any version code / number.
Cross reference LINK
Configure
gradleto sign your debug build for debugging.
android {
...
defaultConfig { ... }
signingConfigs {
release {
storeFile file("my-release-key.jks")
storePassword "password"
keyAlias "my-alias"
keyPassword "password"
}
}
buildTypes {
debug {
signingConfig signingConfigs.release
...
}
}
}
edited Mar 28 '18 at 7:08
answered Mar 28 '18 at 6:42
Anoop MAnoop M
4,94132350
4,94132350
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f11068686%2fthis-version-of-the-application-is-not-configured-for-billing-through-google-pla%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown