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.
Related
The newly available Google Play Billing library does not support the SubscriptionManager of Unity IAP.
Usually, I would validate the receipt with the SubscriptionManager and check the is_subscribed, is_expired, etc attributes and act accordingly.
The documentation of Unity is not up to date with this new information. The Google Play Billing documentation offer no solution or insight as to how to validate that a subscription is still valid. "Not supported" is hardly a valid response, subscriptions are part of a lot of games and software made with Unity.
How can I validate that a Google Play subscription is valid and not expired in a Unity Project using the Unity IAP. Failing to be able to use Unity IAP, any other solution or insight is welcome.
It appears that this new plugin makes it mandatory to validate user subscriptions server-side. When implementing the plugin, I had to create a back-end service that provided the expiry date back to our app since we couldn't use SubscriptionManager to grab that information anymore.
I can't really recommend a specific way of doing this, because everyone's back-end will be different. For us, we utilize Docker containers on DigitalOcean droplets that our app and database can communicate with. This allows us to have a centralized location for back-end services, which we write in Python using Flask.
We have set up one that can go through our database, find every subscription that has expired based on the saved DateTime, and validate whether it has renewed or not. We added an extra endpoint to that service for grabbing the expiry date of a Google Play subscription, as mentioned above.
Subscription information can be obtained by accessing the Google Play REST API's purchases.subscriptions.get. This will return a SubscriptionPurchase object, which provides relevant information that you can then process to find out attributes such as is_subscribed, is_expired, etc.
It may be possible to send this directly from your Unity app/game, however this may also make man-in-the-middle attacks possible (admittedly my knowledge in this area isn't quite there, so I recommend you do your own reading on this).
Also as just a general suggestion, I recommend you try to post questions across both here and the UnityIAP sub-forum. The UnityIAP support folks are super active and even if they can't help because this is a Google implementation, it should definitely put it on their radar! I try to post there whenever I can as it allows them to make improvements to UnityIAP. (:
Yes at the moment we should use server-side API for getting Subscription related info. As SubscriptionManger was dependent on developer payload which is deprecated. See 2nd para https://developer.android.com/google/play/billing/developer-payload
I am now developing a social application. But recently I noticed that Firebase is blocked in China. So I want to make sure whether firebase can be used in China?
* EDIT 24 January 2020 *
Some of the information here might be out of date.
Firebase has a China service at https://firebase.google.cn/ which is not blocked in the PRC. (Thanks to #c-an for bringing this up.)
That said, *.google.com and *.googleapis.com are still blocked in China. I'll change/update this as I get more information.
Original Answer
For now Firebase is blocked and can't be used in China, along with other Google services, because the PRC has blocked all URIs with *.google.com and *.googleapis.com.
This also means, for example, that the Play app store can't be accessed from China. If you don't know what's going on between Google and the PRC, here's a primer.
Also, according to Chinese law, user data of Chinese citizens must be stored inside of the PRC. You might be able to get away with only addressing this once you have a significant number of users, but the trend has been for the CCP to crack down more and more on foreign information, even busting VPNs and declaring them illegal despite complaints of academics who say that they need, you know, real information.
As we're now in the run-up to the 19th Party Congress this autumn, we can expect the situation to get worse before it gets better. Maybe 2018 will leave room for relaxation?
For now, very sadly, forget anything Google in China, and be prepared to store user data of PRC citizens on servers located inside the Great Firewall. Also be prepared for seemingly random degradations of your service within China, or to be blocked altogether, along with these other blocked services.
Update 2017-11-23: The 19th Party Congress has come and gone and, if anything, Google services look less likely than ever to become available in China. The great firewall is likely to continue to be strengthened as the Chinese Communist Party extends its role into corporations, and foreign firms are generally disadvantaged.
Update 2018-08-05: Google plans to open a censored version of its search in China, according to leaked documents. It seems reasonable to assume that if a censored Google Search becomes available in the PRC, then Firebase and other Google Cloud products may as well. The censored search plan, code-named Dragonfly, has reportedly been in the works since December 2017, possibly a result of meetings that month between Google CEO Sundar Pichai and an unnamed top Chinese official when they met at the World Internet Conference in Wuzhen, China, where PRC General Secretary and President Xi Jinping gave a speech.
Update 2018-12-23: It appears that Google's Project Dragonfly is now on hold if not outright abandoned. This implies that the outlook for Firebase in China has worsened.
You can build your own Rest API server outside of China, and make the server talks to Firebase rest api endpoints of Realtime db or Authentication, https://firebase.google.com/docs/reference/rest/database. So you web app talks to your rest api server (accessible from China), and your rest api server talks to Firebase.
The answer is NO :
Using a huge part of Firebase services, I contacted the support, this is the answer :
I'm glad you are considering Firebase for your project. However, in
accordance with current U.S. policies, it is not possible to use
Firebase from within certain countries. For more information about
these restrictions, please refer to the U.S. Department of the
Treasury website. The current list is of blocked countries is listed
here. If you have end-users located within China, it's quite difficult
to access Firebase there since the use of Firebase requires Google
Play Services, which most of the devices in China don't have. We
understand that access to our products has been problematic from
within mainland China. We believe it may have been caused by
networking conditions in China, rather than Google's own services.
Since access to services is determined by the respective country's
government and they don't report to Google, the Transparency Report is
the most authoritative it can be.
I just tested and I am able to access my realtime database hosted on the Singapore region in China mainland. No need to modify anything. Whatever works overseas, works in China. Tested in Beijing.
Facing the same problem, if you are in china, install Astrill VPN and change from openweb to StealthVPN, connect to a server like USA for china one and login to firebase. It will work successfully.
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.
I'd like to use SSO (Single Sign-On) for users of my app, but I don't understand how to apply it to my case.
To summarize, we have:
a database
a website
an iPhone app / an Android App
Currently, it's possible to create an account on the site, and then use the same credentials to connect from the mobile apps. All communications between mobile apps and server work through http requests.
To put it simply, I would firstly
be able to use Google accounts to authenticate users
offering Android users to choose one of Google accounts associated with their smartphone
I found several sources of information:
Google - Using OAuth 2.0 for Login
Android - Remembering Users
Unlike what I saw in some examples, I don't need to make request to Google services like Google Calendar or Tasks, I just want to authenticate the user.
Does someone could tell me what I need to do on the website and on the mobile app. Should I store information in my database? How to ensure that after authentication, all http requests from the mobile application are really from authenticated user?
Do not hesitate to ask me to clarify some points.
Thanks in advance
As OAuth is a standard for authorization and not for authentication, it doesn't support any direct method for this. However, most providers allow you to call an endpoint that returns the id of the logged in user. Google returns the id as part of the basic profile information. This step is described in the first article you already mentioned. There are multiple libraries available to simplify this step for you.
So for identifying a user you acquire his Google user id and store/match it in your database.
To get the user's id on an Android device, there's an even more simple way. Just use Google Play Services as described in its documentation. You can find the user id in the response to the call in the last section of the documentation.
Now there's still the problem that you have to send the user id from the device to your web server and verify that this call was issued by your app. Fortunately, Google has also built a method into Google Play Services for exactly this scenario. There's a blog post by Tim Bray at the Android Developers Blog about this.
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.