IAP or 3rd party?

Hi, hope anyone can answer this 1 (I'm really not that great at reading legal).


I'm developing an app/platform that connects busy people to students who can do chores like shopping for these busy people.

For each connection we charge a fee to the customer.

Customers can also get a subscription which basically means they don jont have to pay the fee every time.


So are we virtual or real-world? Do we need to us eApple or 3rd party software for purcheses??? Our app definitely enables people to purchase a sevice that is ' consumed ' outside the app

as stated in

3.1.5 Goods and Services Outside of the App: If your app enables people to purchase goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry.


Like I said...I do not speak legal....so keep it simple please 😉


Kind regards,


Floeby

Replies

You can't use in-app purchase to pay for the chores themselves. But if people are using your app to make those connections, then any payment making those connections would have to follow in-app purchase rules.

so if I understand correctly ...because we connect people to the ones who do the physical service we have to abide by the in-app purchase rules??


But how does this work with apps like Uber then? their employees don't drive taxis themselves...they mediate as well.

>how does this work with apps like Uber


An Uber ride is not a digital item... it is a real world service used/consumed outside the App. Apple is not the payment processor for Uber transactions. As they do with a normal IAP transaction, Apple does not keep 30% of the transaction between Uber and their client.

Two things to consider:

1) the services themselves - these are real world services. You may not use IAP. You may use a third party system like pay pal.

2) the connection of the app user to the best or closest or tallest or whatever person who can provide the services - if you want to charge for the app making that connection you must use IAP. And if you want you can fold #2 into #1 as a surcharge within the payment for #1 if the value of #1 (the service) is greater than the value of #2 (the connection).


Uber (et al) does not charge for #2 (connecting you to the nearest driver in a large black car to signal 'here I am'). They only charge for #1 (drive me to EWR).


The reply above is saying you must abide by IAP wrt #2.

Uber is actually a pretty good example. If you are setting up a system whereby your "students" are your employees (sorry, "independent contractors") and you pay them for the chores, then that is not an in-app purchase item. In this case, your app itself, like the Uber app, would be completely free. When someone makes a connection and contracts a chore, they would pay you and then you would pay the "student". So how much VC funding do you have for this plan? 🙂 There's your difference.


If you don't plan to be a financial intermediary between the busy people and the students, then you are going to either 1) make your app completely free, or 2) come up with some other kind of funding model. Charging for making those connections is a valid option, but since it takes place entirely digitally inside the app, that is an in-app purchase. You might be able to charge for membership by either the busy people and/or the students. Whether or not you can avoid in-app purchase for a "membership" model is a more difficult question. Apple has some additional rules that apply here.


What is so bad about in-app purchase anyway? I know people complain about the 30%, but I don't. I have an app that is sold both through the Mac App Store and independently. My app is unique so I have some valid reasons for doing this. But I can tell you that the 30% commission that Apple charges is well-worth the price. I can do it direct via other payment providers for 15-25%, but there are whole bunch of additional things to worry about and deal with. There is a huge class of business problems that just "go away" with in-app purchase.

A better approach is to divide up the 'process' into 1) 'connecting the partners' and 2) 'performing the services'. To connect, you have to subscribe or buy credits or join a club or something like that through IAP on the app. It's relatively inexpensive, a few bucks for a user for a years worth of 'connections'. Apple gets 30% because they are providing the app environment and the app developer gets 70%. Once you have found your service provider then you pay for services through pay pal or the equivalent - again through the app. Very expensive - $10 per hour for babysitting or tutoring; total of $100's of dollars in a given year for one user. The service provider gets 90% of that. The developer gets 10%.

Hi PBK,


could you please explain this bit:


And if you want you can fold #2 into #1 as a surcharge within the payment for #1 if the value of #1 (the service) is greater than the value of #2 (the connection).


Give an example or something?


Kind regards,


floeby

So if I understand correctly my pricing would be two tiers:

Connection making that we do via IAP

Services performed by student is via our own payment.


