Develop Reference

Third party billing api in my google play app

I am making an android app to serve my progressive webapp content using webviews. I want to host my android app on the Google Play store. My webapp uses Stripe as the billing api to accept payments, start free trials, and apply discounts. However, after reading the Google Play terms of service, I am confused by the section here.
My webapp offers subscription based content. In other words, users purchase my subscriptions in order to access restricted content. My content definitely meets the requirements in Google Play's terms of service. On billing though, I'd really prefer to use Stripe as that's what I've been using up until now. The terms of service states on in app purchases that I must use Google's billing api as the only payment method for selling subscriptions.
I am confused for two reasons. The first is on this section of Google Play's documentation, they suggest using multiple billing methods in an app as a good practice, but this contradicts their terms of service. So then am I allowed to use Stripe on my android after all? The second is that I'm looking at other android apps on Google Play, such as Spotify. Spotify does not seem to use Google Play's billing api for purchasing subscriptions. So I'm trying to understand what makes Spotify exempt from this requirement.
I had two theories for why Spotify is exempt. The first is because they offer their content through multiple mediums. Website, Windows and macOS applications, iOS app, etc. Does this fact exempt Spotify due to this statement: "Payment is for digital content that may be consumed outside of the app itself (e.g. songs that can be played on other music players)". If so then my app falls under this category as well since a subscriber would be able to access my content on my website and iOS app in addition to my android app correct? My second theory was because I read here that Spotify carries out the in app billing process through an external Spotify webview. If this is the case, then my app would be accepted by Google Play if I do the same and handle the billing by serving an external webview?
So my question is given everything I've touched on above, would my android wrapped progressive webapp be accepted by the Google Play store?
Thanks in advance.

Short answer: If you are planning to rely purely on Google Play or some other marketplace to grow your business / userbase then build your app to use their payment system. If people visit your website from the web, tell them to download it from whatever marketplace.
Long answer: If you do some exploring you will notice there is no option to manage payments from some mobile apps only login / signup (free account). If you want to upgrade you are either redirected to a browser OR forced to use their online web app (because you end up googl-ing out of frustration). BUT Google is saying as of September 2021 there will be 0 links allowed to non-Google payment services for any app that is not exempt (physical goods / services). So unless Netflix is using big money loopholes to qualify as one of the exempt businesses they would need to remove the link to "manage subscription" in their account settings sometime September 2021 - or implement Google's payment system for their APK submitted to Google play store.
My advice: Keep it simple!!! Unless you are working with a budget or team, managing all of this on your own, and in production will be overwhelming, especially if you end up scaling. If you want to make a Google Play game or app then build it with Google in mind. Use Google Oauth, Google Adsense (free accounts), and use Google's payment system to upgrade users. As you grow, hire people to help you expand and maintain your project on new marketplaces.

In-app purchases: Share user In-App purchases between Android and iOS

