Actually I'm developing an iOS application for specific mobile operator,
The app will be free , and some content need to be paid so the operator
need users to pay via Premium SMS or IVR (interactive voice replay),
But after make some search i found that Apple maybe will reject the app.
because the need all payment being done via there system i.e via in-app purchase
or paid Model .
What is the ways to solve this problem , and How can i achieve this (Premium SMS ,paid IVR) ?
The bad news is: you can't ship an app that is solely based on paid sms from within the app. As this article on arstechnica states:
Content providers can continue to offer outside subscriptions that are accessible via an iOS app, so long as no external links to outside purchasing mechanisms are built into the app. If subscribers can pay for content within the app, it must use in-app purchasing APIs, though content providers are now free to set whatever price they like.
If you really want to deploy paid text messages, you could integrate in-app-purchase with a high price. Additionally you offer paid text messages at a lower price(Users send a text message via their ordinary message app to a number you tell them via your web page or ad or any other way). So users will tend take advantage of the lower price and will send text messages. An obstacle will be, that Apple won't allow a reference to the cheaper payment method from within the app. So it depends, on how you inform your users about your app and payment methods.
Related
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 am writing iOS client-server game.
Client side:
- server comunication,
- game user interface etc.
Server side:
- logic for game
- responsible for delivering some data and logic for iOS client
- manage payments
- manage user privilages
In my system I have my own virtual currency. User can buy virtual money via payment system.
User can spent virtual money in game. For spending money he builds his own reputation in my own loyalty program. For some level of loyalty he will have some privilages, for example access for other functionality of app.
As I mentioned, server will responsible for payments, using variety of payments system (paypal, sms, etc.)
And now...
I have a question: Can I use in this case any other payment systems without Apple's IAP?
I don't want to use it, because my server manages payments for all platforms.
I would like to make payments in iOS app using WebViews. Is it possible?
Thanks for replies :)
You must use IAP, since you payments are providing functionalities to your game.
From apple review guidelines:
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. Any credits or in-game currencies purchased via IAP must be
consumed within the app and may not expire, and you should make sure
you have a restore mechanism for any restorable in-app purchases.
Remember to assign the correct purchasability type or your app will be
rejected. Apps should not directly or indirectly enable gifting of IAP
content, features, or consumable items to others. Apps distributed via
the Mac App Store may host plug-ins or extensions that are enabled
with mechanisms other than the App Store.
I'm about to develop an app (for iOS and Android) that allows users to create a collection of digital content from their phone (e.g. some videos and pictures), and send that content to other users who can consume that collection on the same iOS/Android app. I'd like to bill users for sending a collection, because this process involves uploading and processing the collection to the cloud (which I pay for) and the recipient's app downloading it again (causing traffic costs). Note that I don't want to charge any money from the recipient!
The way I see it, producing such an iOS app is not possible (because Apple will reject it, see App store guidelines and In App Purchase Guidelines) for the following reasons:
Setting a fixed price for the app ("paid app") is not reasonable, because I want to charge the user each time he sends a collection, so IAP (In-App-Purchases) would be more reasonable
The IAP-logic/flow would be that a user can create the collection in the app for free and then, when he clicks the "send collection" button, he is asked to approve a purchase, in return he gets the link that he can send to his friend. The logic would essentially be the same in the Android app, using Google's "In App Billing"
Such an app could be rejected by Apple because of rule "11.3. Apps using IAP to purchase physical goods or goods and services used outside of the App will be rejected" - because the user essentially paid for hosting the collection, and that collection can be used outside of the app (by an Android app user for example)
OTOH it's also impossible to use external means of payment. For example, I was thinking about forcing users to first create an account on my website, where they can pay for a voucher (with Paypal, say) that enables users to send collections. They'd first need to log into their account in the iOS app and then they might see a warning that they have not yet purchased (or no longer have) any credits for sending a collection. The IAP guidelines forbid me to directly link to my website with a note saying that users can pay for additional credits by other means. When Apple engineers sees that message during review (assuming they aren't putting very bright people in charge) the app might be rejected, too. Even if it were not, this work flow is very uncomfortable for the user, I'd prefer IAP as this also makes accounting (taxes and earnings for my company) a lot easier.
I'd like to get your opinions on this. Please note that I might be "too hard" on myself. As a matter of fact, I do know apps that have been approved to the store that do exactly that, see e.g. here and here. Maybe they have been approved because paragraph 11.3 actually just forbids the ability to purchase the functionality of uploading (converting a collection to a link) and then use this functionality somewhere else - effectively that would mean "to buy credits for an external service" mechanism. My app wouldn't do this. You'd have to do the purchase and the upload/convert-to-link functionality would only work on that device where you did the purchase.
Any thoughts?
I have similar experience with an app i worked on. It was a GPS device showing tracking data in the app. The device uses cellular data to send tracking information and we need to collect a fee to pay the SIM provider which is an external service. We did this using Stripe payment but Apple rejected the app and asked to implement In-App purchase. Because we were blocking the user and asking to pay in the app that looks like we are asking payment for app digital content.
Based on my experience, to answer your question :
Yes you have to use In-App purchase and it can be Consumable type. When user try to send a collection, show a consumable purchase type. Keep track of the purchase in the server using purchase receipt, collection id etc.
Even though the amount collected is used for hosting and web traffic, you can term this as a service fee for managing/sending the collection. Behind the seen, you use this fee to pay your hosting provider or anyone else, that's up to you. Apple won't reject the app for this reason. Because you are charging a fee for digital service you are provided in the app. In apple guidelines, external physical service means, for example taxi charge in Uber, shopping goods price in amazon etc.
This is very common mistake developer often doing while choosing the payment options for any Payment related feature into application. Specifically in iOS there are new rules defined by the Apple for choosing the payment model for your application.
Here are some important points :
If your application having some points system or coins system for which you needs user to pay for than you must use the inApp purchase. And inApp purchase must be of type Consumable. So it will be purchasable multiple times
If your application offering any pro features or facility inside the application you must use inApp purchase. Type will be non consumable. (Note : For Non Consumable inApp purchase you must give Restore Purchase option into your application other wise your application will get rejected.)
If your application is providing any feature or any internal content access for limited time than you must use the subscription based inApp Purchase.
If your application is selling any physical goods than you must use any third party payment options. You can't use inApp purchase for it.
If your application is selling external services or any donation related feature then you can't use inApp purchase for it. This will be a complicated case & in this case according to the apple guidelines you should use the Payment gate way with Webview redirection. So the user will do the payment from the Webview redirected component.
Hope this helps to everyone.
I am developing an iOS App. In that I want to sell books to the User. In simple words, I want Payment Gateway Integration in my iOS App. My Research shows that we have option to use Apple Payment Gateway API but for every transaction they will charge 30% for them.
Is there any other way to implement this and Apple will approve ?
The Apple payment gateway/API is for in-app purchases (of virtual goods, apps, etc). For physical items/items which have value outside the app, you're free to use whatever payment gateway/API you wish, such as PayPal (cool new SDK for US-based payers), Square (not available in Asia), or any local online payment gateway that you have available depending on your region.
You can provide a web interface where you can implement payment gateway. and generate a token which user can use for purchase the book.
But still you need to provide In-App purchase (Apple provided) in case of e-book and in case of physical book i don't think you need in-App purchase you can use above way or any other way which you think better.
If you're looking for an SDK to accept physical payments within your app, then check out CardFlight (https://getcardflight.com). They provide the hardware and SDK so that you can accept a physical card swipe and handle the payment processing, all within your own app.
Full disclosure: I am currently working on this. We realized the opportunity for an open payment platform that processes credit card swipes within your own app when we realized there wasn't anything like this on the market.
In terms of payment/charging Apple payment gateway/API is for in-app purchases (of virtual goods etc.). For physical items which have value outside the app, I guess you're free to use whatever payment gateway/API you wish, such as PayPal (new SDK for US-based payers) who introduced a new mobile SDK that allows iOS app developers to integrate PayPal checkout and mobile credit card payment mechanisms directly into their apps.
This means that you are not looking at just having a PayPal button inside the app, where users are redirected to Safari on iPhone to complete their transactions, but with this new SDK users can pay without ever leaving the app or any local online payment gateway that you have available depending on respective region.
I am very new to in App Purchase, In my application I need to implement a way for the user to pay some money to the client. Could you guys please give me some ideas on different possibilities.
Do the client and user must need an apple id for transaction?
Yes, your client (as in the person who commissioned this app) and the user both need an apple id. The user needs it to use the app store and in app purchase. The client needs it to become a publisher on the app store and receive payment.
However, you can't just pick and choose if you want to use in app purchase. There are several rules that forbids you to use it for some purposes, as well ar requiring you to use it for others.
As a rule of thumb, if the payment is for functionality or data (such as more levels in a game), or a service (such as cloud data storage) - and you can deliver this immediately, you must use in app purchase. In some cases (such as books) you are allowed to accept payment outside of the app, but you are not allowed to link to that payment information from within the app.
If the payment is for a service or gods outside of the app (like a pizza, a donation or a bus ticket), you are not allowed to use in app purchase.
https://developer.apple.com/appstore/in-app-purchase/index.html
You could use iphone Paypal API for this.
Implementation details may be found in this link:
how to impliment payment-gateway with iphone application?