Apple Pay + Stripe SwiftUI Template: What to Know

What you sell decides how you charge

Before any code, one rule settles most of the confusion: what you sell decides which payment method you are allowed to use. Physical goods and real-world services, a meal, a haircut, a delivery, a ticket, can be charged with Apple Pay and a processor like Stripe. Digital goods and content consumed inside the app, a subscription, premium features, coins, unlocks, must use Apple’s in-app purchase through StoreKit, per the App Store Review Guidelines, with only narrow external-link exceptions. So an Apple Pay and Stripe template is the right starting point for a physical or service business, and the wrong one for selling digital content, where StoreKit is required.

Getting this right first saves a rejected build. Many apps reach for Stripe to avoid Apple’s commission on digital goods, and that is exactly the case Apple does not allow, so the method follows the product, not the preference.

How Apple Pay and Stripe fit together

For the cases where it applies, Apple Pay and Stripe are two halves of one flow. Apple Pay is a payment sheet that presents the user’s saved cards and authenticates with Face ID or Touch ID, then hands your app a tokenized payment, not the actual card number. Stripe is the processor that turns that token into a charge, usually through a payment intent created on your server, and it handles the card networks, fraud checks, and the money movement. Your app never sees or stores a card number, which is the point: card data lives with Apple and Stripe, not in your code.

That division also defines what you build versus what you integrate. You build the checkout screen and present the Apple Pay sheet; Stripe and your server do the processing. A template can give you the entire front end, but the server-side payment intent and your Stripe account are yours to wire.

The payment methods compared

The decision is mostly about what you are selling, and this is the shape of it.

Method	What it is for	Who takes a cut
Apple Pay with Stripe	Physical goods and real-world services	Stripe’s processing fee, around 2.9% plus a fixed amount
StoreKit in-app purchase	Digital goods and content used in the app	Apple’s commission on the sale
External purchase link	Narrow, entitlement-gated cases after recent rulings	Varies, and eligibility is restricted

Apple Pay with Stripe is the route for a physical or service business, and the Stripe pricing is a standard processing fee rather than a platform commission. StoreKit is non-negotiable for digital goods used in the app. The external-link route exists after recent legal changes but is narrow and eligibility-restricted, so it is not a general way around in-app purchase. Pick the row that matches your product, and the template follows.

What an Apple Pay and Stripe template needs

A complete checkout template is more than an Apple Pay button. It needs an order or cart summary that shows exactly what is being charged, the Apple Pay button styled to Apple’s guidelines so it is recognizable and approvable, a card-entry fallback for users without Apple Pay, handled through Stripe so no raw card data touches your app, and a clear confirmation. Around those sit the states a real checkout hits: processing while the payment intent confirms, a declined card, an authentication step like 3-D Secure, a network failure, and success. The processing and confirmation patterns are the same as an Adyen drop-in checkout, and the agent-driven wiring mirrors connecting a Lovable app to Stripe checkout.

A template that ships only the happy path is a demo. The declined card, the authentication challenge, and the retry are where a checkout earns trust and where most hand-built payment screens fall short.

Where to get a template the AI can build from

The fastest way to get a correct, compliant checkout from an AI agent is to hand it a real payment template rather than a prompt. A free VP0 Apple Pay and Stripe template provides the cart summary, the correctly styled Apple Pay button, the Stripe card-entry fallback, and the checkout states as a SwiftUI file with a machine-readable source page. When you paste that link into Claude Code or Cursor, the agent extends a checkout that already respects the Apple Pay button guidelines and keeps card data out of your app, while you wire your Stripe account and the server-side payment intent. That combination, a compliant template plus your own Stripe and server, is what turns a prompt into a checkout that passes review and works. The same template approach helps when adding payments to a Cursor-built app.

The states that make checkout trustworthy

