1st app submission, rejected because we´re not using IAP

Hi Everyone,


Spent months building my first app and it has been rejected because we are using an external payment provider in our client admin area for them to top up their balance and continue to use the app.


Guideline 3.1.1 - Business - Payments - In-App Purchase

..... While the payment system that you have included may conduct the transaction outside of the app, if the purchasable content, functionality, or services are intended to be used in the app, they must be purchased using in-app purchase, within the app - unless it is of the type referenced in guideline 3.1.3 of the App Store Review Guidelines. .....


Our app works on a transactional model. You buy "credits" that allow you to 1) scan some information on the phone 2) which we store on a database and said data is 3) sent to a goverment website and submitted. Not only that, but our backend produces a 4) PDF A4 containing this data which can be downloaded by the user in our backend and 5) we send a collection of these A4´s by post to the client on a monthly basis.


The user will regularly be using their web based client admin area for downloading these PDFs, as well as other account management tasks, and part of the client admin has a billing profile and stripe where users can top up their credits which is then transmitted to the app as a credit balance. If you don´t have credits, you can´t use the service.


I´m hoping KMT and PBK and others can chime in here please!


Therefore, in fact, most of the business value occurs after data capture on the phone, point 1. Points 2, 3, 4, 5 are business value which is provided "outside of the app" in the client admin area backend, and in fact, this is the ultimate aim of the service. and I´m hoping I can adhere to point 3.1.5 (a) ... ??


Furthermore, from my reading I am seeing that having a "Sign up" screen inside the app may provide Apple with a red flag?


Lastly, how would you experts suggest I deal with this:

1) Reply on rejected binary Resolution Centre?

2) Create a new binary and try again.


Many thanks in advance!


Ben

Up vote post of BenJS Down vote post of BenJS
1.3k views
Posted by
BenJS
Reply
Add a Comment

Replies

You are describing an app with two streams in it. Much of what you described is in a first stream that involves unlocking code within the app and you must use IAP for that. Some of what you describe (printing out the documents and sending them to the user) is a second stream of printing documents and sending stuff to the govermnment - that's 'physical goods and services' and you may not use IAP for that stream. So you need to divide up what you are doing into two payments. Use IAP for the first stream and an external system for the second stream. You could "not charge" for that first or second stream in which case you could use only the third party payment system or only IAP. But App Review might not accept the idea that you are "not charging" for something that you are actually charging for.

Posted by
PBK
Up vote reply of PBK Down vote reply of PBK
Add a Comment

Hi PBK,


Thanks for your input. What an unexpected minefield this is turning out to be!


The way the app is built and designed is around pre-paid credits; we don´t need users to enter a token on the app to obtain these credits, neither do we ask them to go and pay outside of the app - they will find the payment system in the client web admin panel and then the display of credits will increase in the app according to their top-up in client web admin.


The two streams, maybe that´s the way to look at it. However, the absolute value is in sending the data to the government and creating digital copies of the PDF form and it´s printed out paper version.


I have no idea how I could suddenly charge for the 2 different steps... it would make things very messy for the user.


Is there no way around this? It´s going to crush our business model having to give 30% for IAP that is not really needed. How do other apps do it, like Pipedrive where it´s not just a reader app, but read and write, and other apps that are similar to ours have got around it - but their model is a monthly subscriber fee charged outside of the app - then login to the app to use it (but you are still paying for it externally).


Thanks again, any ideas would be appreciated.

Posted by
BenJS
Up vote reply of BenJS Down vote reply of BenJS
Add a Comment

You are providing the following:

>sending the data to the government and creating digital copies of the PDF form and it´s printed out paper version.


Allow the user to continue to use the app in various ways to create and display the data within the app (but not send it to the government nor create a digital copy nor print it out) even if they don't top-up their credits. Then tell App Review that (to paraphrase their objection)
"the purchasable content, functionality, and services are NOT intended to be used in the app".

Posted by
PBK
Up vote reply of PBK Down vote reply of PBK
Add a Comment

Assuming I understand your current business model, I don't see a way to satisfy you, Apple, and your user-clients.


Seems you arrived at this point by leaving Apple's take on the process until the end. Now that you know more about what Apple wants out of the deal, you may need to re-tint the paint, with them at the top of the list.


What Apple allows

What your clients need

What you can deliver


Only then can you decide if there is a mix that will work for all parties involved.


Good luck.

Posted by
KMT
Up vote reply of KMT Down vote reply of KMT
Add a Comment