Integrating external payment system such as pay pal

Within my iOS application (currently on testflight) users can can offer their external services, for instance massage treatment, gym sessions etc.


Other users have the ability to buy these services in a form of a voucher which will appear in the application. Users are able to use the service that they payed for by going to the gym or to the masseuse and showing the voucher that is listed in the application under their account.


My question is what form of payment system am I obligated to use? Am I able to use an external payment system like paypal/braintree or the payments have to go through apples in-app purchases?


From what I understand if the goods/services are consumed outside of the application then can/must use traditional credit card entry, paypal or Apple Pay - which is my case.
https://developer.apple.com/app-store/review/guidelines/#goods-and-services


But I can/must use apple in-app purchases when the app offers extra content and features for purchase - so I am not really sure if showing the voucher inside the app after purchase falls into the category of extra content and features?

Replies

I think the "voucher" concept does complicate things. I'm not sure what the answer is. Is there a way you can just do away with the "voucher". Can't they just purchase a service from a provider?


The problem here is that the "voucher" could be like another form of currency - an anonymous currency. If you use the vouchers, then I can see Apple making a case that this should be an in-app purchase. But if you didn't have that anonymity later, then you would have a rock-solid case that must use your own payment system to ensure that the right person is getting the service that they purchased. Plus, there could be personal safety and privacy issues involved with something like massage treatments that take place in private. The more I think about it, I think you may have a legal obligation to have a verifiable and traceable chain of transactions.


Also, if you look at it from another angle, those "vouchers" could be used to purchase content that is not allowed by App Store Guidelines. If you wanted to hack your app and use it for gambling, drugs, or prostitution, would vouchers make that easier?


Now if you did want to offer in-app purchases to your users, then the "vouchers" would be your only option. But that would then be complicated for the customers if they could also buy service directly. Plus, you might still have a legal obligation for traceability and an Apple obligation to prove this isn't a black market app. So you might have to implement additional customer traceability on top of the vouchers.


Again, I don't know what the answer is. Please don't take this as any kind of legal advice. This is just a list of things to worry about. I strongly advise you to consult a lawyer for this app and see what your legal obliations and potential liability really are. Only then do you need to worry about Apple.

> so I am not really sure if showing the voucher inside the app after purchase falls into the category of extra content and features?


The voucher system is 'unlocking code' within the app and, to the extent it represents value, must be purchased through IAP. So in a perfect accounting system you would sell the voucher system through IAP and the service through non-IAP. But.....


1) If the main value is in the service and the voucher system is just a cute convenience feature then it represents so little value that you don't need to separately charge for it. NO IAP is needed, IMHO.

2) If the main value is the voucher and the service has little value then your 'charge' is really for the voucher and must be done through IAP. I suspect this is not your case.

3) consider giving away the voucher system to all users by including some simple 'free' service that requires the voucher. Then it becomes obvious to App Review that you are not charging for the voucher system.

4) consider charging, through IAP for $0.99, to enable the voucher system.

5) beware of hacks into your system.

Thank you very much for your answer, you have some strong points althought i have to say I don't think "vouchers" (receipts) would make gambling, drugs etc any easier than it is in an app where users can offer goods/services for buying.
Never the less other problems persist and thank you about your advice to consult a lawyer, this is what I am going to do next.
On the other hand I do still worry about apple since the level of support and direct answers as well as their guidelines is not as good as I expected so I am starting to think that the only way I can find out if my app/system does comply with each and every apple guideline is to publish it and wait...

Thanks again!

Hello, thank you for the answer.


What you wrote made me worried because my "vouchers" are actually receipts and if you dont have a voucher you can't consume the service/goods that you payed for, so I would say vouchers clearly have more value than the service/good itself.


I have a few questions though:


"3) consider giving away the voucher system to all users by including some simple 'free' service that requires the voucher. Then it becomes obvious to App Review that you are not charging for the voucher system."


Any user can see other users vouchers and any user can create a voucher so the system is free, once you want to buy a voucher that says 10 hours in the gym you pay and the voucher is shown in your purchase history list. So I am not quite sure what you meant by #3, maybe you mean creating vouchers that would be free?



"4) consider charging, through IAP for $0.99, to enable the voucher system."

Also not sure i get you here?


Thanks for the answer!

