Designing an iOS Payments SDK for Security

WePay iOS Server Calls

At WePay, we think about security as our most important product. Security isn’t a background concern - it’s the product that has to be absolutely, 100% solid before any other products can be shipped. That philosophy has guided us towards figuring out the right way to construct an iOS SDK for the WePay API

Since releasing the WePay API in 2011, we’ve received continual requests to make integrating the WePay API into a mobile application even easier. The WePay API has always been language agnostic - companies have baked it into their iOS apps for quite some time. Our foremost concern has been developing an iOS SDK that enforces security best practices.

The challenge

There are two major security challenges with a payments-related iOS SDK. The first is the threat that an app developer will inadvertently store sensitive information within the app’s source code. A person with malicious intent could access this information via a jailbroken iPhone and impersonate the app’s original developer when communicating with WePay. The second major challenge is making sure that an app doesn’t have to store credit card details on its servers for any length of time. Even temporarily storing credit card information triggers all kinds of PCI compliance requirements that our customers shouldn’t be forced to adhere to.

So, the challenge is basically to design an SDK where developers don’t have to store either their WePay credentials within the app’s source code or their customers’ credit card information within their servers.

The solution

The eventual solution basically borrows the same architecture as WePay’s web-first tokenization method - wepay.js. WePay’s javascript tokenization process is based on the standard MVC framework. You can accept credit card information through a form on your page and send it immediately to WePay. Without charging or authorizing the card, WePay returns you a token, which you can then send to your servers.

Once you’ve got a token, you can start making calls to WePay that actually charge or authorize the card. Since these calls generally require identifying yourself through private keys, you can make them from your server, using sensitive information stored there.

The iOS SDK works the same way, but instead of relying on wepay.js to exchange credit card information for a secure token, you just have to rely on the SDK. It encourages you not to store your API keys within the app’s code - we want to make it easy to keep them on a secure server.