This for the customer is quite elaborate....in that case back to the drawing board 😉

Hi John,

Thing is, the 30% is quite a lot...we'd make more if we could do it ourselves.

So we'll definitely also will sell on our website as well....

We understand that we cannot advertise this in the app....but we will outside the app on social media and such.


Maybe you can answer tis one as well:


If we use IAP and sell on our website as well. Can we still have a link in the app to our website?

Not on the paying screen in the app of course, but for example a link in the FAQ section??


Kind regards,


floeby

Sorry, but you seem choosing that poorly-defined middle road. I mentioned this when I said "Apple has some additional rules that apply here." I can't help with that. You will have to do the research on your own. I can tell you that there are many, many questions here in the forum from people trying to figure out this particular option. Usually they are dealing with this after having spent a lot of time and effort developing a system only to have Apple reject the app immediately. You can study the guidelines all you want. You can hire lawers too. But ultimately, the decision is made by some anonymous app reviewer at 3 am that can put you out of business. Or maybe your app goes live and all is well. Then you release an update an other reviewer sees something that the first one didn't and pulls your app. Is that really the business model that you want?


Could you make "more" if you do it yourselves? Maybe. I don't know where you are or what your legal and tax requirements might be. Maybe you can find someone who will process these payments for only a 15-25% fee. You will have to do a lot of research and make sure that your payment provider will handle all of the details. Do you even know what those details are? Have you studied tax law in Austrailia, the EU, and Québec? Is your payment provider going to be following the same legal structure that you must follow? Will they process transactions that are legal for them but illegal for you? Is the money you save on the fee going to cover the added costs for accounting and legal research?


In your first post you said "I do not speak legal....so keep it simple please". Are you now saying that you are an expert on international taxation and trade?

You can decide the connecting to a service provdier, the thing provided by the app, has no value and not charge for it. However, the payment to the service provider for the service provided comes with a surcharge that the developer collects. So if you are flowers through the app from a local flower shop (i.e. I buy in New Jersey for a friend in Colorado and your app connects me to a flower shop in Denver) the payment to the flower shop comes with a surcharge that gets sent to the app developer. The developer can collect that surcharge by having the user pay the developer the flower cost + surcharge and having the developer pay the flower shop the flower cost (the user never knows the surcharge is in the price paid). Or the developer can collect that by having the user pay the flower shop directly and having the flower shop pay the developer a connection fee.


But the easiest, by far, is to have the flower shop pay the developer for inclusion in the app (through IAP, albeit, 70/30) and to have the flower shop bill the user directly outside the app anyway they want.

It doesn't have to be. The IAP is a small charge that the user pays to scan many many opportunities across a wide geographic range and differing features all provided by the 'Student Providers' made available through the app and done before any services are arranged. Then you enter into a service with a particular provider in a particular location - and pay big bucks through your website.


Consider babysitting services nationwide. I'd sign up through IAP for 100 hours, it only costs $2.99, might even be free, and use them during the next year. I'd arrange for next Saturday from 8pm to 11pm, 3 hours, $30. Visa or Mastercard? You'd collect the $2.99*70%, Apple gets 30%. You'd collect the $30 * 10%, the babysitter gets 90%.

You are now allowed to connect to a payment system or even have the payment system in the app - as long as what is being paid for are real world products and services, not unlocking code within teh app or downloading content to be viewed within the app. (if downloading content you can't have that button and you must operate as a reader app)

Thanks for your answers....definitely have learnt something....and possibly might go down that route

What baffles me however (and you might know the answer), is that Spotify uses 3rd party payment for its subscriptions on Android....

I knoiw Apple and Android are two different things 😉....but rules for the respective app markets are pretty similar.


How is Spotify doing this??

1) if another app gets away with something that doesn't mean you will get away with it

2) Spotify may be acting as a 'reader app' and just 'playing' content purchased by the user outside the app - 3.1.3(a) not unlocking code

3) Android guidelines may be different from Apple guidelines