The Stripe iOS SDK make it easy to collect your users' credit card details inside your iOS app. By creating tokens, Stripe handles the bulk of PCI compliance by preventing sensitive card data from hitting your server (for more, see our article about PCI compliance).
We also offer seamless integration with Apple Pay that will allow you to securely collect payments from your customers in a way that prevents them from having to re-enter their credit card information.
Our SDK is compatible with iOS apps supporting iOS6 and above. It requires XCode 6.1 and the iOS8 SDK to build the source.
We've written a guide that explains everything from installation, to creating payment tokens, to Apple Pay integration and more.
There are 3 example apps included in the repository:
- Stripe iOS Example (Simple) shows how to use STPPaymentPresenter to really easily obtain your user's payment information with Apple Pay. When Apple Pay isn't available on the device, it'll use Stripe Checkout instead. It uses a small backend to create a charge. The app is written in Swift.
- Stripe iOS Example (Custom) demonstrates 3 different ways of collecting your user's payment details: via Apple Pay, via Stripe Checkout, and via your own credit card form. It also uses our ApplePayStubs library to demonstrate how the Apple Pay flow appears in the iOS simulator (normally Apple Pay requires a device to use). It, too, uses a small example backend to make charges.
- Stripe OSX Example demonstrates how to use Stripe Checkout inside a native Mac app.
Note: all the example apps require Xcode 6.1 to build and run.
Before you can run the app, you need to provide it with your Stripe publishable key.
- If you haven't already, sign up for a Stripe account (it takes seconds). Then go to https://dashboard.stripe.com/account/apikeys.
- Replace the
stripePublishableKey
constant in ViewController.swift (for the Simple app) or Constants.m (for the Custom app) with your Test Publishable Key. - Head to https://github.com/stripe/example-ios-backend and click "Deploy to Heroku" (you may have to sign up for a Heroku account as part of this process). Provide your Stripe test secret key for the STRIPE_TEST_SECRET_KEY field under 'Env'. Click "Deploy for Free".
- Replace the
backendChargeURLString
variable in the example iOS app with the app URL Heroku provides you with (e.g. "https://my-example-app.herokuapp.com")
After this is done, you can make test payments through the app (use credit card number 4242 4242 4242 4242, along with any cvc and any future expiration date) and then view them in your Stripe Dashboard!
- Open Stripe.xcworkspace
- Choose the "iOS Tests" or "OSX Tests" scheme
- Run Product -> Test
Before version 3.0, most token-creation methods were class methods on the Stripe
class. These are now all instance methods on the STPAPIClient
class. Where previously you might write
[Stripe createTokenWithCard:card publishableKey:myPublishableKey completion:completion];
you would now instead write
STPAPIClient *client = [[STPAPIClient alloc] initWithPublishableKey:myPublishableKey];
[client createTokenWithCard:card completion:completion];
This version also made several helper classes, including STPAPIConnection
and STPUtils
, private. You should remove any references to them from your code (most apps shouldn't have any).
Versions of Stripe-iOS prior to 1.2 included a class called STPView
, which provided a pre-built credit card form. This functionality has been moved from Stripe-iOS to PaymentKit, a separate project. If you were using STPView
prior to version 1.2, migrating is simple:
-
Add PaymentKit to your project, as explained on its project page.
-
Replace any references to
STPView
with aPTKView
instead. Similarly, any classes that implementSTPViewDelegate
should now instead implement the equivalentPTKViewDelegate
methods. Note that unlikeSTPView
,PTKView
does not take a Stripe API key in its constructor. -
To submit the credit card details from your
PTKView
instance, where you would previously callcreateToken
on yourSTPView
, replace that with the following code (assumingself.paymentView
is yourPTKView
instance):if (![self.paymentView isValid]) { return; } STPCard *card = [[STPCard alloc] init]; card.number = self.paymentView.card.number; card.expMonth = self.paymentView.card.expMonth; card.expYear = self.paymentView.card.expYear; card.cvc = self.paymentView.card.cvc; STPAPIClient *client = [[STPAPIClient alloc] initWithPublishableKey:publishableKey]; [client createTokenWithCard:card completion:^(STPToken *token, NSError *error) { if (error) { // handle the error as you did previously } else { // submit the token to your payment backend as you did previously } }];
See StripeError.h for a list of error codes that may be returned from the Stripe API.
You have a few options for handling validation of credit card data on the client, depending on what your application does. Client-side validation of credit card data is not required since our API will correctly reject invalid card information, but can be useful to validate information as soon as a user enters it, or simply to save a network request.
The simplest thing you can do is to populate an STPCard
object and, before sending the request, call - (BOOL)validateCardReturningError:
on the card. This validates the entire card object, but is not useful for validating card properties one at a time.
To validate STPCard
properties individually, you should use the following:
- (BOOL)validateNumber:error:
- (BOOL)validateCvc:error:
- (BOOL)validateExpMonth:error:
- (BOOL)validateExpYear:error:
These methods follow the validation method convention used by key-value validation. So, you can use these methods by invoking them directly, or by calling [card validateValue:forKey:error]
for a property on the STPCard
object.
When using these validation methods, you will want to set the property on your card object when a property does validate before validating the next property. This allows the methods to use existing properties on the card correctly to validate a new property. For example, validating 5
for the expMonth
property will return YES if no expYear
is set. But if expYear
is set and you try to set expMonth
to 5 and the combination of expMonth
and expYear
is in the past, 5
will not validate. The order in which you call the validate methods does not matter for this though.