Mobile Applications

Developing a native mobile application that uses Spreedly's orchestration layer to collect sensitive payment data can be challenging. There are a few approaches available.

Security considerations

Mobile applications that securely collect credit card information can require additional details to execute. By their nature, mobile devices can be compromised by their owner via methods like jailbreaking and brute-force attacks. In these situations, the app maintainer often has no ability to detect intrusions. Because of this limitation, data stored on the device should be considered open to compromise. No secret or password values should be stored by a mobile application, including Spreedly's access secrets.

Without an access secret on the mobile device, Spreedly requires:

Any payment methods added from mobile will be in the cached state, meaning it can be transacted against immediately but will be purged and made inactive after ~12 hours. These payment methods will need to be retained separately to be saved for future use from the secure backend environment.
Requests to process a payment cannot be sent directly from the mobile application, as these API calls generally require access secrets. Instead, the token of the added payment method must be sent to the server backend where the transaction can be executed against Spreedly's API. Since many mobile applications require some form of a supporting API, this is more of a procedural detail than a technical burden.

With these requirements in mind and depending on the mobile platform, gateway connections and desired UX, choose how to implement payment collection with Spreedly from the options below:

Approaches

If you want to...	Then use...	which...
Collect payment information in your iOS/Android app, minimize PCI scope in a mobile setting, and have full control over UI/UX	iFrame payment form or Spreedly Express	are mobile compatible, browser-based approaches to collecting payment information. This is the recommended approach for all Spreedly customers.
Implement a native iOS card collection	the iOS SDK	allows the submission of payment information directly to Spreedly from an Objective-C/Swift app.
Integrate an Android application	the Android SDK	allows the submission of payment information directly to Spreedly from a Java/Kotlin app

Note: The iOS and Android SDKs provide reference code demonstrating card tokenization using a "WebView" experience similar to how iFrame is embedded in the desktop browser user interface. The SDKs are not actively maintained nor supported at this time, but an improved solution for native iOS/Android is on our roadmap. To tokenize cards using a native GUI experience now, we recommend developing in-house or working with a design partner.