Top Six Ways To Collect Payment For Your App

From App Stores to Custom Payment Systems, No Option is Perfect

by Kaj Gronholm

You’ve built an app and now you want to monetize it. It seems like a simple concept – companies sell apps all the time. However, actually collecting payment from your customers into your bank account means making some compromises because there’s no perfect, simple method to do this that fits every use case.

In this blog, I’m not trying to address how to price your app. What you actually charge will have some impact on the app payment method; however, sometimes the way you sell it will also influence what you charge. This blog also isn’t focused on how to set up e-commerce sites that sell products. The focus of this blog is addressing the nitty-gritty of different methods for collecting payments themselves.

Too often the decision on how to collect payment is left for after the app is developed. However, as we shall see, waiting until the end will change the options you have. The goal for this post is not to give all the detail on every option, but just to discuss the high-level pluses and minuses of each choice. Hopefully, this blog will give you a foundation of knowledge so you and your development team can make the best decision.

In this blog, I’ll cover six methods to get money from your customer’s bank accounts into yours and I’ll address how they work for both Web and Mobile Apps. I’ll start with the mobile options, then discuss options that work for both mobile and web, and finally just web options.

Collecting Payment in the App Stores: Google Play and Apple App Store

One of the simplest methods to collect payment for your mobile app is to charge to download it from the app stores. You put your mobile app in the store and choose a price ($1.99 to $4.99 is the most common, but it can be anything you want). 30 to 60 days after the end of each month, Apple or Google will send you a check. However, you might be surprised to find out the check is for 70% of what was sold, the other 30% stays with Apple or Google.

Why would anyone give up 30%? Well, for one, it is the simplest way to collect payment for your app. Apple handles all payment processing and returns. You have a low-security risk since you never process a credit card transaction. Another reason may be that it’s the only option you have. If your app doesn’t have user accounts or other features that require a back-end server, there may be no way for a user to send you payment.

Selling direct in the app store is also a good option if the price of your app is very low, say under $10. In this case, your goal is volume. It’s much easier for someone to just download an app and click approve payment. At a price point of $1.99, most users are not going to want to go to your website and create an account and enter a credit card. Apple has recently changed its terms if your app is subscription based. Now you’ll pay 30% on the first download, but when the customer renews the second year they will only take 15%. How nice of them.

There are definitely good reasons to sell your app using a per download fee in the App stores and many apps make their owners very good money in the stores; however if your app will create user accounts, and requires a backend server, you may find that there is more money to be made using “in-app purchases” or registration on your website.

Free to Download in the App Store, “In-App Purchase” for Premium Features

This is a corollary to the method above. It’s also known as a Freemium model, though the term freemium can be used to describe other payment methods too. In this plan, your app is free to download, but if the customer wants all the features, you charge for them in-app. Like the option above, it’s a simple method and very effective.

However, just like collecting payment to download the app, Google and Apple keep 30% of these purchases. If you are selling content that is “delivered” via the app itself then you can’t avoid this 30% fee. The concept of “delivered” via the app is a critical one. Some apps, for example, Uber, do not pay the 30% fee, even though Uber will charge you in the app itself. The key here is that the content or service is delivered out of the app. In this case, the phone can’t pick you up and drive you around (at least not yet!), so Uber does not pay the fee. For an alternative example think of Audible. Their books can be delivered in the app. For this reason, Audible won’t let you buy an audiobook in-app, you need to buy audiobooks on their website. The Audible app just lets you download what you have already bought.

Apple and Google are quite strict about enforcing this rule. It’s sometimes hard to figure this out if your content/service is delivered in-app or out-of-app, but we can help you figure this out.

The “in-app purchase” model is great if your app has a low price, think $0.99 to $4.99 features that you can buy. Also if you have some free content that is valuable without the purchase. However, if you don’t have these low priced features, or have a strong web presence, it’s likely best to avoid the 30% fee, and use another option.

Free in the App Store, but Payment Collected on the Website App

