How to integrate Stripe in an iOS app
The one Apple rule that decides whether you can use Stripe, how the integration works, and how to keep payments secure.
Short answer
You integrate Stripe in an iOS app using its official iOS SDK, and it is the right choice for selling physical goods and real-world services. The rule that matters most is Apple’s: Stripe is allowed for physical products and services, but digital content and subscriptions used inside the app must go through Apple’s In-App Purchase instead. The integration adds the Stripe SDK, creates payments securely on your own server, uses Stripe’s prebuilt payment screen, and is tested with test keys before going live.
The one rule that decides everything
Before any code, there is a single rule that determines whether you can use Stripe at all, and getting it wrong is the most common way payment features get an app rejected. Apple draws a firm line between physical and digital. For physical goods and real-world services, things delivered or performed outside the app, you must use an outside payment processor like Stripe, and you are not even allowed to use Apple’s system. For digital content and services consumed inside the app, such as paying to access features or subscribing to digital content, Apple requires its own In-App Purchase and does not permit Stripe.
This distinction, set out in Apple’s review guidelines, decides your whole approach, so settle it first. A shop selling products, an app taking bookings for a real service, a donation feature, or a food order all sell something physical or real-world, and therefore use Stripe. An app charging for a premium tier, selling in-app currency, or billing for digital content must use In-App Purchase. Some apps have both kinds and need both systems. Knowing which category each of your payments falls into is the foundation everything else is built on, and it is worth confirming before you write a line of integration.
Stripe or Apple In-App Purchase?
Because the choice is really about what you sell, it helps to see the two systems side by side. The table below compares them.
| Stripe | Apple In-App Purchase | |
|---|---|---|
| Use it for | Physical goods and real-world services | Digital content and subscriptions in the app |
| Apple commission | None | 15 to 30 percent |
| Who processes the payment | Stripe | Apple |
| Typical example | A shop, bookings, donations | A premium tier or digital subscription |
The table makes the trade clear, though remember it is not a free choice: Apple’s rules assign each type of product to one system. For what you are allowed to run through Stripe, the advantage is real, since you keep your margin apart from Stripe’s processing fee and pay Apple nothing. For digital goods, In-App Purchase is mandatory and its commission is the cost of doing business there. Our guide on whether you pay Apple’s commission on everything covers this split in more depth, but the short version is that Stripe is for the physical and real-world side of your app.
How to integrate Stripe
Once you know Stripe is the right tool for your payments, the integration follows a standard, well documented path. First, the Stripe iOS SDK is added to the app, giving it the code to talk to Stripe. Second, and most important, a small backend is set up: when a user wants to pay, your server, not the app, tells Stripe to create the payment and hands back only what the app needs to complete it. Third, the app shows Stripe’s prebuilt payment screen, which collects the card details safely, so you do not build or handle that sensitive part yourself.
That server step is the part non technical founders often miss, so it is worth stressing. The app itself should never create charges on its own or hold your secret Stripe key, because anything inside the app can be inspected by a determined person. Instead the sensitive decisions happen on your server, which the user cannot tamper with. A developer implements this, and the pattern is common enough that it is not exotic work, but it does need doing correctly.
To make the flow concrete, picture a customer buying a product in your shop app. They tap buy, the app asks your server to start a payment for that exact amount, and your server calls Stripe and returns a one time token to the app. The app then shows Stripe’s payment screen, the customer enters their card, and Stripe confirms the charge. At no point did the app decide the price on its own or see the raw card number, which is exactly the separation that keeps the payment trustworthy. If your app is payment heavy or handles money in a serious way, our overview of the cost of a fintech app covers the wider engineering that surrounds payments.
Keeping payments secure
Security in a Stripe integration comes down to a few clear principles, and following them keeps both your users and your business safe. The first is that raw card details never touch your systems: Stripe’s payment screen collects them directly, so your app and server only ever see a safe token, and Stripe handles the sensitive storage and compliance. This is one of the main reasons to use a processor like Stripe rather than trying to handle cards yourself, which would be far riskier and more demanding.
The second principle is that your secret Stripe key lives only on your server, never in the app. The app uses a publishable key that is safe to expose, while the secret key, which can actually move money, stays server side where users cannot reach it. Payments are created and confirmed through that server, so the app is never trusted to decide a charge on its own. Kept to these rules, a Stripe integration is genuinely secure, and the app holds no data that would hurt you if someone pulled it apart. Cutting corners here, by putting keys or charge logic in the app, is where security problems come from.
The integration checklist
To turn all of this into a concrete plan, the checklist below captures the steps of a clean Stripe integration in order.
| Step | What to do |
|---|---|
| Add the SDK | Install Stripe’s official iOS SDK in the app |
| Use a backend | Create payments on your server, not in the app |
| Prebuilt payment screen | Use Stripe’s payment sheet to collect cards |
| Test mode | Verify the whole flow with test keys first |
| Go live | Switch to live keys and monitor real payments |
The order matters because each step rests on the one before it. The SDK gives the app the tools, the backend makes payments secure, the prebuilt screen keeps card handling safe, and thorough testing with Stripe’s test keys, which simulate payments without real money, catches problems before customers ever see them. Only then do you switch to live keys and start taking real payments, watching closely at first. Skipping the test stage or the backend is where integrations go wrong, so treat the checklist as a sequence, not a menu.
Cost and when it is worth it
On cost, Stripe charges a per-transaction fee that varies by country and payment type, so check its current pricing for your situation rather than assuming a number. The point that matters for planning is that, for physical goods and real-world services, using Stripe means no Apple commission at all, so you keep your margin apart from that processing fee, which is usually much smaller than Apple’s cut on digital sales. For a shop, a booking service, or donations, this makes Stripe both the required and the economical choice. Put simply, on the physical and real-world side of your app, Stripe lets you keep almost all of what you charge, which is a meaningful difference from the digital side where Apple’s commission applies. That is one more reason to be clear from the start about which of your payments are physical and which are digital, because it shapes not only what is allowed but what you take home.
The honest limitation is that integrating Stripe is real development work, not a switch you flip, and it must respect Apple’s physical versus digital rule or risk rejection, so it is not something to improvise the day before launch. If your app sells physical products or real-world services and you want it built with Stripe correctly and securely, and published under your own Apple developer account, book a free call.
FAQ
Can I use Stripe in an iOS app?
Yes, for the right kind of payment. Apple allows Stripe and other outside payment processors for physical goods and real-world services, such as a shop, bookings, or donations. What you cannot use Stripe for is digital content or subscriptions consumed inside the app, which Apple requires to go through its own In-App Purchase. So Stripe is fully allowed when you are selling something physical or a real-world service, and not allowed when you are selling digital goods used in the app.
When must I use Apple In-App Purchase instead of Stripe?
When you sell digital content or services consumed within the app, such as paying to access premium features, in-app currency, or a subscription to digital content. Apple requires these to use its In-App Purchase system, which takes a commission. Physical goods and real-world services are the opposite: they must use an outside processor like Stripe and cannot use In-App Purchase. Getting this distinction wrong is a common cause of App Store rejection, so decide which category your product falls into early.
How does Stripe integration work in an iOS app?
At a high level, you add Stripe's official iOS SDK to the app, set up a small backend that creates each payment securely, and use Stripe's prebuilt payment screen to collect the card details. The app never handles raw card numbers or your secret key; those stay with Stripe and your server. You test everything with Stripe's test keys first, then switch to live keys to accept real payments. A developer handles the technical steps, but the shape is standard and well documented.
Is Stripe secure for handling payments?
Yes, when integrated correctly. Stripe handles the sensitive card data and the heavy security and compliance work, so your app never stores raw card numbers. The key rule is that your secret Stripe key must live only on your server, never inside the app, and payments should be created on that server rather than trusted from the device. Done this way, the app itself holds no sensitive payment data, which keeps both your users and your business safe.
How much does Stripe cost to use in an app?
Stripe charges a per-transaction fee on payments it processes, which varies by country and payment type, so check Stripe's current pricing for your case rather than a fixed figure. The important saving is that for physical goods and services, using Stripe means you pay no Apple commission, since that only applies to In-App Purchase. So a shop or service app keeps its margin apart from Stripe's processing fee, which is usually far smaller than Apple's cut on digital sales.