Whether your app is iOS, Android or web-based, selling products and services within your app requires back-end financial services integration.  This article provides a business-level overview and best practices for the back-end services you'll need when selling goods and services in-app. Here I'll focus on selling physical goods and services within an iOS or Android mobile app--but the basic concepts apply to selling services in a web application.

Using In-App Purchase vs. a Gateway + Merchant Account

When considering how to sell products or services in-app, the first question to ask is whether to use the in-app purchasing (IAP) APIs provided by Apple/Google or a traditional credit card processing platform. Fortunately this decision is made super easy by Apple and Google App Store rules.

• Are you selling a digital item, such as a downloadable app, app subscription payment, in-app currency (coins, loot boxes, etc.)?  If so, you must use Apple In-app purchase or Google Play Bililng Services. You may not use your own payment processing platform--except (at the time of this writing) if you're developing a dating app for iOS in Denmark.
• Are you selling a physical good or service that is consumed "in the real world", i.e. not consumed within a digital device--such as a printed book, a massage therapy session, or a food item?  In this case you must use a traditional payment processing platform--you may not use IAP to sell this item.

The remainder of this article discusses the second case -- the backend services that provide your app the ability to sell physical goods or services using traditional payment platforms.

How Does Payment Processing Work?

When selling physical goods and services, your app will leverage traditional payment processing platforms to accept credit cards, debit cards and other payment methods (e.g. PayPal or Apple Cash).

Complicating the implementation is that each payment method has its own back-end processing infrastructure.  Because it would be arduous and expensive for most retail sellers to integrate directly with all possible payment method providers, we use payment processors to facilitate payments from customers using these payment methods.

Payment Processing Components

When processing traditional payment methods for physical goods/services, a transaction involves multiple financial service provider components.

• Your App.  The purchase process begins when your customer presses the "pay now" button in your app (or on your web site).  At this point, your app and/or your back-end web services will begin talking to external financial service providers to authorize the payment and capture funds.
• Payment Gateway As mentioned above, the process of authorizing a payment, capturing funds from a customer's credit card (or bank account) and transferring those funds to your own bank account requires multiple steps. The Payment Gateway manages these steps on your behalf.  Your app only talks to the Gateway.
• Merchant Account. Your merchant account is essentially a bank account you open. It exists to serve as a short-term landing zone for funds captured from customers (or, in the case of a refund/charge-back, a source for funds to transfer back to customer accounts).
• Your Bank Account.  You want access to the revenue from in-app purchases, right?  When payment provider (Visa, etc.) and merchant account provider are satisfied that the funds your customer intended to send to you have arrived (or will arrive), those funds are transferred into your bank account for your use.  This transfer is typically automated on a predefined schedule.

What Payment Methods Can I Accept

A decision that's important to make at the beginning is which payment methods are to be supported.  Different gateways support different payment methods--if you decide to accept a payment method later that isn't supported by the gateway provider you selected initially, it may not be possible without changing to a new payment provider (or adding an additional one). Switching between gateways (or adding a second one) is time-consuming and expensive--it's important to choose wisely up front!

Examples:

• Virtually all gateway providers support Visa, MasterCard, American Express and Discover
• PayPal operates its own Gateway (BrainTree) and PayPal owns Venmo. If you want to support these payment methods, it's basically a requirement to choose BrainTree as your Gateway provider.
• Not all Gateways support Mobile Payments (Apple Pay, Google Pay, Samsung Wallet). If you intend to support these payment methods in mobile apps (and you should!), be sure your gateway provider supports mobile payments.  If you decide to add these payment methods later but your gateway doesn't support them--it could mean starting your payment integration over with a new gateway provider.

I can't emphasize enough to do great due diligence and requirement gathering on payment methods.

When is a Merchant Account Needed?

All credit card processing requires a merchant account to capture funds from the originating payment accounts (Visa, etc.) and escrow funds during finalization.

A merchant account has attributes of a bank accounts and a line of credit.  As such, you will need to apply for a merchant account, which may involve providing business/personal credit information. While I won't delve into the minutia of this process, this article by Jennifer Dublino on Business News Daily is a great primer on merchant accounts.

