[Question] App Payments

Aswerty

I have some questions with regards how mobile market places handle payment collection for hybrid apps.

My first question is if you are performing in app purchases do you then need to implement separate functionality for interfacing with the different market place payment systems? For example if an app had a premium version you can unlock does the action to unlock it need to interface with the Apple store api, the Google Play api, and whatever the Microsoft api is?

Secondly can you perform in app purchases and avoid the market place payment system directly? For example to upgrade to a premium version the app could take payment details and send these back to your server where something like PayPal or Stripe is used. Or would something like this breach terms and conditions? The advantages of doing it yourself is of course you get more of the money and you avoid having to integrate with the different market place payments systems. The down side being you have to handle passing the credit card details to your payments processor.

Finally is there any sensible way of having a subscription payment mechanism in an app? For example you pay €1 a month or something to use the app.

As you can see I really don't have much of a clue as to how payment for apps is processed. So any information outside of the scope of my questions would be welcomed.

MyPeopleDrankTheSoup

yes, you need to implement separate functionality in iOS and Android, it's completely different code but of course there's loads of help online. your question tells me you haven't started coding stuff for both Android and iOS yet. if you did, you'd face the unfortunate realisation that practically nothing between the two can be reused. so even if you used Paypal in both, you'd still be using different code, so you might as well just use the native IAP system

neither Apple nor Google allow apps with external payments in their stores. Apple never did and Google stopped it a few years back. note that you can still have external payment systems in apps outside the stores, like jailbroken apps in Cydia and side-loaded APKs. i myself use the Paypal SDK for my app on http://www.tinderautoliker.com/ and it works great. I get 85% instead of the 70%. it definitely has hit conversions as people trust the Play store checkout more but it's not doing too bad.

Android definitely have an app subscription system, not sure about Apple

i know nothing about Windows phone, and don't want to know anything

Aswerty

Thanks for the info. Yes I've not started coding yet, just trying to figure out how it all works before dipping my toe in. Googling about (and DuckDuckGoing about) didn't give me great results for these particular questions.

I have another question hopefully someone could answer. If you have a web app and you build a mobile app for it which you distribute for free but functionality, or at least some of it, is reliant on the person paying for a subscription on the web app can it still just be distributed for free on the Apple/Google mobile app market place? It seems like Apple/Google wouldn't be happy making nothing out of that particular scenario.

i know nothing about Windows phone, and don't want to know anything

Yeah I'm not particularly bothered with Windows phone either, just thought I'd throw it into the mix to see how everything in the wider picture works.

The Corinthian

Aswerty wrote: »

I have another question hopefully someone could answer. If you have a web app and you build a mobile app for it which you distribute for free but functionality, or at least some of it, is reliant on the person paying for a subscription on the web app can it still just be distributed for free on the Apple/Google mobile app market place? It seems like Apple/Google wouldn't be happy making nothing out of that particular scenario.

A hybrid app is essentially an app 'wrapper' for an embedded browser that simply shows your mobile optimized web site.

At it's simplest level there's practically no interaction between the browser and the app, however once you start looking to integrate additional functionality, you need to implement a means to pass messages from the app to your web site and vice versa.

Naturally, if you want to implement subscriptions via IAP, you'll need to be able to at least;

1. be able to start the IAP process in the app from the browser, and
2. be able to check if someone has a subscription through the app and pass it back to your browser (and ultimately server) so that you know whether to allow a user the extra content/functionality or not.

Both iOS and Android have means of doing this natively, although they are quite different. It may also be possible to do this using a multi-platform framework. Realistically, you need to have or hire the skills to do this. You could concentrate on what you know (I presume you have the Web side of development covered), if you hire out the skills I suggest you sit down with the developer and plan out what interactions are required and what both sides expect to send / receive in these interactions - an API.

Aswerty

Yeah I'd probably be going with a multi platform framework, such as Xamarin, as opposed to a hybrid app.

As you guessed I have the necessary knowledge to implement the API myself, I've done a fair amount of server side web development over the last few years. I'm completely new to the mobile side of things but I don't think it'll be particularly difficult to pick it up. While it will take longer for me to do it than if I outsourced it the overall cost will be significantly less. I'll also get to pick up a valuable skill. I've packed in my job to try out stuff on my own so I have more time than money at the moment.

I think I understand the payment side of things now. In app payments, be it subscriptions or once off payments, can only be done through the native payments api (e.g. in app purchases in Angry Birds). On the other hand you can have in app restrictions based on remote payment requirements (e.g. you can only watch movies on the Netflix app if you have a subscription on their website).

colm_c

The rules around payments are that anything used in app (e.g. new features) must go through the native payment method, whereas any features or use of services outside of the app eco system are not subject to this rule. There are some cases where this is blurry.

Also note, you cannot make credit card payments directly in an app, you need to either use something like PayPal's SDK or direct the user to a mobile browser to enter their details.

OP -- from experience the cross platform solutions are difficult to get right, often times you spend more time creating if statements identifying iOS/Android and writing specific code for them. Mostly because they have different paradigms and design patterns, which you want to keep specific to each platform.

Do up some POC's before committing!

Atomic Pineapple

+1 on Colm_C's post, I have done hybrid and multi platform app development and they simply don't work unless what you're developing is so basic a mobile website would do anyway. I would always go native.

You say you have the time so I would highly encourage you to learn to develop natively, you'll thank yourself in the long run, especially if you want to make money from your apps, you're going to want to give your users the best experience possible and native is the only way to do that.

Aswerty

Thanks for the replies. I've come across the argument before that hybrid platforms and/or hybrid apps aren't all that well suited for apps that directly generate revenue. I had a colleague in my last role who was working with Xamarin and compared to working within the normal Microsoft eco-system it seemed a bit finicky. And I imagine Xamarin is up there with the best of the hybrid platforms.

The Corinthian

At the end of the day, the suitability of hybrid or multi-platform frameworks depends very much on what you are trying to achieve and what the hybrid or multi-platform framework was designed for.

In a best case scenario, it typically takes longer for one to develop in a hybrid or multi-platform framework than a native one. This can make sense when developing for multiple OSs (for example the development time for one can be, say 70%, of what it would take to do an iOS and Android development). However they come with multiple issues too; we use Unity a lot, and while great for 3D and games, bugs and lack of support for native functionality are common issues, as is the fact that most Unity developers come from a design background, which means that any kind, even third party, library imports are a clusterfück at the best of times. It's also a games orientated platform, which means it's not ideal for many other app types.

As colm_c and others have touched on, the design phase is very important, as this is when you're going to ultimately assess whether you should go native or not. Personally, I'm a big believer is solid specs for any app. Other than the advantages this can bring to an in-house project, it means that you can always do one OS version yourself and offshore other versions more easily.