Using external payments processor on Android for S

问题:

I’ve built a SaaS website with subscriptions, enabled by an external payments processor (which could be Stripe, Braintree, Paddle, etc.).

Now this website for my SaaS has been packaged in a small WebView wrapper and is about to be released as an Android app. But on the Stripe website, I found this:

Google’s developer terms require that purchases related to the app, such as premium features or credits, are made via their native In-app Billing API.

– https://stripe.com/docs/mobile/android

Diving deeper into Google Play’s terms, you can find this (emphasis mine):

• Developers offering products within a game downloaded on Google Play or providing access to game content must use Google Play In-app Billing as the method of payment.
• Developers offering products within another category of app downloaded on Google Play must use Google Play In-app Billing as the method of payment, except for the following cases:
  • Payment is solely for physical products
  • 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)

– https://play.google.com/intl/en/about/monetization-ads/

So that seems more permissive than Stripe’s interpretation, and since my SaaS is not a game and can be used via a generic web browser as well, my understanding would be that using an external payments processor instead of Google Play’s billing is fine.

On the one hand, this would mean that most digital services could avoid Google Play’s billing and use something else, which seems (too) fair on Google’s part. On the other hand, this excludes games, which Google can generate a lot of revenue from, so it may be reasonable again.

This is not a legal question, and the answer could not be found in legal literature or by asking a lawyer, anyway. Instead, it’s entirely up to Google’s discretion whether using an external payments processor is allowed or not, based on one’s interpretation of the terms presented above.

So instead of legal advice, I’m looking for practical guidelines and examples of real-world usage that supports any interpretation of the terms above.

One example that I’ve found is Dropbox: Having downloaded their app on Android, Dropbox allows me to select between two payment methods: Google Play, or debit card on Dropbox’s own site. This seems to support the more permissive interpretation of Google Play’s terms.

Another example is Spotify, which opens a WebView where you can choose from several payment options, none of which is Google Play. The app still has Android’s permission for in-app purchases, though, which is also disclosed in the Play Store, so perhaps they’re using Google’s in-app billing in specific countries only.

Are there any other real-world examples?

回答1:

There are such apps. Various network providers for instance, one could argue that ability to use phone calls or internet is not a physical good. Specific example would be Skype, which allows buying skype credit from a webview within the app.

But I think a good example for you would be WPS Office android app, which suggests upgrading to premium with an in-app subscription or a credit card payment.

回答2:

For sure, all (real-money) poker application are real-world example. (pokerstars for example)

I had never seen a poker application which use Google Play Service for billing. (maybe for legal reason)

They are using an hosted web-page (in a webview or in an encapsulated builtin web-browser) to treat payment processing on their side, which allow end user to select a payment methods in a big list.

Note that in that case you have to treat by yourself the user balance (which implied to treat all the security on payment processing on your side)

回答3:

I think the mobile banking applications is simple example one of them. You can pay your bills, send money via mobile banking apps. But there is no need to use Google Play Service for billing. The all transactions will complete on the banking side. You can even send money directly to some betting sites. (If you want I'll share with some mobile banking apps for this features but you need to login, you have to be customer of the app owner bank)

I just want to share it for an idea, I think you can build your own crypto currency with Ethereum infrastructure called smart contracts. Its really easy to deploy. You can find 10mins tutorials for this. You can use as a money in your mobile app. In this way If someone need to be buy something they have to be purchase some of your crypto currency. And the google side you will be exception because of this,

"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)"

But as you said,

it’s entirely up to Google’s discretion whether using an external payments processor is allowed or not, based on one’s interpretation of the terms presented above.

I'll signing under this.

You can also examine crypto stock market applications. I can bet they did not charge Google Play commission

Some of the information is not exactly what you want, but it's just for sharing ideas.

回答4:

I think Quickbooks by Intuit (accounting software) is an example of a SaaS solution which, I believe, does not go through Google:

https://play.google.com/store/apps/details?id=com.intuit.quickbooks

Another example is Invoice2Go

https://play.google.com/store/apps/details?id=com.invoice2go.invoice2goplus

These solutions are available through different devices (iOS and Android) and thorough web. It doesn't make sense for Google to take a cut since the Android app is just one of many different user connection options, just like Google's songs/music example.