Now we are getting to the fun options, at least from a technical standpoint. In this case, we have a mobile app that is free to download in the app store and there are no premium options that you pay for directly to the app store. However, you can buy things inside the app, such as premium content and the app has a web server backend, that will hold all the customer information and credit card data. It’s definitely more complicated than just collecting payment directly in the App store, but you can avoid the 30% fee.

As mentioned above, Apple can be a bit finicky on approving apps that collect payment outside of the app. They, of course, want their 30%, but there are plenty of apps that allow for payments on the website. For example, an e-learning app that students use to take photos for a portion of a class, but use a web app to complete their course. In this case, you can give your app away for free and then have the students pay for the course online. Another example would be having a mobile app that is used by someone who is out in the field, say doing construction, but the field users are managed via a web app. The field users download the app for free, and you charge the web users online. The field user app isn’t useful without a web account to create the logins.

If you’re designing your app to avoid paying Apple’s fees, then having web-based payments is a great way to do it. However, care must be taken to ensure the user experience is smooth. Take a look at an app like Audible, your account and credit card are entered into the web app, then when you download the mobile app, you just need to sign in. The development team still needs to implement things like “Forgot Password” capabilities on the mobile app, so there is some overlap for user account work. These types of app features aren’t always necessary if you’re just taking payments in the App stores.

Technically the general flow is that a user logs in on the mobile app; the mobile app will connect to the web server backend to verify the account via an API; then, over the API, credentials, and content are sent back to the app. This is all done securely over SSL. Care needs to be taken to make sure user accounts, EULAs (End User License Agreements), and forgot password features all work seamlessly with the web server’s API.

Another bonus is that if you’re collecting payments in your web app, you can more fully control features and content on your mobile app. Often the best plan as discussed above is to give your app away for free, and then handle the payment on the web app. Now we have full control over all features in the mobile app via an API and can turn them off or on based on the plan we sell in the web app.

None of these technical details are challenging, but they do take time. The question is whether it’s better to invest this time and skip the 30% fee, or if you are better off just letting the App store collect payments. We can help you decide. Of course, if you’re collecting any payment, you still will be charging a credit card and paying about 3%. Which brings us to the next method. . .

Collecting Payments in a Web App

Whether your app is mobile and web or just web, a great option is to collect payments inside of your web app. About half of our customers choose this option and for good reason. It offers the most flexibility and the lowest on-going costs. Since it’s your own custom payment solution in the app, you have the flexibility to choose and change your versions of payment. Setting up thresholds for “freemium” content, having free trials, adding in tiers of subscriptions, having one time payments and then lower monthly subscription fees, turning on and off options are all available to you.

There are some upfront and ongoing security costs. Your site needs to be secure, as well as PCI compliant. User accounts and payment methods are prime targets for hackers, so once you go down this road you need to plan to invest in the maintenance and upkeep of your site. All that said, you have complete control when using a web app for payment collection. Your users will create accounts on your website and then enter credit card information. You choose if there is a one-time fee or a subscription.

It’s important to know how the payments are processed, as there are a few choices. It’s simplest to think of credit cards being run through two steps. The first is the payment gateway, which is basically the tools to get the credit card information. Think of the payment gateway as the credit card machine on your website. It’s where users enter their credit card info and it authorizes the card. To actually get the funds from the credit card to your bank account requires the second part, a merchant account. The merchant account is a bank account that processes the credit card and collects payment and sends it to your bank account. You need both a payment gateway and a merchant account to complete a credit card transaction.

To further simplify this process there are companies that combine the two steps. Companies like Square, Stripe, and even Paypal, will do this for your site. For the ease of combining the payment gateway and merchant account into one, they will charge 3% plus a transaction fee.

3% does not seem like much, but if you are collecting $100,000 per month, that’s $3,000 per month or $36,000 per year. If it’s $1,000,000 per month then it will cost you $360,000 per year. By having a separate merchant account and payment gateway, you can get the fees down to 1.5% or close to half of the price for the bundled service. Therefore, larger companies almost always have separate merchant accounts and payment gateways.

