Integrating Payments in Mobile Apps: Stripe, Apple Pay, and Google Pay

Payment integration is where mobile development meets financial regulation, platform policy, and user trust. Getting it wrong costs you money through failed transactions, chargebacks, and users who abandon checkout. Getting it right creates a checkout experience so smooth that users barely think about it.

I have integrated payments in apps handling everything from $5 service bookings to five-figure B2B transactions. The technical implementation is straightforward, but the decisions around it are not.

Understanding the Rules

Before writing any code, understand the platform policies that constrain your options.

Apple requires in-app purchases (IAP) through StoreKit for digital goods and services consumed within the app — subscriptions, virtual currency, premium content, feature unlocks. Apple takes a 30% commission (15% for small business and subscription renewals after year one). You cannot use Stripe or any external payment processor for these transactions.

For physical goods and services delivered outside the app — food delivery, ride-sharing, physical products, professional services — you can use any payment processor. This is where Stripe, Apple Pay, and Google Pay come in as payment methods through your own checkout flow.

Google Play has similar rules but has been more flexible with alternative billing in some markets due to regulatory pressure. The specifics vary by region, so check the current policies for your target markets.

If your app sells both digital content and physical services, you may need both IAP and a direct payment processor. Design your payment architecture to handle both from the start.

Stripe Integration

Stripe is my default payment processor for mobile apps selling physical goods or services. The SDK is well-designed, the documentation is excellent, and the server-side API handles the complexity of payment processing.

The architecture follows a client-server pattern. Your mobile app never handles raw card numbers. Instead:

1. Your backend creates a PaymentIntent with the amount and currency
2. Your mobile app receives the PaymentIntent's client secret
3. The Stripe SDK collects payment details and confirms the payment
4. Your backend receives a webhook confirming the payment status

Use @stripe/stripe-react-native for React Native. It provides prebuilt UI components — PaymentSheet is the fastest integration path. PaymentSheet handles card input, validation, saved payment methods, and Apple Pay / Google Pay as payment methods, all in a single modal.

For a custom checkout UI, use the Stripe SDK's lower-level APIs to create your own card input form. This gives you design control but means you handle more edge cases — card validation, error display, loading states during processing.

Server-side, build your payment API with idempotency keys for every payment creation request. Mobile networks are unreliable, and a retry after a timeout should not create a duplicate charge. Stripe's idempotency mechanism prevents this, but you must include the key. The API design principles that apply to general API development are especially critical for payment endpoints.

Apple Pay and Google Pay

Apple Pay and Google Pay are not alternative payment processors — they are payment methods that sit on top of your payment processor. They tokenize the user's saved cards and provide the token to Stripe (or whatever processor you use) for the actual charge.

The user experience benefit is significant. Instead of typing a 16-digit card number on a small screen, the user authenticates with Face ID or fingerprint and the payment is done. Conversion rates for Apple Pay checkouts are consistently higher than manual card entry.

Stripe's PaymentSheet supports both Apple Pay and Google Pay out of the box. Enable them in your Stripe dashboard, add the configuration to your mobile app, and they appear as payment options alongside card input. For most apps, this is all you need.

For Apple Pay specifically, you need a Merchant ID configured in your Apple Developer account and the Apple Pay capability added to your app's entitlements. In Expo, this is handled through app.config.ts with the appropriate plugin configuration.

Test Apple Pay and Google Pay on real devices. The emulator and simulator do not support biometric payment authentication, so you need physical hardware for end-to-end payment testing.

Handling the Edge Cases

Payment integration has more edge cases than most features because money is involved and errors have real consequences.

Failed payments need clear, actionable error messages. "Payment failed" is not helpful. "Your card was declined — please try another card or contact your bank" gives the user a path forward. Stripe's error codes map to specific failure reasons — insufficient funds, expired card, fraud suspicion — and your UI should translate these into user-friendly messages.

Refunds should be automated through your backend when possible. Build a refund endpoint that calls Stripe's refund API and updates your order records atomically. Manual refunds through the Stripe dashboard work for small volumes but do not scale and are error-prone.

Webhooks are essential for payment state management. Do not rely on client-side payment confirmation alone. The mobile app might crash, lose network, or be closed during payment processing. Your server should listen for Stripe webhooks — payment_intent.succeeded, payment_intent.payment_failed, charge.refunded — and update your records accordingly. The webhook handler is the source of truth for payment status.

Subscription management adds another layer of complexity. Users expect to manage subscriptions from within the app — upgrade, downgrade, cancel, view billing history. Building this with Stripe's subscription billing requires handling proration, billing cycle changes, and the interaction between Stripe subscriptions and app store subscriptions if you support both.

PCI compliance is simplified by Stripe's architecture — since your servers never handle raw card numbers, your PCI scope is minimal (SAQ-A). But you must still protect API keys, use HTTPS for all communication, and follow security best practices for storing Stripe customer IDs and payment metadata on the device.

Payments are one of those features where getting it 95% right is not good enough. The 5% of edge cases represent real money and real user trust. Invest the time to handle every failure mode gracefully, test with real transactions (Stripe's test mode is excellent for this), and monitor payment success rates in production as a critical business metric.