We've completed the implementation for Google Play Subscriptions v3 in our app and we are now testing with Alpha Builds on Play Store. Everything works perfectly, apart from the orderId, which is not returned as part of the Google Play API JSON response on the device. The token is returned as expected though. Is this happening because we are testing using Alpha Testing, or is it another issue? If so, shouldn't the orderId still be sent by the Google Play API as the token already is?
So apparently this is the expected behaviour when doing pre-release testing of Subscriptions with testing account licences, the Google Play API won't send out orderIds because no actual real life purchase is being made, so Google Wallet doesn't create any order. Which translates into no orderId being received by the app.
The official response from a Google Play Developer Support representative on the matter:
Currently, test subscriptions will not appear in your Google Wallet
Merchant Center because they are not actually assigned valid order
IDs. I'm sorry for the confusion.
To manage test subscriptions, you will instead need to use the
Developer API to refund, defer, cancel, or revoke test subscriptions.
To take any of these actions, you will simply need the app's package
name, the subscription ID, and the purchase token.
and when asked what not actually assigned valid order IDs means,
As per your concern, since it's test purchase, there won't be any
order ID. The order ID will however only exists when you move to
production.
Related
There are two endpoints in Google Play Developer API providing information about the subscription purchased by the user (depending on the purchase token) - purchases.subscriptions and purchases.subscriptionsv2. What is the proper way (and does it even exist?) to link that information with the corresponding subscription from Google Play Console, including the concrete base plan and offer?
v1 request doesn't contain any subscription identifiers, v2 request contains lineItems[].productId, which refers to the whole subscription. But none contain any information about base plans or offers, which were used to make the current purchase.
The second and smaller part of the question is where are located purchase price currency and amount in the v2 endpoint, which were available in the v1 endpoint?
Looks like Google has fixed this problem in the last API update and now there are basePlanId and offerId fields in OfferDetails in purchases.subscriptionsv2 request.
I'm using Google Play IABv3 and want to be able to easily test what I do (not surprisingly). Since IABv3 all items are managed and it's up to the application to consume the items that it considers consumables.
I'm not sure what the expected work flow is with testing non-consumable products. To be able to test the purchase flow more than once you need to be able to remove the previous purchase. However, the purchase is intended to be non-consumable so we obviously don't want to add any code that consumes it (since it could accidentally slip through and remove real users purchases).
I would like some way of clearing a test users account from purchases, which I doubt is possible since there is no "real" test users.
What is the suggested way to do this?
You can use test product IDs instead of real items. Remember to use it only in debug builds.
https://developer.android.com/google/play/billing/billing_testing.html
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.
android.test.canceled
When you make an In-app
Billing request with this product ID Google Play responds as though
the purchase was canceled. This can occur when an error is encountered
in the order process, such as an invalid credit card, or when you
cancel a user's order before it is charged.
android.test.refunded
When
you make an In-app Billing request with this product ID, Google Play
responds as though the purchase was refunded. Refunds cannot be
initiated through Google Play's in-app billing service. Refunds must
be initiated by you (the merchant). After you process a refund request
through your Google Wallet merchant account, a refund message is sent
to your application by Google Play. This occurs only when Google Play
gets notification from Google Wallet that a refund has been made. For
more information about refunds, see Handling IN_APP_NOTIFY messages
and In-app Billing Pricing.
android.test.item_unavailable
When you make an In-app Billing request with this product ID, Google Play
responds as though the item being purchased was not listed in your
application's product list.
When using in-app billing with Google Play you receive a PURCHASE_STATE_CHANGED broadcast intent containing information about the purchase. At that point you
Verify the purchase (possibly on your own server)
Record the purchase (almost certainly on your own server if its an unmanaged item)
Update your app to reflect the purchase
My question is:
When recording the purchase on your own server what user identity should be used to collate multiple purchases (and uses) of an unmanaged item? And how do you get this identity on Android?
NB the identity can't be device specific because a user may have more than one device. It needs to be linked to the Google Play account used for purchase. The data in the intents coming back from Google Play don't seem to contain any user identity (obfuscated or not).
I'm looking for where/how to find the Google play identity on Android and how to send that to an AppEngine stance.
I saw your discussion on Google Groups, from a few months ago when Google Play Services was not yet released.
You can now use Google Play Services as a standard way to do this. See AccountPicker.
I am trying to test the new subscriptions in Google Play but the service returns "Item not found".
I've used the identifier "android.test.purchased" to test.
With this identifier I can test perfectly the normal in-app product, but whith subscription it doesn't work.
In the Google Play Console I added a subscription, and it is published.
Do I have to use the real subscription identifier and pay for testing?
Thank you
Even I have been looking for this , and am guessing that you may have already solved your problem.But this might help others
Even I have been unable to find any documentation about test product-ids for subscription however Testing In-App billing suggests only use of 4 reserved static product ids. This makes me infer that there is no test-id for subscription.
Hope this helps
yes,you will have to use real subscription and pay (you can cancel later).
there's no test for subscription.
notice that you will have to send in your request
api version=2 and product type should be "subs".
Google Play has already implemented a sandbox to test subscriptions and issue purchases. You need to publish your app in beta and after a few hours of doing that the test users(added in Google Play dev console) can make test purchases(these are not charged) in your app. They can even make subscription test purchases. A test subscription automatically renews every day(until canceled from Google Play) irrespective of the subscription duration.
Although, please note that the test user(Google account) must have a valid credit card added to the Google Wallet account in order to make test purchases(which are not charged). While making the purchase, the purchase confirmation dialog clearly mentions that this is a test purchase and you will not be charged.
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.