The retirement notice for Google Checkout at https://support.google.com/checkout/sell/answer/3080449?hl=en says:
If you are a user of [Google Play or Google Wallet for digital goods],
but use the Google Checkout
APIs for notifications or reporting, stay tuned. We will be announcing
replacement APIs shortly and recommend you stop using the Checkout
APIs as soon as possible.
I am a user of Google Play, and I'm using the Google Checkout API for reporting. The said announcement was published back in May; was there any replacement API announced so far, please?
The short answer is no. There is not yet a replacement for the Checkout reporting API. I assume by "shortly", they mean it'll be ready in six to eight weeks.
I have to assume they will have something ready before the November 20th kill-date.
The Purchase Status API looks promising.
For the list of sales, though, they recommend downloading sales reports. This does not sound promising at all - these are not realtime, like the old order list API was.
EDIT: Purchase status API sucks. It's not an order details retrieval the way Checkout API used to have - it's a basic "yes, an order took place" type of call. No amount, no customer data... Not a replacement for the Checkout API at all. I've filed a support ticket.
Related
I'm currently very much confused about with which subscription service to use between any Third-party or Google's In-App billing system.
Let me explain first , I have an app which is providing service to Landlord for Posting their vacant Properties where we are providing free trial 60 Days for full app features & after trial expires I would like to add Subscription Plans as below:
Silver: Less than 50 units (monthly or yearly)
Gold: Less than 51 - 100 units (monthly or yearly)
Platinum 100 and up units (monthly or yearly)
Now I'm exploring options to include to implement this subscription features & found that Stripe would be a good option for me but soon I find out about in-app purchases guidelines where they mentioned that In-app purchases must use Google Play’s payment system & also mentioned , examples of products not currently supported by Google Play In-app Billing:
So , basically there are two questions from my side :
Can I use other payment system or should I need to use Google's Play Billing system ?
For Google's Play system , How can I divide or how many subscriptions items will be there for above subscriptions plans?
Any help would be appreciated!
You can use both services Stripe and Google IAP(In App Purchases) or just 1 of them.
I suggest that you go with Google IAP since you do not have BE(BackEnd) and as I understand would be hard for you to maintain card numbers and everything.
Google IAP provides an SDK so that you can manage subscriptions on the Play Developers Console yourself. It also provides sandbox environment so that you can test it but also Stripe does that.
Here are some references:
https://developer.android.com/google/play/billing/billing_subscriptions
https://developer.android.com/google/play/billing/billing_overview.html
but I guess you have gone through them already. In the company that I previously worked on we were developing a project with pretty much the plans you described above and we used Google IAP and Apple IAP(for iOS/tvOS) without any problems. Furthermore we were able to query Google or Apple for previous subscriptions and let customers actually renew them instead of buying new ones.
As you mentioned the leasers/landlords will not be able to pay electronic bills with Google IAP but you can integrate Paypal/Stripe/BrainTree/WePay or any other alternatives for that.
Having mentioned that I would like to answer your questions now:
1) Yes you can use Stripe instead of Google IAP
2) You can divide subscriptions and you can manage them in your Google Developers Console at https://play.google.com/apps/publish/. However that can happen after you uploaded an .apk in console with in-app-billing dependencies and also permissions.
Hope it helps!!!
Your particular scenario is a bit of a grey area.
As a precedent the Autotrader app in the UK is using direct credit card billing in-app and this is a similar service to yours - i.e they are selling listings.
This seems correct to me because in app billing is designed to be used for digital content to be consumed in the app - not for real world services. Google may even reject your app for it.
In this case my advice would actually be to use Stripe or some other billing platform.
As for your billing model - it doesn't really fit the subscription model. I don't know specifically about Stripe but with Google you can't have a subscription AND a limit on items in the way you describe. So you would have to manage the listing limits yourself on your own backend.
There are some edge cases though - what happens if you use all of your 50 listings within the month? Do I have to buy another whole subscription?
The most suitable payment model I can see for you is Metered Billing from stripe - essentially pay as you go.
I recommended to use Google's In-App Billing. Because most of country payment support by google and user first trust on google that most benefit for you.
I received an email from Google Wallet on Friday saying:
Our records indicate you are a Play Apps developer who may be using Google Checkout APIs for notifications or reporting. On May 20, we announced that we will be replacing these APIs.
We provided replacement Play APIs, as of July 25, and anyone using the Checkout >notifications or reporting APIs needs to implement the Play APIs by August 22 to prevent >disruption to your scripts.
If you used the Checkout API for notifications, use the Play Purchase Status API. If you >used the Checkout API for reporting, you can automate the download of your estimated sales >and earning reports via the gsutil utility
I assume that the Google Checkout APIs I must be using are in relation to the In-app Billing Version 2 implementation that I have. It relies on the Billing Service to share interprocess communications with the Google Play Store app via local notifications. So I believe that I am supposed to look into the Play Purchase Status API. I looked into it, but I wonder if there are any tutorials or better documentation for the process of transitioning from the old In-app Billing Version 2 to use the new Google Play Developer API.
The Play Purchase Status API page states:
The API is designed to be used from your backend servers as a way of securely managing in-app products and subscriptions, as well as extending and integrating them with other services.
That really adds confusion for me since all of the purchase requests and tokens are handled by the Android app on the device. My back-end server just records the information that my app sends to it via web service call. Is my back-end server now expected to periodically poll the Google Wallet servers via Play Purchase Status API?
Google has now sent out emails that yes they ARE shutting down V2 of In-App Billing. I wrote a blog post discussing how to migrate (it's more like a re-write than a migration).
http://www.innodroid.com/blog/post/migrating-from-in-app-billing-v2-to-v3
Hopefully this helps others out. V3 is totally different (although much easier to understand and maintain, in my opinion).
This has nothing to do with in-app billing version 2, or what you are using in your app. This is about the Web services formerly offered by Google Checkout, which are being deprecated. Unless your app is accessing those Web services directly, you don't have to do anything at the app side. If you have your own Web application (for reporting,etc.) that pulls data from the Google Checkout API, you have to update it or stop using it.
Announcements section from Developer Console:
Beginning January 27, 2015, we will end support for the In-app Billing Version 2 API. In-app purchases made using the In-app Billing Version 2 API will be blocked.
To help ensure that users have time to update their apps, we recommend you migrate your applications to use the In-app Billing Version 3 API by November 2014.
It looks like we should still have until November.
For those of you looking for Server-To-Server API update instructions, the only noticeable difference is that you change the "v2" to "v3" in the endpoint path.
What was previously this:
https://www.googleapis.com/androidpublisher/v2/applications/packageName/purchases/products/productId/tokens/token
Is now this:
https://www.googleapis.com/androidpublisher/v3/applications/packageName/purchases/products/productId/tokens/token
They've also added a new field called "acknowledgementState", but this seems useless. If you were using it entirely to see if your purchase was consumed and valid, then the endpoint is essentially identical.
In my android app internaly useing some transactions in that purpose i want use *Subscriptions Google market billing *.
i googled found some sites for In-app billing and Subscriptions ,now want used Subscriptions based api but not found any code related this api.i found in-app billing code only.
please send Subscriptions based code
There is no one specific API. It is an extension of in-app billing with a new parameter and a couple of modifications in the APIs. For example, in the RequestPurchase call in BillingService.java, the item type now needs to be 'subs'. You really need to read the documentation:
http://developer.android.com/guide/google/play/billing/billing_subscriptions.html
as well as download the 'Google play billing Rev 2' from the 'Extras' from the SDK manager as that's a sample app that does subscriptions. The entire code base for it is too big to just give you but the sample app is a good start. I suspect with such a vague question, you're not going to get more details.
PREAMBLE: the question is wildly obsolete. There's no more Google Checkout, no more Checkout API, and no more notification settings in Wallet Console.
I have a paid app on Android Market. I've set up an HTTPS notification URL in Google Checkout settings. Yet notifications don't come.
My Google Checkout settings under Integration go like this:
My company will only post digitally signed carts - checked
API callback URL - provided, it's HTTPS and it's valid
Notification as XML - checked
API version - 2.5
Notification filtering - checked
Please, what am I doing wrong? Are realtime order notifications supported for Android Market at all? If so, is there a separate UI for setting those up?
EDIT: any data points would be welcome. If you sell stuff on the Market and do get those HTTP notifications, let's compare the setups.
EDIT2: seriously considering timed polling of my Google Checkout account. :(
EDIT3: contacted Google Checkout support. No substantial response for over a week. :(( On the brighter side, it is possible to retrieve the list of one's Google Checkout orders, with date and state filtering. On to retrieving order details...
The support rep told me it's by design, I should implement account polling with notification history API.
Specifically: https://developers.google.com/checkout/developer/Google_Checkout_XML_API_Order_Report_API describes how to get the list of orders in given state
https://developers.google.com/checkout/developer/Google_Checkout_XML_API_Notification_History_API lets you retrieve order details (getting just the "new order" notification is sufficient in my case).
EDIT: you cannot use some parts of the Google Checkout API with Android Market orders (like marking as archived).
This is not documented. Related question here.
I want to know if its possible/legal(not against terms of service) to use the google checkout api for an android app to support in app purchases. The types of items being purchased would be something like extra coins where they can be purchased multiple times.
I know that this would require getting the user's credentials or pointing them to the checkout page or something. I want to know if its possible to do this within the app by opening a webview to the checkout process, and then getting a callback to a custom url on my server that will allow the app to see that the purchase was successful. Something like what the android market does for app purchases.
Thanks for any responses. I don't currently have code to show as I am researching into this before devoting time to create something I won't be able to use. Also maybe android will support native in-app purchases in newer versions of the sdk.
Spoke to (Android evangelist) Reto Meier at Google Tech Days about this and he said it is perfectly OK to do inter-app purchases in the market. You should comply to other regulations - most common is that you need to only buy content that is consumed on the mobile. Virtual "coins" are on quite thin ice, some countries ban issuing "virtual money" but you can do essentially the same with just little different paradigm. Hope this helps.
Android market documentation explicitly states that you can do check it.
http://developer.android.com/guide/market/billing/billing_admin.html#billing-refunds
Important: You cannot use the Google Checkout API to issue refunds or
cancel in-app billing transactions. You must do this manually through
your Google Checkout merchant account. However, you can use the Google
Checkout API to retrieve order information.