A checkout feels safe when its states are honest and complete. Processing should clearly show the payment is confirming, not frozen, and should prevent a second tap that double-charges. A declined card needs a readable reason and an easy retry rather than a dead end. An authentication step like 3-D Secure should hand off and return cleanly, because a lost redirect mid-payment is alarming. And success should confirm exactly what was charged so the user is never unsure whether the payment went through. These states are also where compliance shows: the app presents and confirms, Stripe and the card networks move the money, and the card number never lands in your code.

Get these right and a physical-goods or services checkout feels as smooth as any major app. Skip them and even a working Apple Pay button feels risky at the moment money changes hands.

Key takeaways: an Apple Pay and Stripe template

• The product decides the method. Physical goods and services use Apple Pay and Stripe; digital goods use StoreKit.
• Apple Pay tokenizes, Stripe processes. The card number never touches your app, and a server payment intent does the charge.
• Style the Apple Pay button to guidelines. It has to be recognizable and approvable, not a custom button.
• The states carry trust. Processing, declined, authentication, and success are where checkout proves itself.
• Start from a compliant template. A free VP0 Apple Pay and Stripe template gives an agent the checkout to extend.

What to choose

For a physical-goods or services app, build checkout from an Apple Pay and Stripe template, because it keeps card data out of your app and gives you the button and states review expects, then wire your Stripe account and a server-side payment intent. For digital goods used in the app, use StoreKit instead, since Apple Pay and Stripe are not permitted there. A free VP0 Apple Pay and Stripe template gives an agent a compliant checkout to extend for the cases where it applies, so you spend your effort on the processing and the edge states rather than the layout. Match the method to what you sell, and the rest follows.

Frequently asked questions

Can I use Apple Pay and Stripe instead of Apple’s in-app purchase? Only for physical goods and real-world services. For those, Apple Pay with Stripe is allowed and common. For digital goods and content consumed inside the app, like subscriptions, premium features, or virtual items, Apple requires StoreKit in-app purchase, and using Stripe there will fail review, aside from narrow, entitlement-gated external-link exceptions. So the answer depends on what you sell: a physical or service business can use Apple Pay and Stripe, while a digital-goods app cannot avoid in-app purchase that way.

Where can I get an Apple Pay and Stripe SwiftUI template? The most reliable option is a payment-specific template you can hand to an AI agent, rather than a prompt. A free VP0 Apple Pay and Stripe template provides the cart summary, the correctly styled Apple Pay button, the Stripe card-entry fallback, and the checkout states, with a machine-readable source page, so Claude Code or Cursor extends a compliant checkout. You then wire your Stripe account and a server-side payment intent, since the template is the front end and the processing is yours. It suits physical goods and services, where Apple Pay and Stripe are permitted.

Does my app store card numbers with Apple Pay and Stripe? No, and that is the point. Apple Pay hands your app a tokenized payment rather than the real card number, and Stripe processes the charge through your server using a payment intent, so the actual card data lives with Apple and Stripe, not in your code. This keeps you out of the heaviest compliance burden of handling raw card data. Your responsibility is the checkout screen, the Apple Pay sheet, and the server call to Stripe, not storing or transmitting card numbers yourself.

What states does a checkout screen need to handle? More than a successful payment. A real checkout handles processing while the charge confirms, a declined card with a clear reason and retry, an authentication step like 3-D Secure that hands off and returns cleanly, a network failure, and a success state that confirms exactly what was charged. It should also prevent a double tap that double-charges. These states are where a checkout earns trust, and they are the first thing to check in any payment template, because a happy-path-only screen feels risky at the moment money moves.

Why does Apple reject apps that use Stripe for digital goods? Because Apple requires in-app purchase through StoreKit for digital goods and content consumed inside the app, so using an outside processor like Stripe for those sales violates the App Store Review Guidelines. Apple allows Apple Pay and Stripe for physical goods and real-world services, where in-app purchase does not apply, and recent rulings have opened narrow external-link exceptions, but those are restricted. The safest path is to match the method to the product: StoreKit for digital, Apple Pay and Stripe for physical and services.