Funds deposited into your merchant account are typically not immediately available. Depending on the merchant account, funds may be distributed to your bank account at the end of the day or (more commonly) 2-3 days after funds are captured.

Because a charge-back or refund could occur after funds are transferred out of your merchant account, the merchant account  serves as a line of credit extended to you by the merchant account financial servicer, i.e. they may refund funds to a customer that are no longer immediately available in your merchant account, thus extending you credit.

Who Provides Merchant Accounts?

Merchant accounts are available from many providers. Often the same provider that provides gateway services will bundle a merchant account, There isn't a one best answer for who to use for your merchant account. What should you consider?

• Whatever merchant account is opened, it must be integratabtle with the selected payment gateway. Under most circumstances both of these services are provided as a bundle, but it's possible to use a gateway from one company and a merchant account from another--though doing so adds additional complexity to the solution.
• For new businesses or those with limited development budgets, Stripe can be a fantastic option. The onboarding for new companies and startups is easy and their development APIs are best in class--translating to a fast and efficient software development integration.
• As mentioned, if PayPal/Venmo are must-have payment methods, Braintree is probably the first choice, since these payment methods are not typically available with competing gateway providers.
• If your business has in-person Point of Sales systems (e.g. Square), then using a merchant account/gateway from the PoS provider will probably be the best choice--if available.
• If minimizing transaction fees is the top priority, it may be possible to shop around to other merchant account/gateway providers. Shaving a few basis points off your transaction fee structure will probably translate to more software integration and support costs, but if the volume of transactions flowing through the app is large enough, this can be worthwhile.

Transaction Fees

Accepting credit cards vastly streamlines the purchase process for consumers--and arguably increases sales by removing the friction of asking consumers to carry cash with them for any payment they make. However if you ask any small business what they don't like about accepting credit cards, the answer is invariably processing fees.

Processing fees vary depending on how a credit card is presented for a transaction to account for the risk to the card issuer:

• Cards presented in-person have the lowest rates
• Cards presented not in person but with verification of card possession (e.g. CVV digits) may have a lower rate than a card number without CVV digits.
• When a consumer provides billing address information, the risk is perceived as lower, and the rate may be lower
• A card read over the phone with no confirmation metadata has the highest risk and will typically have a higher transaction processing rate

Mobile App Transaction Fee Structures

For mobile apps, which are "card not present" transactions, many merchant account/gateway companies offer "flat rate" pricing--where the rate is the same no matter what payment method is presented by a customer.

Multi-Channel or Physical Transaction Fee Structures

If a business has a mix of card acceptance locations (physical store, web site, mobile app), it may pay different rates depending on where a sale is made.  And, as mentioned before, different providers may offer different rates--though lower rates may offer fewer features and less flexibility.

The bottom line to rates is they're tied mostly to risk. The card processor will price fees both by the perceived risk of how the consumer is presenting their card, as well as the risk profile of the merchant they're providing a merchant account/gateway service to.

Things that impact the rate you'll pay:

• Are sales made in a physical store, on a web site, in an app?
• How long has the business applying for the merchant account been in business? Does it have a favorable credit rating?
• What industry is the seller in? Does that industry have a high or low risk of credit card fraud?
• Does the business applying for the account have a history of charge-backs?

While transaction fees are a cost, they're also going to be a known cost--these fees are unavoidable in modern retail sales and must simply be built into the cost of sales calculation.

Gateway Only vs. All-In-One

Another determining factor in transaction cost is whether you opt for an "all in one" Gateway+Merchant Account plan (all in one), or purchase Gateway and Merchant Account services separately (gateway only).  While a "gateway only" service is less expensive--you'll still need to "bring your own merchant account" and then integrate the gateway service with your existing merchant account.

The "gateway only" services make the most sense when your business already has a merchant account and you're adding mobile app and/or web purchases to other, existing physical channels.  In some scenarios it could be advantageous to purchase gateway and merchant account services separately and then integrate them at the customer side.

PCI Compliance