>I am starting to think that the only way I can find out if my app/system does comply with each and every apple guideline is to publish it and wait...


Yes, same as the rest of us...because - there are no pre-reviews, review is a fluid process that can change in an instant, and no one can promise what review will/won't accept/reject.


Finally, remember, it's called development for a reason. It doesn't help that the store is a blackbox, otherwise, tho


As for the title question, devs need to be careful how they 'integrate' any 3rd party billing system. It must be clear to the user that they are interacting with that system outside of Apple's control/involvement.


Good luck.

I think the scams are a problem for some developers. They may innocently design an app using a certain business model or that provides certain functionality and Apple rejects it for one of the "catch-all" reasons. They can't understand why and Apple doesn't provide any details. But most honest developers don't understand how scam artists and criminals think. Apple sees all those scam attempts and will reject anything that has proven risky in the past. Appe probably also doesn't want to publicize how many scams are in the store.


Also, now that you are calling these vouchers receipts, you may need to worry about being scammed yourself. An in-app purchase can be verified online, but only under certain conditions. These vouchers would be "consumable" in-app purchases. If you did have to verify them, it may not be possible at all with in-app purchase. I suggest you stop thinking or documenting them as vouchers and stick to "receipts". That makes it much more clear what they are, how they can be used, and justifies a choice to use non in-app purchase. You might still be money laundering, but you wouldn't be using Apple to do.

You seem to be ok, IMHO. The voucher system is available for all to see - it's free. You are selling the service and that cannot be done through IAP.


My #3 is satisfied as soon as the user can see any vouchers. If the user can't see the voucher without some payment then there is some code in the app that is blocked without some payment. Unblocking that code requires IAP. But if all you are doing is changing "$0 value 0 hours in the gym" to "$100 value 10 hours in the gym" you aren't unblocking code in the app.


My #4 was another solution - I don't think you need it. The free app describes all the wonderful services that are available for purchase. But first you have to become a 'member' by paying $0.99 through IAP. Now the app is open, the code is unblocked, and you can purchase $100 gym hours and $10,000 plastic surgery. Apple got it's 30% of $0.99 for unblocking the code that opens up your voucher system. They don't get 30% of the surgery fee.

Thank you for the thorough explanations, I get what you mean. Much appreciated!


Having read everything you said, I still have one more concern and it would be of great help to get your opinnion on this also.

It is about the way that the seller confirms that the user that wants to use the service actually payed for it through the app.


To try and be as clear and as short as possible...

Scenario:

  1. User (buyer) buys the voucher from another user (seller)
  2. Once bought that voucher is listed in Users (buyers) "purchase history" along with a unique QR code for this purchase
  3. When a user wants to consume the service/good that he purchased he goes to seller, opens the app and shows the qr code
  4. The seller also has the app, opens the QR scanner within the app and scans the code after which that voucher is marked as used


So the unique QR code which I generate and show after each purchase is the thing that worries me at this point. Optionally I could send it through an email or send some code through sms in order to completely remove the QR code generating/scaning functionality but I wouldn't like to do that...

I'm not sure what your question is. One question could be:


How do I assure that the seller can't be fooled into accepting an invalid or fraudulent QR code from the buyer?

If that is your question then here is my approach: The problem is that the buyer owns their device and can fiddle with it, can backup to when they had lots of voucher credits, can alter the code. So you need some other authetication system. CloudKit will do that. Have the buyer's app push something to CloudKit when they purchase vouchers and when they want to use purchased vouchers. Keep a record of their total number of vouchers (CREDITS). When they want to purchase something using 63 vouchers then debit that CREDITS record by 63 and create another record (WORTH63) with 63 vouchers and a unique code. Allow the buyer to display that unique code within a QR code. When the seller wants to accept 63 vouchers have the seller scan that QR code and use the unique code within the QR code to check for the WORTH63 record in CloudKit. If and only if WORTH63 exists, compete the transaction - indicate OK on the app, mark the WORTH63 record as USED and credit the seller's CREDiTS record with 63. Add some text in WORTH63 so that when the buyer tries to reuse that QR code (e.g. using a screenshot) they, and the next unsuspecting seller is told "Failed - used November 4, 2018 at Ace Hardware in Hoboken, NJ" not just "Failed".