I'm planning to add In-App purchases to my Productivity app. Enhanced features are purchase products (e.g., freemium).
I would like to have user access to purchased feature on both Android and iOS, if he has purchased on any one platform. Technically I plan to store purchase information on server and have it retrieved whenever user logs-in on either device, and unlock the feature if already purchased.
Is this allowed in both iOS and Android?
Apple App Store Review Guidelines on Section 11 have this explained.
Points "11.1/11.2" and "11.14" sounds conflicting (or I'm missing something.).
On Android, I do not see this point mentioning in Policies.
If you had any experiences (w.r.t sharing purchase info between devices) that I should take care additionally, any suggestions are welcome.

I'd like to add a note about subscriptions. Here's the quote from Apple guide:
Cross-Platform Considerations
Product identifiers are associated with a single app. Apps that have both an iOS and macOS version have separate products with separate product identifiers on each platform. You could let users who have a subscription in an iOS app access the content from an macOS app (or vice versa), but implementing that functionality is your responsibility. You would need some system for identifying users and keeping track of what content they’ve subscribed to, similar to what you would implement for an app that uses non-renewable subscriptions
Link to Apple docs: https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Subscriptions.html
Quote from Android docs:
You can also build on your existing external subscriber base from inside your Android apps
If you sell subscriptions on a web site, for example, you can add your own business logic to your Android app to determine whether the user has already purchased a subscription elsewhere, then allow access to your content if so or offer a subscription purchase from Google Play if not.
You can implement your own solution for sharing subscriptions across as many different apps or products as you want ...
Link to Android docs:
https://developer.android.com/google/play/billing/billing_subscriptions.html
At the moment of writing this answer (May 23, 2017) Windows Store doesn't have subscriptions but they were announced during the latest BUILD conference. Some details here and here
Subscriptions should be available later this summer.

Answering myself. I submitted to App Store mentioning this case and got it approved. I'm yet to submit to Google Play so not sure about it.
Below the snippet I mentioned in App Store review notes that may help some
If user already purchased premium outside the app(our website or
Android app), then we are unlocking Premium as soon as user
logs-in to the app on iOS device. We do not include any button or link
or information inside this app regarding purchasing outside. If you
have any concern or comments regarding this, please let us know.
Additionally mentioned that our in-app item's service is based on user data at our server and not solely on iOS platform. I think this is the key point that makes sense to reuse user's purchase of our service. However, I do not find this case mentioned clearly in App Store review Guidelines.

[Update for April 2019]
As I've already answer here - from developer Apple guidelines:
3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired elsewhere, including consumable items in multi-platform games, provided those items are also available as in-app purchases within the app. You must not directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods must not discourage use of in-app purchase.
So like #siddharth-gupta explain in his answer:
Apple's rule basically states that if you have a digital product in your app (in your case, your subscription), the only way to pay for it should be via Apple's in-app purchases. If instead of using in-app purchases, you redirect the user to pay using any other method, your app risks getting rejected.
Note: this Apple statement for April 2019 -> and can always change. To avoid potential rejection/ban Always verify it with current official Apple Documentation

Syncing in-app purchase between platforms allowed?

Is it allowed to keep in sync auto-renewing subscription in Android and iOS via an online account?
That is to say : in Babbel, if I buy an auto-renewing subscription in Android (with the Android system of purchasing), it will be available on my iOS device.
In the same way, if I buy an auto-renewing subscription on iOS (via IAP), the courses will be available on Android too.
Everything is synced into my Babbel account.
Is it allowed (according to Apple guideline about IAP) so that I can reproduce this system in an app of mine? (The content sold being videos)
Thank you very much,
Jery

Yes. Both app stores have provisions to allow for this. (It's how Kindle, for instance, avoids being kicked out of the App Store even though you purchase content for it from Amazon directly).
There are drop-in libraries like Frac.as that handle the syncing part for you.

Android and Google Wallet - mandatory for one time purchase?

Is the Google Wallet online payment system on Android phones mandatory for e.g. movie, songs or game levels purchases in a similar way the Apple’s In-App-Purchase is on iOS?
According to the information here “Developers offering additional content, goods, or services for an application downloaded from Android Market must offer an authorized Payment Processor as the payment option“.
Our understanding is that if user has installed an application, which plays movies and users pay per single movie view application needs using the Google Wallet otherwise it can be removed from Google Play. Is that correct?
Similar situation is within game if user wants to pay for the additional level. Is that correct?
For subscriptions it is not required to use the Google Wallet (again the similar situation is on the iOS).
STeN

I had an app that had LogiaMobile billing integrated and was rejected from Google Play for that very reason (it was in Sept 2011). The app tried to bill users when they wanted to download videos.
Find a good explanation about the policies in this Techcrunch article
My advice would be to always integrate Google In-App billing (now v3 is far more confortable to work with).
I hope this is what you were asking for :)

'Google Wallet' is a confusing name, because it may refer to different thing. First there is the Google Wallet app that lets you pay with your phone via NFC. You certainly don't need this to buy things from the Play Store and it is supported only in the US, and only on a limited number of devices. Google Wallet also refers to Google's online payment system (aka Google Checkout). You need to register your credit card with that in order to make purchases on Android. It serves as the 'authorized Payment Processor' in most case. Other ones being carrier billing on supported carriers.

Payment gateways on iPhone & Android?

I'm looking for some advice on an app that I am hiring a developer to work on for me - its my first app and his first solo app, so I at least am still getting a feel for the ropes a bit.
My question lies in the area of in-app purchases. My app will use an in-app purchase system that will be used to purchase "credits" for lack of a better word. Each time a credit is purchased it will enable data stored in the app to be emailed to a particular email address.
I had originally thought it would be good to have an external web-based shopping cart to deal with it, but I understand there are APIs available to embed these shopping cart systems into the app. Additionally I also understand that any "digital consumables" that unlock features of the app are subject to the commission that iTunes/Android charge, does anyone have any initial thoughts on whether the ability to email would be included in this?
Many thanks in advance.

Savvas, that's not true at all ... AFAIK , in Android there's some exceptions you can read here: http://play.google.com/intl/en/about/developer-content-policy.html
Paid and Free Applications
App purchases: Developers charging for applications and downloads from Google Play must do so by using Google Play's payment system.
In-app purchases: Developers offering additional content, services or functionality within an application downloaded from Google Play must use Google Play's payment system as the method of payment, except:
where payment is primarily for physical goods or services (e.g. buying movie tickets; e.g. buying a publication where the price also includes a hard copy subscription);
or where payment is for digital content or goods that may be consumed outside of the application itself (e.g. buying songs that can be played on other music players)
So for example, for buying a coffee, you can use your own payment gateway.

I am pretty sure that both iPhone and Android agreements require you to use their own payment services for all in app purchases.
That means you can't roll your own paypal/visa/any other payment system and have your users use that if you plan on distributing the app via the Google Play Store or the App Store.
That being said, you can still roll out your own payment system if you distribute your app via other channels (for android you can have a look at the Amazon app store and other solutions. For the iPhone there is no official third party app store since Apple prohibits it. Cydia is an alternative app store that many people have though in their jailbroken phones)

Personally I am a big fan of Urban Airship. Works great on iOS and Android.