Need clarification and specification on how to implement my billing model in iOS for my business.

I need clarification and specification on how to implement my billing model in iOS for my business.

My webservice offers Personalized-Reports to users accessible from:

  • Web
  • iOS app.
  • Android app.

The users can buy packs of 10 reports:

  • from web with credit card
  • from iOS with credit card (apple pay, stripe.com)? IAP? both?
  • from android with credit card (stripe.com).

and then get each report on web, ios app or android app interchangeably.

About iOS billing model specifically, confusion comes from:


https://developer.apple.com/app-store/review/guidelines


points 3.1.3 "Content-based ‘Reader’ Apps”

and 3.1.5 "Physical Goods and Services Outside of the App"

  1. Is It ok to implement Apple Pay, stripe, or any other Credit Card to buy the packs for 10 reports on iOS?
  2. Despite my personalized-reports will be accessible from all other platforms, must my iOS app only offer IAP in iOS and avoid all other payment options or can i implement both ?
  3. Is there ANY reliable source of information to clarify this? or the only way is to send the app for review and see what apple says?
  4. since my content is not streaming (but just graphical and sensitive data that expires), where does my personalized-reports get into: 3.1.3 or 3.1.5 terms of the licence?


Thanks in advance,

All help will be much appreciated!

If your report is a computer document then it is not 'physical goods and services' and 3.1.5 does not apply.

You may be able to operate under 3.1.3 as you referenced:

3.1.3 Content-based “Reader” Apps: Apps may allow a user to access previously purchased content or content subscriptions (specifically: magazines, newspapers, books, audio, music, video, access to professional databases, VoIP, cloud storage, and approved services such as educational apps that manage student grades and schedules), provided the app does not direct users to a purchasing mechanism other than IAP.


But if the iOS app is used to input information that will go into the report this 3.1.3 most likely does not apply and you must use IAP 3.1.1). The fact that it is accessible on the other platforms is relevant to a very small fraction of your users - and they are welcome to purchase it on their other platforms and operate in iOS under 3.1.3.

While I think it's all about 3.1.3 in your example (unless App Review dings you for not needing an app to do what a website already offers, etc.) you might want to note the following, just to help keep things/terms clear, etc.:


>Is It ok to implement Apple Pay, stripe, or any other Credit Card

IAP vs. Apple Pay...they are two different things.


Apple Pay is a payment scheme (hooks to credit cards, as an example) and the others are a transaction process.

Quoting from the Developer Agreement:

"Apple Pay APIs:

3.3.42 Your Application may use the Apple Pay APIs solely for the purpose of facilitating payment transactions that are made through Your Application, and only for the purchase of goods and services that are to be used outside of any iOS Product."


Apple Pay just hands off to a payment processor - IAP involves direct billing via iTunes, where Apple takes it’s usual 30% vs. external credit card billing where Apple doesn't take it's 70/30 cut.


>Is there ANY reliable source of information to clarify this?

Dev-facing in public - no. It's all a moving target and the guidelines, while seemingly complete, are nonetheless non-committal by design, allowing App Review to apply them case/by/case.


>or the only way is to send the app for review and see what apple says?

Typically, in your example and what you're asking, yes. There are no pre-reviews, only app review knows what will/won't be approved/rejected, app review isn't here. and no one here can offer little more than opinion and/or anecdotal advice.


Good luck and if you have the time, pls. let us know how you get on, thanks.


Ken

Need clarification and specification on how to implement my billing model in iOS for my business.
 
 
Q