Credit fraud has been a risk ever since credit was first extended--thousands of years.  As credit processing has moved online, the need to ensure handling of sensitive credit information such as credit card and consumer information has become critical.  Most readers of this article have probably had their credit information lost by a large retail organization--even the largest organizations have trouble ensuring the security of credit information.

To help ensure consumer credit information isn't mishandled, all credit card providers require those accepting credit cards to adhere to Payment Card Industry Data Security Standards.  PCI compliance can be complex and expensive (see this compliance document for details). Fortunately, with the right application architecture and service provider selections, organizations can outsource PCI compliance to their gateway provider.

How to minimize the cost of ensuring PCI compliance?

While every business accepting credit cards needs to have a PCI compliance plan, the key to reducing PCI compliance cost lies in the following quote from the PCI Security Standards document:

"Cardholder Data -- if you don't need it, don't store it."

In a modern mobile app, when the consumer enters their payment information, they enter it into the gateway's UI (e.g. a Stripe payment sheet). The app never sees the credit card number, and thus the gateway provider (Stripe in this example) is responsible for safeguarding the credit card number.  The gateway provides a single-use token to capture the payment.

Mobile Payments

Most apps allow users to enter in credit card information to provide payment for purchases made in-app.  To make purchases available to the most number of customers, of course we want to provide this option.  However, more and more consumers are using mobile payment services like Apple Pay and Google Pay, which streamline their experience even more.

Why Support Mobile Payments?

Mobile payments are becoming popular with consumers largely due to the security and convenience of using them vs. entering credit card digits. According to Bernstein as quoted in Quartz,  as of 2020 5% of global card transactions were Apple Pay, and they predicted that total would be 10% by 2025.

Mobile payments reduce friction for sellers as well.  During a presentation at 2020 WWDC, Apple reported in their studies sellers who implemented in-app Apple Pay saw conversion rates increase 30% compared with traditional credit card digit entry.  This makes sense given the friction involved in typing credit card numbers into a mobile keyboard is relatively high compared with biometric authorization for Apple Pay or Google Pay.

How do I support Mobile Payments?

More and more gateways provide out-of-the-box support for Apple Pay and Google Pay in their back-end processing.  Whether a consumer types a credit card number into their phone, or uses biometric authentication to authorize a mobile payment method, the payment gateway will provide the same authorization code to capture the payment, and the payment will be recorded in your sales system as a credit card payment corresponding to whatever payment method the user stored in their mobile wallet.

There is additional implementation in the mobile app to support mobile payments, and some gateway providers support mobile payments better than others.  With some, supporting Apple Pay can be a single line of code, for example--while with others you may need to fully implement mobile payments in the app UI yourself and make additional calls to the gateway.  It's always best to do a diligent evaluation of the payment integration complexity with a candidate gateway provider before committing to a gateway decision.

Summary

Consumers are preferring cashless payments--and even some merchants no longer accept cash. At the same time, the options for supporting in-app purchases have never been more plentiful or easier for app developers to incorporate in their apps. While digital goods must use Apple/Google in-app purchasing, physical goods and services must use more traditional credit card processing platforms. Which payment channel your company uses simply depends on what's being sold.

The first and most important step when integrating in-app payment for physical goods/services is selecting the most appropriate gateway and merchant account.  Often some or all of these decisions are pre-ordained (for example if the app we're building is extending a pre-existing e-commerce or point-of-sale system).  When making a "green field" selection of a gateway provider, we need to consider several factors in selecting the best provider.

• Fee structure
• Payment method support
• Mobile payment support
• Ease of integration with the selected application/platform technologies

Fortunately there is a wide range of financial services providers to choose from. A thorough understanding of requirements and assessment of business priorities can help hone in on the best choice.

At the end of the day the objective when providing in app purchase support is to drive sales and make it easier for customers to purchase our products and services. The wide scale availability and relatively easy implementation of in-app electronic purchasing has made it easier not only to facilitate user purchases--but also to clearly attribute those purchases to the app that drove the purchasing decision.  As more consumers rely on mobile apps as their preferred channel to interact with businesses, mobile purchases continue to let us meet customers where they want to be.