Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Follow the money: Best practices for adding mobile payments to your app

Erik Sherman Journalist, Independent
Adding mobile payments to your app may sound great, but making it work effectively and securely can be tricky.

Payments can be a key ingredient of your mobile strategy. If you already have an app, that means adding mobile payments to the software.

With the billions that both Google and Apple claim to have paid to developers, this sounds like a tempting—even obvious—choice. And it may be, but adding payment capabilities to an existing app can be much trickier than fashioning a pop-up form and some back-end code. And with some new regulations having come into force, the stakes are getting higher.

How it works

To enable payments, you need to understand the basics of how they happen. "You have your payment gateway and then you have your merchant account [with a payment processor,]" says Robert Brodie, CTO of digital commerce consulting and strategy firm SUMO Heavy. The gateway is effectively the API you call to charge a customer's payment card. The payment processor at which you have a merchant account actually processes the payment.

This is a two-part process for added security, although some processors have their own gateway. If you transmitted the credit card information directly to the processor, someone who intercepted the traffic could have everything they needed—the card number and access to the processing merchant account—to fully create a transaction.

There are variations on the process, depending on how you technically implement payments. Greg Goldfarb, CEO of Flint Mobile, which helps clients accept credit card payments through smartphones, calls a "happy path" (straightforward transactions) a company's attempt to obtain payment. But a "happy path" can also result in the payment being declined, some of the billing information being incorrect, or even the need to process a refund.

That's where "things can get a little more complicated from a user interface and workflow point of view," he says. "There are a number of scenarios that the developer needs to anticipate and handle." For example, different decline codes mean different things, and handling a direct billing to a customer is different from enabling payment for a third-party vendor and its customers.

Getting the details down right is important, even beyond the technology. You might have to learn a new language. "As a programmer, I don't think in terms of authorizations and transactions," says Jerry Pickering, technical director at e2k. "All of a sudden there's this new nomenclature of what I'm attempting to do. You're telling this financial institution that you'll give it valid information, so it only helps if you appear if you have some idea what you're talking about."

Right planning

The mechanics of how payment systems work dovetail with the initial planning that a cross-functional team must complete before developers start coding. Adding payment capabilities can mean "completely different things," Goldfarb says. "One of the core questions is whether your app is really an app that consumers download, or is it an app that businesses download?" In other words, are you looking to sell something directly to the app users, or are you enabling another company to process payments from its customers?

That first decision influences all the others. "For the latter, you have to handle offline payments [when the phone doesn't have a data connection] and maybe invoice-based billing or online bill pay," Goldfarb says. The former means you'll primarily deal with e-commerce transactions that can be simpler to manage as your company has the control over which process and payment service providers to use. "The whole account structure and risk is completely different [between the two]," he says.

Once that is clear, you need to make other decisions based on the company's business model and expectations for the app. For example, if you want to sell virtual goods and are doing so through an iOS app, "[y]ou have to use in-app purchases and they're going to take a 30 percent cut," says Jen Looper, a developer advocate at Telerik. "If you're trying to sell physical goods [through an iOS app], you can use other strategies." Android, on the other hand, has more flexibility in handling payments, which don't have to occur through Google.

Other business considerations affect the technical plans as well. "Are you trying to move customers that are solely purchasing based on discounts to loyal customers, or are you trying to get loyal customers to buy more on mobile?" asks Scott Hutchinson, technical lead at Copper Mobile, an enterprise mobile app development company. Depending on the answer, you might have to consider loyalty functions and promotions, not payment in isolation.

Security and liability

Security for any app is important and has always become increasingly so when payments are involved. Now the imperative is stronger than ever before due to recent regulatory changes. It used to be the case under US statutes that if a fraudulent transaction occurred, the banks were responsible for the loss, absolving the consumer from all but perhaps a token portion of the total loss.

That's no longer the case. You've likely read about the switch from swipe-and-sign credit card use to EMV, which stands for EuroPay, MasterCard, and Visa. This is the payment card technology with embedded chips holding encrypted security information that has been in use elsewhere in the world for years, the purpose of which is to make it harder to commit credit card fraud.

But with the change in technology comes a shift in legal liability. Up until now, it was the credit card issuer that held legal liability under the law for fake card transactions. Now the onus is on whoever didn't enable an EMV transaction, whether the merchant or the issuer.

"If you're trying to accept a payment, and it's not through a secure way, and it winds up getting hacked, you're liable," says Wendell Adams, CEO of AB Mobile Apps, which creates cross-platform apps for clients. If something goes wrong—such as the data disasters that occurred at Target and Home Depot—the results can be terribly costly.

Keeping a handle on security means enforcing some strict practices. "We have a security checklist for mobile apps that's specific to mobile apps," Hutchinson says. The test of the apps is based on asking how much damage could be done if someone left an unlocked phone at a bar. For example, making a purchase should require separate password entry. Copper Mobile has testing software to look for issues like a gateway API key being hard-coded into the app. "Cracking them takes about five seconds," he says.

There's an acute need to keep current with security practices and requirements. "As of June 2016, SSL is no longer a viable transport for API calls for payment gateways," Brodie says. Instead, it will have to be TLS.

An app also has to be aware of the current state of the device on which it runs. "There's a typical decision about root protection and jailbreak protection," says Winston Bond, European technical manager for Arxan Technologies. "Some payment providers don't want [to deal with] a jail[broken] device."

Platform, or roll your own?

The business needs, planning, and security concerns of each app help inform the technical choices. Copper Mobile deals with large clients with existing e-commerce systems. "A lot of people we deal with have customer e-commerce platforms," Hutchinson says. "I would say 80 to 85 percent of the apps should and probably can use a [third-party mobile commerce] platform. The other 15 to 20 percent are enterprises, and the main reason they don't use a platform is just because of the cost."

A platform charges a percentage of the transaction as a fee. A common amount is 2.9 percent. So there's a fairly straightforward calculation the company has to perform: At what point does the percentage of annual sales reach the cost of the additional developers, security experts, and other specialized personnel and related overhead expenses? Typically, a mobile sales volume reaching the $50 million to $100 million range can be enough where maintaining the entire payment system internally becomes financially advantageous.

If supporting the team necessary for such systems is impractical, then there's likely a preexisting payment platform that will do the trick. "There are a bunch of really good SDKs out there that are looking to make this easy," says Jitendra Gupta, head of product and strategy for Punchh, which develops branded loyalty apps for restaurant brands.

Skyjet, which has a platform for booking private charter flights, wanted to add mobile payment. It already had a back end integrated with a major payment processor that was also authorized by Apple Pay. So Skyjet commissioned consultancy ArcTouch to integrate Apple Pay into the app.

"This was very easy for us," says Paulo Michels, ArcTouch's vice president of engineering. "As long as you work with one of the authorized gateways and you don't try to create everything yourself, it's a very easy situation for developers." Android Pay would be Google's equivalent that, according to Michels, has largely the same capabilities.

Getting it right

There are many other choices out there—Braintree (owned by PayPal) and Stripe are two of the most common. But just as important as the technical capability to submit a payment is managing the entire process within the context of the app without making it so complex or buggy that users delete the software.

Adding mobile payments to your app may seem simple in some respects. But managing all the issues, from business intent to security concerns and technology implementation, all while keeping the entire app easy to use isn't easy by any stretch of the imagination.

Keep learning

Read more articles about: App Dev & TestingApp Dev