It really isn’t much harder technically to have separate payment gateways and merchant accounts, so if you’re willing to spend the few hours getting them set up at the beginning, you can increase your profits by 1.5% which could be huge over time. Companies like Authorize.net allow developers to set up the payment gateway and merchant account separately and to do so without storing credit cards on your site.

Hopefully, as payment methods continue to get more and more diverse, we can get away from the high-priced options and get closer to 1% fees for processing payments, but we’re not there yet. However, regardless of the payment gateway/merchant account we set up, the option of collecting payments on your web app is the most flexible choice.

Collecting Payment through your CMS (Content Management System)

CMS systems like WordPress are great for your “brochure” site. Many, if not most, of the apps we develop at Woodridge use some form of public-facing marketing site, which is often built using WordPress. The Web app that Woodridge will build will typically not be WordPress, as our apps tend to have far more features and are more robust than a platform like WordPress can support. So a very common case is that there are two websites – a WordPress or other CMS website for marketing and the Web App for the technology. This is not inherently a problem and it generally makes the most sense. Since WordPress is relatively easy for a non-technical user to manage, it’s great for marketing. However, your web app generally needs features that WordPress won’t support, so it’s separate. For most of our apps, the end user doesn’t even know that he is going back and forth between the two apps.

So why not use WordPress to collect the payment? WordPress has some very slick e-commerce capabilities that make it easy to collect payment, such as the WooCommerce plugin. With little to no technical knowledge, you can set this up. However, if your app is subscription-based (as most are these days), you now will need to tie in your WordPress database users with your mobile and web app database users, and this is not always seamless. WordPress does have some single-sign-on (SSO) capabilities to make this easier and plugins like WooCommerce do an adequate job of supporting subscriptions, but integrating things like free trial periods and multiple payment options or supporting changes to the main account email start to get tricky when using WordPress to collect payment.

Using WordPress, or a WordPress plugin like WooCommerce, is a valid option and it can be set up quickly. It’s best used if you don’t have a complicated pricing model and are not expecting it to change much. You will still need to set up a payment gateway and a merchant account as mentioned above, but that’s very straightforward. If you already have a CMS for your marketing site and your payment collection plans are simple, then it might be the way to go for your app. However, it’s a choice that comes with the limitations of the CMS, so it’s a decision that needs to be made carefully.

Sending Traditional Invoices to your Customers

The old school method of simply setting up your customers with an account to your web or mobile app and then sending them an invoice is still completely valid. In fact, we often recommend this to customers who have only a few (1000 or less) customers and whose apps sell for larger amounts ($5,000 or more per year).

If you’re collecting $50,000 from 100 customers, there is no reason to give up 2-3% to the credit card processing companies or gateway+merchant processors like Stripe and Paypal. Simply send the customers an invoice. This is particularly true if your customers are blue-chip types with whom you have a good relationship. You’ll notice there is no payment option on the Woodridge website or those of most custom software development companies.

Another situation where this is a great option is when you’re just starting out. Your pricing model is not proven. Will your subscription idea work or will your customers prefer a one-time license? Maybe you need to charge your customer’s customers, not the customer directly. You can save development costs by starting out with a straightforward traditional invoicing plan. However, you do want your development team to be aware of the different pricing models you’re considering, so when/if you do go with taking payments via the app, your app is built to support it.

Summary

If you made it this far, you can see that there are trade-offs with each of the methods for getting money from your customers’ bank accounts into yours. Decisions on how to collect these payments are important and can make or break your app’s success.

It’s important to work with a partner who is able to support multiple payment methods. I’ve seen development shops have their “favorite” payment method and then force all apps they build into it. You need a partner that’s flexible and will do what’s right for your app. Things change. Often, you may think one option is the best when you first plan your app, only to find another option is the one your customers prefer. The right development partner will be flexible and build an app that can change with you and your customers. Regardless of the payment method chosen, it’s key that the user experience is smooth. Forgot Password needs to work, subscription notifications need to be timely and send users to the correct spot to renew. A perfect payment method will feel natural to your user base and encourage them to buy your app and that’s the real goal – creating an app that is successful and profitable.