Which payment system should you use with your app or site?
Narrowing it down
Deciding on a payment system for your new web or app based business? Finding the options overwhelming? The number of payment services available has ballooned over the years. With many of the options specialising in a particular type of transaction or emphasising a particular function or innovation of their own. As ever in business there’s a balance to assess when deciding which one to use. What do you need to consider?
- What are your existing banking arrangements? This might depend on your geographic location. Does your bank integrate well with your prefered payment system? Should you build the system around your current situation or consider moving to a bank which would integrate with more widely recognised systems?
- Where are your target customers based? It makes sense to use a system which integrates well with the prevalent banking service providers in your target customers locale.
- What sort of image do you want the payment system you use to project?
– Companies desiring a strong emphasis on security and reputation may wish to maintain their professional air by sticking to a longer established service, requiring direct connections with a merchant bank account.
– Even paypal, at one time perhaps looked down on as low brow for its association with ebay has now become such a widely accepted standard that it’s packaged inclusion in other services is prevalent and the services longevity and wide adoption give it a respectable reputation in an industry where security is key.
– Perhaps for newer companies, including startups, it may be appropriate to hunt around for something more directly tailored to your needs. You may also find that more newly established services also have special deals, rates or functions specifically aimed at winning themselves a space in the competitive financial services market, by offering you a great deal.
In-app purchasing
If you’re looking to generate profit through in-app purchases, your options are actually very limited. Apple are not highly tolerant of third party payment solutions in apps, so it’s Apple’s “in-app purchase” or nothing when you’re using iOS and Google’s “in app billing” is so thoroughly integrated that Android developers rarely choose to look elsewhere either. The systems are simple enough to set up, Apple and Google do all the hard work, but they also take a 30% cut. If you build a business model based on in-app purchases though, you’re probably well aware that this just comes with the territory.
An evolving sector
Ekreative has worked with a multitude of different payment systems, often chosen by the client on the basis of what works with their existing banking set up or where in the world they’re based. These services know that they’re operating in a competitive market and many of them upgrade their service and even release new features on a regular basis to keep ahead of the competition, so development experience may change over time. Here’s a quick look at what you can expect from of a selection of services we’ve worked with recently:
Paypal – the key to paypal’s ease of use from a development perspective is the fact that no card data needs to be stored. The user starts on your website, adds an item to a shopping basket (or similar) and the information about the purchase is then sent, with the customer, direct to the paypal site, where they deal with the banks directly. Not having to store or manipulate card data is definitely a plus for developers and using Paypal pro you can set up recurring and chained payments too.
Amazon payments – Amazon’s contribution echos paypal in terms of the convenience offered to both the developer and the customer. Site integration is easy and all interaction with the bank is done at their end, removing any necessity for you the developer, to do any messing around with merchant accounts. On the other hand, also like Paypal, Amazon doesn’t allow much by way of customisation and you may find their approach to branding to be heavy handed. Still, for the large majority of ecommerce sites, this type of approach is appropriate because of its convenience, despite the relatively high transaction fees.
Google Wallet – Whilst it’s been around since 2011 (in an attempt to make up for problems with the Google Checkout service), Google Wallet’s never really taken off in a big way. With many of the same benefits and disadvantages as the services mentioned above, somehow Google’s attempts to wrestle into the online payments market have never really taken root. They’re not giving up though. The Google brand remains big enough and trusted enough that their announcements about upcoming “Android Pay” services may well leave them on the table, at least for US based businesses.
Mercury Pay / Cybersource – In comparison to many of the big name brands, a service like Mercury Pay is much more flexible in terms of both implementation and branding. Set up is considerably more complicated as a result, but whilst that’s not necessarily a bad thing if you’ve got the expertise to hand, this service in particular is not one we’d recommend. Recent experience with their system revealed old, badly thought through api’s and while the support team were quick on the ball, it didn’t seem to improve the experience, which involved directly working with user credit cards, authorising them from our end and then sending the card data to the mercury servers. Cybersource is a similar style of service, which gave us a similarly bad experience, instead try:
Stripe – If you’re looking for this style of payment system, you’ll likely be better off sticking to Stripe. With intuitive and easy to use API’s, Stripes easy implementation makes it a much better choice for developers. Additionally, the credit card data is sent directly to Stripe, encouraging good security practices and making things much simpler at your end. Whilst the service is mostly great for convenience, if you need to get hold of sent funds instantly you may want to take another look at paypal, as Stripe and it’s ilk amalgamate all transactions over seven days, delivering funds in one bulk transaction.
Recurly – Recurly is a service which focuses specifically on recurring payments and could be used as a good alternative to Stripe if you know that you’re going to be working specifically with recurring payments only.
Learning from others
There are a lot of other services out there and maybe one of them appears to be offering exactly what you’re after. If so, great, but caution is still definitely recommended. Check for recent reviews and find out about other people’s experiences of using the service. Of course, the big name brands come with a big variety of reviews and user experiences, both positive and negative. Paypal for example, is often the subject of account freeze complaints and Stripe reviews are prone to accuse them of unresponsive support. Despite these possible problems, for the large majority of cases, the ease of implementation and wide recognition and adoption of these two services makes them the first choice for many projects and firm favourites with Ekreative developers too.
Learning from each other
Have you already tried implementing an online payment solution? Which one did you choose and why? What problems have you encountered and how did you solve them? Whilst we’ve got our prefered systems for the moment, here at Ekreative we’re always seeking to improve, to learn and to grow. So share your experiences in the comments below and lets grow together!