We have hit a hurdle with Apple/Itunes and rejection of a submitted binary and would like to know how to find a solution which meets the 'guidelines' and also fits our purpose.
We have 2 billing situations (Subscription for services outside the app):
Subscription (monthly or annually) - Can use In-App Purchase but how does an external system view each transaction or status (eg a website using API to extract?)
Variable priced monthly fee - Monthly subscription + varying additional fee based on usage (similar to a post pay mobile phone plan)
Therefore, 2 questions:
How does an external source (eg a webserver) extract InApp purchase data for a specific user?
Can In-App purchases perform variable priced subscriptions, (similar to ReferenceTransaction in Paypal or a BillingProfile/Authorize process for payment gateways)
I'm not familiar with PhoneGap and the Approval process this would require but would assume the same problem would occure with Apple stating the guidelines are being breached.
Ideally we would like to use PayPal for Subscriptions and PayPal/Local
Payment Gateway for CreditCard authorisation billing of variable
monthly amounts. The framework to technically perform this is
available via customised API calls.
If InApp purchases can perform these functions and present a summary of this information to an external service we're happy to work with Apple but so far I cannot find anything that would suggest the functionality is available.
Any information related to Payments within an IOS App would be appreciated.
We've been told that if we do not use InApp purchases we must remove ANY links to the website and not have a registration section within the App, only login.
Found these links below which do not inspire much confidence:
How to sync iphone in-app purchase with website
iTunes In app purchase
For any in-app purchase review guidelines. Refer to this link
Q1. How does an external source (eg a webserver) extract InApp purchase data for a specific user?
-> Make sure you use a secure server (https not http) to access receipts. Refer to this link for Validating Receipts with Secure Server
Refer to sample and Video series showing example of validating on server RayWenerlinch ( External Website )
Q2. Can In-App purchases perform variable priced subscriptions, (similar to ReferenceTransaction in Paypal or a BillingProfile/Authorize process for payment gateways)
-> Yes, you can add new in-app purchases and subscriptions without adding new build. link
Related
I developed an iOS app for my client which consists of three primary functionalities:
Masterclasses
Clever Closet
Vision Board
I have a website from where you can purchase the masterclasses. So, the Clever Closet and Vision Board are free of charge. You can login with the credentials from the website, but also you can register a new account (without access to masterclasses or external links to payments). Firstly, I tried to use buttons with external redirect to the website, but I found out this is not allowed so I removed them.
Right now, my app was rejected from the App Store submission based on:
Hello,
Thank you for your resubmission. Upon further review, we
identified an additional issue that needs your attention. See below
for more information.
If you have any questions, we are here to help. Reply to this message in App Store Connect and let us know.
Guideline
3.1.1 - Business - Payments - In-App Purchase We noticed that your app includes or accesses paid digital content, services, or functionality
by means other than in-app purchase, which is not appropriate for the
App Store. Specifically: Your app accesses digital content purchased
outside the app, such as memberships and courses, but that content
isn't available to purchase using in-app purchase.
Next Steps
The paid
digital content, services, or subscriptions included in or accessed by
your app must be available for purchase using in-app purchase.
Apps that offer paid digital services and content across multiple platforms
may allow customers to access the content they acquired outside the
app as long as it is also available for purchase using in-app
purchase. See Guideline 3.1.3(b) Multiplatform Services for more
information.
If you have any additional information to provide
regarding the digital content and services in your app and how the
guidelines apply to them, please reply to this message in App Store
Connect and let us know. If there is information you'd like us to
consider in our review of future submissions, please feel free to
include it in the App Review Information section of App Store Connect.
My client doesn't want to use in-app purchases, we are providing purchasing these masterclasses on our website. Isn't my app a Reader App?
3.1.3(a) “Reader” Apps: Apps may allow a user to access previously purchased content or content subscriptions (specifically: magazines,
newspapers, books, audio, music, and video). Reader apps may offer
account creation for free tiers, and account management functionality
for existing customers. Reader app developers may apply for the
External Link Account Entitlement to provide an informational link in
their app to a web site the developer owns or maintains responsibility
for in order to create or manage an account. Learn more about the
External Link Account Entitlement.
Also, I do not want to use the External Link Account Entitlement, so it should be simple. What do you think?
My app was finally approved, because I mentioned that is a Reader App using their guidelines, so I had right about it and regarding the fact that Apple try to force you to use their IAP!
My Application got rejected Recently with following error
Guideline 3.1.1 - Business - Payments - In-App Purchase
We noticed that your app offers a subscription with a mechanism other than the in-app purchase API.
Next Steps
To resolve this issue, please revise your app to ensure that the subscription for products used within the app is offered using the in-app purchase API, with the exception of the content specified in guideline 3.1.3 of the App Store Review Guidelines.
In-App Purchase
It may be appropriate to revise your app to use the in-app purchase API to provide content purchasing functionality.
In-app purchase provides several benefits, including:
The flexibility to support a variety of business models.
Impacting your app ranking by consolidating your sales to one app rather than distributing them across multiple apps.
An effective marketing vehicle to drive additional sales of new content.
For step-by-step instructions on in-app purchase creation within App Store Connect, refer to App Store Connect Help.
You can't sell subscription using Stripe, because it's a digital property.
More info:
There are a couple different ways to integrate payments into your iOS
app: Apple Pay and In-App Purchases. It’s important to understand when
each option should be used.
You can use Apple Pay to sell physical goods such as groceries,
clothing, and appliances. Also use Apple Pay for services such as club
memberships, hotel reservations, and tickets for events. These
transactions will be processed through Stripe and you’ll only need to
pay Stripe’s processing fee. You can read more about Apple Pay here.
You are required to use Apple’s In-App Purchase API to sell virtual
goods such as premium content for your app, and subscriptions for
digital content. Specifically, Apple’s developer terms require that
the In-App Purchase API must be used for digital “content,
functionality, or services” such as premium features or credits. If
you use the In-App Purchase API, the transactions will be processed by
Apple, which will charge a fee of 30% of the total transaction.
Docs: https://stripe.com/docs/mobile/ios#using-stripe-and-apple-pay-vs-in-app-purchases
You can't use a payment gateway other than InApp purchase to offer soft services/digital good transactions(Any functionality within the app) in your app.
First of all, my app include contents which are only allow to watch or access for membership subscribed user. It include 1 week, 2 weeks, 3weeks, 4 weeks and user have to pay it via other payment gateway which was popular at our country instead of IAP.
I can't use IAP because clients(users) at my country have problem with using IAP services because there is no international credit card services or payment services such as MasterCard,VIZA,etc are not supported as well. Also we can buy iTunes Gift Cards of course. But, compare it to our price subscription list, it is really too much
Here our subscriptions prize and it doesn't include auto-renew
1 weeks subscriptions -> $0.5
2 weeks subscriptions -> $0.9
3 weeks subscriptions -> $1.3
4 weeks subscriptions -> $1.5
So compare it to Apple Store Gift cards $10, that is not possible to use IAP. And at our country, giftcards are hard to buy because there is no Official Apple Store or authorized store.
To explain you about my popular payment gateway, it was like using Apple Gift Cards. It was just purchasing PIN codes from nearest Mini-marts, cafe and other shops. You can see the detail here.
http://reddotpayment.com
At my app, I included internal web view and it leads to reddot page which include textfield for PIN codes. After user fill the pin code which they bought and click subscribe, it can now part of our membership subscriptions. That's how it goes.
But Apple didn't allow and reject my app. They respond me like that.
Guideline 3.1.1 - Business
We noticed that your app enables the purchase of content, services, or
functionality in the app by means other than the in-app purchase API,
which is not appropriate for the App Store.
Specifically, your app uses Red For pay to purchase subscription
outside the app.
Next Steps
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 through in-app purchase, within the app - unless it
is of the type referenced in guideline 3.1.3 of the App Store Review
Guidelines.
Was it because I do the transaction outside of the app? I mean even internal web view? What if I make the transaction inside the app with UITextField call to our API for making the purchase?
Any Suggestions?
Only two ways to solve this case.
Use their In-App Purchase
Else try to trick the Apple with Server-side control especially when they are reviewing your app for App Store Distribution approval.
Please note :
Using No.2 might get your app rejected when they detect your app is
using 3rd party payment service instead of their because they want the
money for each subscriptions as long as your app meant for using only
at your country or specific territories not international.
Because if you app meant for using at world-wide like Uber or Instagram, then you are at dead end.
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 looking to start selling an app on the Apple app store however currently the app uses our own servers to generate a license to the customer once they have purchased it. How can our existing licensing system which uses our own servers be implemented if a customer purchases the app from the App Store instead?
The application license will be a yearly renewable one. Therefore, so far, from what I have read, the app on the App Store could just come with an auto-renewal option (opt-out of course) so that would take care of the subscription cycle but how can our own server issue the customer the one year license which they could then renew from iTunes using the auto-renew function of the App Store?
I am sorry if this is not clear but it would go like this:
Customer downloads application from app store with a one year auto
renewal subscription.
Customer pays.
The app store verifies the
payment.
Once payment is verified it contacts our server to create a
license for that purchase and for one year.
That license is sent back
from our server to the purchased app to unlock the subscription.
Please correct me if my understanding on how this works is wrong but if anyone can point me in the right direction or give examples of how an application on the app store can successfully issue licenses from their own server then I would be very grateful.
As an example, look at "Aviation Exam". They let you buy subscriptions on-device as in-app purchases, or on their own website. In each case the details are synced to a user's account on their own server, so the same exam can be used from any device.
Look at the Apple documentation for how in-app purchase subscriptions work on iOS. Then your app can send details of a purchase to your servers, and download further information.
Edit; after discussion in comments:
If you want payment to go via Apple then it has to be via App Purchase or In-App Purchase. In-App Purchase specifically supports the idea of buying a subscription for a limited time. This is explained at the second link above.
If you want the user to create an account on your server you can either have a page in the app for them to input their details, or you can bring up a web page served from your website. Either way, the info can go to your server and it can create an account.
The key thing is, if payment went via Apple then inside the app is the only place you know this. The app can send this info to your server. You need some common identifier (i.e. a user-name) that is known to your server and to your user, then the user keys it in to your app and it can all be matched up.
There is nothing complicated here, to a decent software developer. All they need is an existence proof such as I gave at the top, and they can figure out how to link the info together.
Edit 2
Some tutorials for in-app purchase listed at: In-App purchase server model
Lots of low-level detail at: Verify receipt for in App purchase
If you prefer to handle payment yourself, not via Apple, then the situation is very different. Now, your own systems have to keep track of what has been bought, when subscriptions run out, etc. To begin with, the app won't know this at all. However, once you identify the user by having them enter credentials (username/password), you can fetch all the details from your back-end system to the app and proceed as above. Again, this is all visible in the example I gave at the beginning, which supports both Apple and non-Apple payments.
One thing to note: if you handle payment yourself then Apple isn't getting its 30% cut, which is the usual App Store commission, so they may not like this. The guidelines say:
11.1 Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the App, such as a "buy" button that goes to a web site to purchase a digital book, will be rejected
That's pretty clear-cut, but since there are apps that rely on subscriptions or content purchased elsewhere, they don't seem to follow these rules in every case. Even the Amazon Kindle app was allowed back, once they took the 'buy' button off.