I was wondering if anyone has any experience selling apps through the Android, iPhone and Windows Phone market places using a subscription (recurring) payment model?
I have the requirement to develop a cross platform WP7, iPhone, Android application for a health and fitness company. The company wishes to sell the app as a monthly subscription, rather like you would a gym membership. It will be delivering personalised workout and nutrition advice to users as they progress through the programme.
I've read that iPhone supports directly a subscription model for content-delivery apps, e.g. newsreaders, that android supports in-app payments however Windows Phone doesn't seem to support anything like this. So, my question is:
Is something like recurring payments natively supported by any or all of the three main marketplaces?
If not, is there a workaround? Like prompting the user to renew monthly or quarterly and processing a new payment? Any comments / suggestions welcome.
Finally, what caveats should I be aware of with the three main marketplace hosts? I've heard horror stories of companies blacklisted for processing payments outside of the marketplace agreements.
The Windows Phone application policy states
Your application must be fully functional when acquired from Windows
Phone Marketplace (except for additional data as permitted below).
Unless you have a pre-existing billing relationship with the user,
your application may not require the user to provide payment
information, within the application experience, to activate, unlock,
or extend usage of the application.
However this paragraph seems to be ambigious. If anyone has any further information on this specifically I would appreciate it!
Finally, I have found some third party payment processors which claim to allow subscription payments through cloud services, e.g.
MoVend
Linxster
Again appreciate anyone who has had experience with using a similar method to achieve a subscription or recurring payment, even one driven by the user.
Best regards,
As told by a Microsoft rep yesterday:
The only way to do this on Windows Phone will be to redirect the user to a website and take the payment there. It's not permitted to take payment details directly within an app.
Related
The mobile application I am building has got payment features (both for buying some coins and subscription of (1 month, 3 months and 12 months) for premium accounts. Here, I should not directly ask card details to pay for the users, instead I need to the user's device stored payment to pay for the mobile application (it may depend on ios and android) I am building. Also, how do the subscription works and keeps making charges to the mobile application timely?
Actually, I need help with the implementation mechanism. I am new to this kind of scenario.
For iOS payment you should go with in-app purchase. It is apple's payment gateway. It has facility to create different subscription plan with duration. So, all things which you want that managed by apple. Same way for android , google have also same mechanism for payment(in-app feature).
I'm planning to add In-App purchases to my Productivity app. Enhanced features are purchase products (e.g., freemium).
I would like to have user access to purchased feature on both Android and iOS, if he has purchased on any one platform. Technically I plan to store purchase information on server and have it retrieved whenever user logs-in on either device, and unlock the feature if already purchased.
Is this allowed in both iOS and Android?
Apple App Store Review Guidelines on Section 11 have this explained.
Points "11.1/11.2" and "11.14" sounds conflicting (or I'm missing something.).
On Android, I do not see this point mentioning in Policies.
If you had any experiences (w.r.t sharing purchase info between devices) that I should take care additionally, any suggestions are welcome.
I'd like to add a note about subscriptions. Here's the quote from Apple guide:
Cross-Platform Considerations
Product identifiers are associated with a single app. Apps that have both an iOS and macOS version have separate products with separate product identifiers on each platform. You could let users who have a subscription in an iOS app access the content from an macOS app (or vice versa), but implementing that functionality is your responsibility. You would need some system for identifying users and keeping track of what content they’ve subscribed to, similar to what you would implement for an app that uses non-renewable subscriptions
Link to Apple docs: https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Subscriptions.html
Quote from Android docs:
You can also build on your existing external subscriber base from inside your Android apps
If you sell subscriptions on a web site, for example, you can add your own business logic to your Android app to determine whether the user has already purchased a subscription elsewhere, then allow access to your content if so or offer a subscription purchase from Google Play if not.
You can implement your own solution for sharing subscriptions across as many different apps or products as you want ...
Link to Android docs:
https://developer.android.com/google/play/billing/billing_subscriptions.html
At the moment of writing this answer (May 23, 2017) Windows Store doesn't have subscriptions but they were announced during the latest BUILD conference. Some details here and here
Subscriptions should be available later this summer.
Answering myself. I submitted to App Store mentioning this case and got it approved. I'm yet to submit to Google Play so not sure about it.
Below the snippet I mentioned in App Store review notes that may help some
If user already purchased premium outside the app(our website or
Android app), then we are unlocking Premium as soon as user
logs-in to the app on iOS device. We do not include any button or link
or information inside this app regarding purchasing outside. If you
have any concern or comments regarding this, please let us know.
Additionally mentioned that our in-app item's service is based on user data at our server and not solely on iOS platform. I think this is the key point that makes sense to reuse user's purchase of our service. However, I do not find this case mentioned clearly in App Store review Guidelines.
[Update for April 2019]
As I've already answer here - from developer Apple guidelines:
3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired elsewhere, including consumable items in multi-platform games, provided those items are also available as in-app purchases within the app. You must not directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods must not discourage use of in-app purchase.
So like #siddharth-gupta explain in his answer:
Apple's rule basically states that if you have a digital product in your app (in your case, your subscription), the only way to pay for it should be via Apple's in-app purchases. If instead of using in-app purchases, you redirect the user to pay using any other method, your app risks getting rejected.
Note: this Apple statement for April 2019 -> and can always change. To avoid potential rejection/ban Always verify it with current official Apple Documentation
My startup is developing a real-time marketplace platform for taxi companies somewhat similar to Hailo, Get taxi, Uber and Lyft (more or less), etc.
We are shopping around for a mobile payment solution and so far, we looked at the products offered by PayPal, Intuit, Braintree, and Stripe.
We are having a hard time with finding the mobile payment solution that fits our requirements.
Requirements:
1) (Must have) Passenger should be able to pay within the app by using previously added payment methods such as Credit Cards (CCs), Paypal (optional). Passenger is asked to enter the CC information only once when they sign up (or add a new card), so the CC info needs to be stored somewhere and retrieved when needed seamlessly. However, we would really prefer not to apply for PCI compliance.
Q.1) Let’s say I use PayPal Mobile SDK 2.* for payment system in our app. In the above scenario (1), is the passenger required to have a PayPal account (even for just using CCs for payment) and link it to our app?
Note: I have spent a lot of time digging into PayPal Mobile SDK 2.0 documentation (also called their support). I was told by the support person that merchants cannot store credit card info with PayPal for mobile payments (which I thought was the whole point of SDK 2.0).
2) (Optional) Passenger should be able to pay with a physical credit card by swiping it in the reader plugged into the driver’s smartphone. However, we need to integrate this process into our app (which is not currently supported by PayPal Here and Square). So, basically we need an API provider that allows creating custom POS integrated with our app.
Q. 2) Am I right when saying that scenario (2) cannot be accomplished with PayPal, Braintree, Intuit, or Stripe?
Q.3) Do you have any suggestions regarding the payment system that would allow us to implement scenarios (1) and (2)? just scenario (1)?
Please help if you have dealt with similar problems or know more about the subject. Thank you
Q3. You can also check out LevelUp. Facilitates in-app payments similar to PayPal and Stripe.
Similar to PayPal, it will allow you to store an access token after the user links their account. You will not be able to charge the card directly, as this would subject you to PCI compliance. LevelUp does not support the ability to swipe a physical credit card.
A. to Q. 1) Yes, the passenger is required to have a PayPal account if you want to enable future payments. PayPal stores and charges the credit card, without the merchant having access to it. This is pretty much the core of the Digital Wallet industry. You might have thought that you could process the credit card yourself, after retrieving it from PayPal. This is not supported, and would subject you to PCI compliance-ness.
A. to Q. 2) PayPal Here does not have a publicly available SDK yet.
A. to Q. 3) Just scenario 1 can easily be accomplished by integrating the 2.0 PayPal SDK.
I'm looking for some advice on an app that I am hiring a developer to work on for me - its my first app and his first solo app, so I at least am still getting a feel for the ropes a bit.
My question lies in the area of in-app purchases. My app will use an in-app purchase system that will be used to purchase "credits" for lack of a better word. Each time a credit is purchased it will enable data stored in the app to be emailed to a particular email address.
I had originally thought it would be good to have an external web-based shopping cart to deal with it, but I understand there are APIs available to embed these shopping cart systems into the app. Additionally I also understand that any "digital consumables" that unlock features of the app are subject to the commission that iTunes/Android charge, does anyone have any initial thoughts on whether the ability to email would be included in this?
Many thanks in advance.
Savvas, that's not true at all ... AFAIK , in Android there's some exceptions you can read here: http://play.google.com/intl/en/about/developer-content-policy.html
Paid and Free Applications
App purchases: Developers charging for applications and downloads from Google Play must do so by using Google Play's payment system.
In-app purchases: Developers offering additional content, services or functionality within an application downloaded from Google Play must use Google Play's payment system as the method of payment, except:
where payment is primarily for physical goods or services (e.g. buying movie tickets; e.g. buying a publication where the price also includes a hard copy subscription);
or where payment is for digital content or goods that may be consumed outside of the application itself (e.g. buying songs that can be played on other music players)
So for example, for buying a coffee, you can use your own payment gateway.
I am pretty sure that both iPhone and Android agreements require you to use their own payment services for all in app purchases.
That means you can't roll your own paypal/visa/any other payment system and have your users use that if you plan on distributing the app via the Google Play Store or the App Store.
That being said, you can still roll out your own payment system if you distribute your app via other channels (for android you can have a look at the Amazon app store and other solutions. For the iPhone there is no official third party app store since Apple prohibits it. Cydia is an alternative app store that many people have though in their jailbroken phones)
Personally I am a big fan of Urban Airship. Works great on iOS and Android.
If I have an iPhone app, Android app, and Blackberry app, is there any way to implement a monthly or yearly subscription-based billing scheme such that a user need only pay for one subscription in order to use my app on any device? The problem is that each app store seems to have the stipulation that any fees required to use the app must be paid through them so they can take their cut.
Dropbox does this, but I think they can get away with it because their apps will work for free, and the subcription only offers more storage space. Is their any way to do this type of billing for an app which requires a subscription in order to be used at all? If not, will simply adding some sort of free functionality get me around this?
Thanks.
[EDIT]
Let me be clear, my question is about how this can be done legally. I'm basically running up into the same issue that caused the Financial Times to stop offering its paper through a native iPhone app. The difference between them and me, though, is that I don't mind paying the app markets their cut. I just want to know if this is possible; a user can either order their subscription through Android Market or the App Store, and if a user isn't paying through both stores then I think I'm violating the terms of one of the stores.
You could try Bango.But you need to implement a possibility to transfer the Bango User IDs between your different apps on the different devices. They offer a service where they bill a recurring fee to the user. They offer a SOAP-Based API (amongst others) you can use from your app.
But beware: there are some legal restrictions concerning inapp payment in the Apple AppStore and the Android Market and maybe also in the Blackberry AppWorld.