Two trends are converging in technology that are changing consumer expectations and creating a wealth of blue ocean opportunities: the rise of mobile devices and the "Uberization" of payments. Everybody understands that mobile devices are now ubiquitous, but what is the "Uberization" of payments?
Simply put, it's the ability for consumers to conveniently and directly transact with other consumers and services, in real-time. Think of TaskRabbit which lets you quickly find somebody to help you with an errand, or, of course, Uber which lets you hail and pay for a cab from your phone with no hassle. At their core, these services all enable effortless financial transactions between disparate parties via a mobile device. But when you are accepting¬†payments, on any device, you must secure your users' financial data and adhere to PCI compliance standards.
PCI compliance is a nasty bag of vague requirements and becoming PCI certified can takes months of work even for a company that specializes in storing and processing credit card data. So how do you correctly and securely develop a mobile application that touches financial data? Let's walk through some common scenarios when developing a mobile app for accepting payments and evaluate your options.
Handle and store card data directly
If your organization is already PCI certified, congratulations! A lot of work has already been done to secure your existing systems and you may be able to receive and store card data yourself. However, a mobile app that touches card data exposes you to additional scope. You now need to work with your QSA to bring the app and supporting services in compliance. You know that this can take a huge amount of time and effort. More likely your organization is not already PCI L1 compliant and wants to stay in compliance by minimizing scope wherever possible. You also want to be able to execute quickly on your concept. If so, the rest of this post investigates some more palatable options.
Existing mobile POSs
If you're looking for a generic way for accepting payments from consumers then you might want to consider a mobile point-of-sale app such as Square or PayPal Here. For a transaction fee (usually anywhere between 2.5% - 3%) you can begin swiping credit cards with negligible up-front cost and very little setup time.
This is a great option if you want to sell goods in a card-present environment such as a local marketplace or store. You don't have to worry about PCI compliance and you get funds deposited to your account in a day or two.
However, what you gain in ease of PCI compliance you lose in terms of brand and control. It's a Square or PayPal driven environment vs your own brand. If you want a branded payment experience, to distribute your own app, or operate in a card-not-present environment then these are not an option for you. Instead you should consider a gateway specific mobile component.
Mobile payment widgets
Many gateways offer mobile-specific libraries that make accepting¬†payments within a mobile app trivial. These libraries provide their own payment UI components making the implementation as close to a drag and drop as can be expected in a custom app.
Major gateways such as Stripe, Braintree/Venmo Touch and PayPal all offer robust mobile libraries that do much of the heavy lifting for you. If you're already using one of these gateways, or have yet to choose a gateway to process your payments, one that has a well-supported mobile SDK would be a good option. Card data is handled by their library, limiting your PCI compliance exposure and implementation effort.
There are only a few downsides to this approach: 1) You lose control of the UX since you're using the gateway widget's chosen look and feel and 2) Your stored payment information is locked into that one gateway, potentially constraining future provider decisions. If you're comfortable being a single-gateway merchant but want to provide a custom checkout experience or, in general, want greater control of the UX you will need to develop directly to the gateway's API.
All relevant gateways support some form of a direct API that allow you to transact with credit card data. Integrating with these payments APIs depends on the implementation and client library support and can be delightful in some cases, and downright frustrating in most. However, beyond the developer experience, the more limiting factor is that you are now responsible for card data since it now passes through your mobile app.
There are many concerns you need to be aware of when directly handling protected card data. The first is that you are now in scope for requiring PCI compliance. If you are merely passing through this card data to a gateway for long term storage you may only have to complete a PCI self-assessment questionnaire. There are also several security practices you should adhere to when developing a mobile app, including not bundling any secret passwords (such as gateway credentials or access secrets) with the app.
Mobile devices are inherently compromiseable and any sensitive data stored on them should be considered at-risk. This can greatly complicate a gateway integration if the gateway doesn't support an unauthenticated tokenization process that will let you store a payment method without requiring your API credentials for that specific step.
For example, collecting a credit card number with Stripe's iOS bindings doesn't require your secret API key, nor does Spreedly's add payment method API call require your access secret. These calls will hand back a token representing the submitted card which you can then use from a secure and authenticated environment (e.g., your server environment) to execute actual purchase transactions.
Many gateway APIs don't provide this segmentation between storing a card from an insecure environment and transacting with it from a secure environment. This is required when accepting payments from a mobile app and should be part of your decision process. Using a gateway's API directly allows you complete control of the UX at the expense of increased development complexity and gateway lock-in. This latter point, the lock-in, is actually more relevant than you might think. For instance, to circle back around to Uber, consider a mobile app that has work with 10 cab companies in your city. This requires the ability to work with each taxi company's merchant account which means you need to be able to operate across gateways. For this type of marketplace app you'll need to consider a multi-gateway provider such as Spreedly.
Multi-gateway mobile access
If you want to collect payment information in your mobile app in a way that doesn't lock you into a single gateway you'll want to take a look at Spreedly. Spreedly uses a common API on top of dozens of gateways to provide a consistent payment processing language to your app.
Spreedly chooses to provide its mobile support via a two-phased tokenize/transact API that allows you complete control of the UX. Integrating with Spreedly from a mobile app requires the same attention to security as going to the gateway API directly, but provides the peace of mind of non-vendor specific card storage and processing paired with a modern, mobile-compatible API.
Mobile payment considerations
There is no one best choice when it comes to choosing how to accept payments in your mobile app ‚it all depends on your technology and business requirements.
We've looked at a few different options, let's compare them side by side to give you a clearer view of what approach is right for you.
Though there may be some variance within each bucket, the general relationship between each option holds. For instance, the ease of implementation using a modern gateway's direct API can be much greater than using a poorly implemented and documented payment component. However, in general, it is more effort to integrate directly to a gateway's API than to drop-in their mobile-specific widget.
As with any decision, choosing how to best accept payments in your mobile app is a balancing act. There are several options, all that have their own pros and cons. We hope this post serves as a useful roadmap to that decision.