I've read the Apple Store Review Guidelines and it doesnt seem to be clear for our use case.
We're developing a cross platform app with phonegap in which the user can buy or get for free some courses (which will be available to the same user on android and browser). What they get is content that a teacher using a separate web app has built (lessons and activities) that the user (student) can review at any time, any amount of times.
Is no clear whether using a third party payment gateway (that opens InAppBrowser) goes against apple store guide. Googling only makes things more confusing. It's certain it's ok for physical products, you can use that payment system.
Also because apple only allows discrete prices for the products, we had to change how a teacher sets the price, we made an incomplete list of the prices available.
We are in the process of implementing the third party payment gateway for the students that'd like to use the browser version.
How should I proceed about this? Should we use the same in all platforms, or use InAppBilling for android an InAppPurchase for ios?
Related
We have third party payment gateway on our application and apple rejected our app stating we need IAP.
Our app is supposed to be a coaching/career/testseries related app i.e. something like where you can buy content to study and practice on demand
Here's our business model and I need insights on how to approach it with IAP
Our platform let's user buy "x tests for y amount of money that expires in z days"
If you have used all "x" tests then you can check the new available plans and purchase them and similarly if you have passed "z" days.
These plans are non-renewable cause the tests are limited in nature and the pricing, no of tests and expiry keeps on changing depending on the market.
How do we approach this case?
Also the added complexity is also adding third party payment capability which in this case seems almost impossible but I'd like to ask
You cant use 3rd party payment gateway if the goods are digital.
your options:
make an in-app currency (coins) like games, so the user can buy a package of coins (for example 1000 coin) using app store IAP, then use it to buy stuff in your app as if it was 3rd party payment gateway.
show the different programs that the user can purchase and tell them to buy them from your website (but you cant put a direct link to your website in app) you can see how Spotify handels this in its iOS app install Spotify App and see how they do not even link to the main website of the service from the app because this is not allowed.
you can only show description and tell people to go to your website without linking to your website.
I'm finding it difficult to get a concrete answer on this, either I'm finding the wrong info or not comprehending what I am finding.
Our app will be available on the Play Store and App Store, as well as being accessible via Web App. We planned on using our website for customers to sign up, subscribe, pay, etc. The app will be a free download on the mobile app stores, with the free features active, only requiring a subscription for the advanced features.
Would this scenario (using Stripe for subscriptions, without any use of Google IAB or Apple IAP) break any developer agreements as they stand?
You will be rejected from the app store if you do this. Guidelines:
3.1.1 In-App Purchase: If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game
currencies, game levels, access to premium content, or unlocking a
full version), you must use in-app purchase. Apps may not include
buttons, external links, or other calls to action that direct
customers to purchasing mechanisms other than IAP.
If you don't want to bother integrating IAP, you can just exclude the payment stuff on the mobile client and let people do it on the web. Then, you can use your own verification mechanism to give people that have subscribed the correct content once they log into your app.
Spotify does something similar as described on their website. As far as how much of that they reveal in the app itself, you'd have to download it and see as I am not sure offhand. Your app may be rejected if it directly instructs users to go subscribe on your site.
The relevant info for the Play store is here.
Developers offering products within another category of app downloaded
on Google Play must use Google Play In-app Billing as the method of
payment, except for the following cases: Payment is solely for
physical products.
Payment is for digital content that may be consumed
outside of the app itself (e.g. songs that can be played on other
music players).
According to this, you are not required to use In-app Billing on Android since your content will technically be available on iOS and web as well.
I have this problem. I'm making an iOS application in Swift that sells user images and videos. I've got my own server, so all media is saved there. But now I've come to a point where I need make possible that user can buy some content from another user using a credit card or PayPal account. Other users can be found on a map, they have added their payment information to their profile (it's not visible to others) so that transactions could be made.
I've done some research on this topic and I know that a powerful tool for payments in Swift is Stripe. However, as far as I read about it, users can only pay to one account that you register. Basically, they can make purchases as if buying from a store. But in my case, I need to provide the possibility to pay to another user.
Also, I need to integrate PayPal. For this I found API's like Auth0 and PayPal API, but can't seem to find any more information on inter-user transactions.
And there is In-App Purchases option, of course, but I'm not sure if I can use that in this case, because most of my purchases will be done from a Web App.
Can somebody please help me, by giving some tips on how to move forward from here and implement this payment system?
There are several considerations to take into account, the three most important being price, ease of implementation and availability. I'll briefly discuss each point of the 3 options you mentioned:
Stripe:
Implementation: Stripe has a native SDK for iOS and has a functionality called Stripe Connect which enables payment between users directly, without having the money to go through your account, yet allows you to take a cut of the transaction if you'd like:
https://support.stripe.com/questions/can-i-enable-my-users-to-receive-payments-from-others
https://stripe.com/docs/connect
Price: Stripe has a starting fee of 0.3$ and takes 2.9 % of the full amount.
Availability: Currently Stripe is only available in 9 countries worldwide and available as a beta in another 15 countries:
https://stripe.com/global
PayPal:
Implementation: PayPal has a native SDK for iOS, but a very fractioned history of SDK libraries depending on how complex functionality you need (Which Pryo's answer underlined). Paypal has something called Adaptive Payments which allows for peer-to-peer payments:
https://developer.paypal.com/docs/classic/products/adaptive-payments/
Price: PayPal has a lot of mixed information about pricing (currency conversion, cross border transfer, etc.), but roughly it is a starting fee of 0.3$ and another 3.9 %.
Availability: PayPal is available in 203 countries/markets around the world:
https://www.paypal.com/webapps/mpp/country-worldwide
In-App Purchase:
Implementation: This money will always go directly to the developer, so this means you will need to implement some sort of service which takes money from your account to the final user. So the flow goes: buyer -> you -> receiver.
Price: Apple will take 30 % of the total amount.
Availability: In-App Purchase is available in every country where you would be able to distribute the iOS app.
Conclusion:
Don't use the In-App Purchase option for user-to-user sales, it's simply too complex and expensive out of the three options.
PayPal has a strong brand that people trust and is available in many countries, which makes it a stronger candidate than Stripe, but IMHO I would choose Stripe due to its simplicity and cheaper pricing.
If you want to implement in the swift Paypal has already SDK, which you can use to make between users to make simple payment:
https://github.com/paypal/PayPal-iOS-SDK
or if you need some more advanced feature like (third-party, parallel, and chained payments ) you can check old MPL library by Paypal:
https://github.com/paypal/sdk-packages/tree/gh-pages/MPL
For the In-App Purchases payment can be made by valid app store user only and there is mostly no facility of inter-user in general case in-app payments are made to app owner
So I have a RESTful Api service which has free and pay'ed stuff. Anyone can create an iPhone/Andriod/MSPhone app that leverages our api.
Bad analogy: imagine we're creating a chat api service for Steam .. and you can pay for more people in your friends list, instead of getting them via steam-experience/steam-levels. So now anyone can create a chat client (on any platform) .. and they use our REST api.
So, for anyone creating an iPhone app, are we allowed to accept credit card details and HTTPS POST them to our webserver .. where we call another payment gateway (eg. Stripe, paypal, etc.) to do the processing.
WE NEVER STORE ANYTHING ** (besides the receipt from Stripe, etc.)
Are well allowed to program this into our iPhone app? Or is that illegal?
Can we also offer bitcoins as a payment option?
(Note: we're not really using Stripe .. but they are a well known payment processor, which helps explain this question).
Below news is a big win for iOS developers. If it comes to effect then nothing like it.
https://in.pcmag.com/iphone-apps/144790/judge-apple-must-let-ios-apps-include-third-party-payment-options
Judge: Apple Must Let iOS Apps Include Third-Party Payment Options. The injunction, which takes effect in 90 days, threatens to upend Apple’s control over the iOS ecosystem.
As per this rule, no matter what you are selling from iOS apps, developers should be allowed to use 3rd party payment gateways.
For real goodies you can not use IAP.
For virtual goodies consumed into your app you are allowed to integrate 3rd party payment gateway as long as you also implement IAP. Also note the price for your product through the IAP shall not be higher then through 3rd party payment gateway.
Also thing about your product, if it is non-consumable you need to provide mechanism to restore the purchase.
I have a client who wants a mobile app that requires the user to enter a code to start using the application.
This is basically a promotional campaign for a new product: each product bought gives the user a code that he can put in the app to "advance" to the next level. The "game" consists of six levels. All users that finish the game will participate in a draw to win some prizes.
Is this allowed? I am concerned that the user cannot use the app without buying the product first.
All I could find, here and on Google, refers to selling stuff in app but nothing about this particular case.
Final thought: if this is not the right place to ask this question then I apologize...
11.1
Apps that unlock or enable additional features or functionality with
mechanisms other than the App Store will be rejected
11.16
Apps may enable additional approved features or functionality when
used in combination with specific approved physical products (such as
a toy) as long as the additional features and functionality are either
completely dependent on such hardware (for example an App that is used
to control a telescope) or also available through the App without the
physical products, such as by way of reward for achievement or by use
of IAP.
They just don't want you using any trick to avoid giving Apple their share. If your app is strictly promotional, you may get a pass for 11.1.
11.16 is for things like Skylanders. You can also follow the above clause or also available through the App without the physical products, such as by way of reward for achievement.
They do allow apps for sweepstakes/raffles, as long as you don't buy the raffle in the app, so it might fall into that category:
Contests, sweepstakes, lotteries, and raffles
20.1
Sweepstakes and contests must be sponsored by the developer/company of the App
20.2
Official rules for sweepstakes and contests, must be presented in the App and make it clear that Apple is not a sponsor or involved in
the activity in any manner
20.3
It must be permissible by law for the developer to run a lottery App, and a lottery App must have all of the following characteristics:
consideration, chance, and a prize
20.4
Apps that allow a user to directly purchase a lottery or raffle ticket in the App will be rejected
If you're worried about 11.1, I think one trick here is to make it not usable at all until you enter a code. "Additional" being the key word in "additional features". Then, it's the NetFlix model.
You'll need to provide codes for Apple to test the app.