Lessons on app - IAP only solution?

Hi there,

Thanks for your time by reading this.


We are currently designing an iOS app which primary feature is to offer 1to1 lessons online using audio conference from a third party provider (Plivo or Twilio).


Calls will occur within the app, but it's a real-world service, so, based on what I've read in the forum, I still have no idea if we need to use IAP or could integrate a third party processor.


In addition to that, this will work as a marketplace, where users will be able to pay calls as they go and coaches will get paid for that lesson. It's not a subscription model. It's always on demand.


Using IAP only will allow us to charge payments to users, but we won't be able to send money to coaches. It won't violate 3.1.3(b) guideline if we ask coaches to send us their Paypal account?.


In a nutshell:

- Online lessons within the app, will require only IAP even we offer a rea-world service?. We want to use PayPal.

- IAP supports pay-as-you-go model?. Meaning: "you talked 18 mins, this is your billing and will charge you $x for this call".

- IAP supports send money to users?. I guess not. This would be a Marketplace.


Apps like Verbling and Cambly are working with this model: offering service in-app but they were allowed to use third party payment processor.


I read a lot in the forums but didn't find any like this.


Thank to all of you, guys.

Replies

May you use IAP? The guidelines used to explicitly state that you cannot use IAP for real world services. Now they just say that you cannot use IAP for goods and services consumed outside the app. So it is unclear whether you may use IAP for those real-world servcies consumed within the app.


Must you use IAP? The guidleines require use of IAP if you will be unlocking functionality within the app. From your brief description, you seem not to be doing that - so you do not need to use IAP. Further, if you are displaying prerecorded lessons, i.e. digital content, you can operate as a Reader App (3.1.3a). But if you are unlocking functionality within your app then you need to 'sell' that component using IAP. So of you unlock a 'Super Viewer' and then the user can view X and Y but must pay additional to interact with or view Z then you sell the Super Viewer unlock through IAP and the access to Z through a third party payment suystem.

>...this will work as a marketplace, where users will be able to pay calls as they go and coaches will get paid for that lesson.


Have you already lined up coaches that understand that if you are using IAP, they get their money from you, not Apple, after Apple pays your revenue each month, one month delayed?


I don't believe you are mandated to use IAP, if that's what you're asking. In your example, I'd prefer any 3rd party payment method that allows you to keep splits to a minimum, etc.

Thanks PBK for your answer.

Definitely we are talking about a real-world service. Payments won't unlock any extra content, but will allow users within the app to connect each other using audio conference. I think we are in a gray area but we don't want to waste critical dev hours.


What would be your choice? IAP or third party?. Third party for us would be ideal.


Will take that in mind to apply as a reader or unlock credits based on your example.


Thanks so much for your time!.

I'd say you are in a light grey area. Use a third party payment system.


I'd have your app come with some functionality that makes it useful before anything is purchased. That way it is obvious that nothing is being unlocked by the payments. In your notes to App Rview say that payments are for real world, real time audio conferences but do not unlock any functionality within the app.


Good luck.