The Payment Integration Playbook: What Actually Works

After implementing payment systems in multiple mobile apps over the past two years, from fitness booking platforms to SaaS products, we have seen the same assumptions cost clients time and money.

Here’s what actually matters when you’re building payments into your app.

The Mistakes We See Too Often

1. “We’ll figure out payments later”

Every founder wants to validate the idea first. Makes sense.

But here’s what happens: You build the entire app flow, onboard beta users, get great feedback. Then you bolt on Stripe, and realize your whole user journey needs restructuring.

Why? Because you didn’t account for:

• Failed payment retry logic
• Subscription state management
• Grace periods when cards expire
• The difference between trial users and paying users

Start thinking about payment flows from day one. Not implementation – just the business logic. How do users become paying customers? What happens when payment fails? When do you restrict features?

2. Treating all payments the same

We built a fitness app where users book real-world training sessions. Client initially wanted RevenueCat because “everyone uses it for subscriptions.”

RevenueCat is excellent for digital products. But we were selling physical services – sessions that happen in gyms with real trainers.

RevenueCat makes sense when you’re selling digital products through App Store/Play Store. If you’re selling anything that happens outside the app (bookings, physical goods, real-world services), you need direct Stripe integration.

The difference:

• RevenueCat: In-app purchases, managed by Apple/Google, 15-30% commission
• Stripe: Direct payment processing, 2.9% + 30¢, full control

We switched the project to Stripe. Client saved 12-27% in fees per transaction.

3. No strategy for failed payments

“Why are our paying users suddenly locked out?”

Because their card expired and nobody handled it.

Failed payments happen constantly. Cards expire. Banks flag transactions. Users hit spending limits.

Apps that don’t handle failed payments lose 20-40% of subscribers unnecessarily.

What we implement:

• Automatic retry logic (Stripe does this, but you need to handle it in-app)
• Email notifications before card expires
• Grace period (3-7 days) before restricting access
• Easy in-app card update flow

Users appreciate the heads up. Churn drops significantly.

The numbers we’ve seen:

In one app, before implementing proper failed payment recovery:

• 32% of payment failures resulted in permanent churn
• Average recovery time: never (users just left)

After implementing dunning (automated payment recovery):

• 68% of failed payments recovered within 7 days
• Saved roughly $15K MRR for a mid-sized app

The recovery sequence that works:

Day 1 (payment fails): Email + in-app notification “Payment failed – please update your card”

Day 3: Second email “You have 4 days left to update payment”

Day 5: Final reminder “Access ends in 2 days”

Day 7: Restrict access but don’t delete account

Most users update their card within first 3 days if you make it easy. Don’t immediately lock them out. Don’t make them create a new account. Just make the update button obvious.

What Actually Works

Match your payment solution to your product type

This is critical and often overlooked.

Real example: We built a personal trainer booking app. Initial plan was RevenueCat because “it handles subscriptions.”

But think about what users were buying: 60-minute sessions with real trainers in physical gyms. Not digital content. Not features unlocked in the app.

With RevenueCat, Apple would take 15-30% of every booking. For a $50 training session, that’s $7.50-15 going to Apple for… what exactly? Processing a payment for a service that happens entirely outside their ecosystem.

We switched to Stripe. Client kept that 15-30%. Trainers got paid more. Users paid the same.

The decision tree we use:

• Are you selling digital goods consumed in the app? → RevenueCat + In-App Purchases
• Are you selling anything that exists outside the app? → Stripe direct

Apple Pay isn’t optional on iOS

We added Apple Pay to a subscription app targeting US users.

Conversion rate on iOS jumped 40%.

Not “a bit better.” Forty percent.

iOS users expect Apple Pay. When they see a checkout form asking for card details, many bounce. Apple Pay is two taps. No typing. Face ID. Done.

The implementation? Two lines of code if you’re using Stripe.

If you’re targeting US market and skipping Apple Pay, you’re leaving money on the table.

Payment preferences: US vs Europe

This matters more than you’d think.

US users:

• Expect Apple Pay / Google Pay
• Comfortable with credit cards
• High adoption of subscription services
• Want instant access

European users:

• More privacy-conscious about payment data
• Higher preference for SEPA direct debit (especially in Germany)
• Want to see exact charges in their local currency
• More likely to scrutinize subscription terms

We built an app for both markets. In the US, 67% of iOS users chose Apple Pay. In Germany, 52% wanted SEPA direct debit.

The takeaway: Don’t assume one payment method works everywhere. Match your payment options to your target market.

For US-focused apps, Apple Pay is critical. For EU apps, especially in DACH region, offer SEPA alongside card payments.

The discount system nobody talks about

Client wanted a loyalty program. Users earn points, redeem for free subscription months.

Sounds simple. In practice: How do you apply points to Stripe subscriptions? Stripe doesn’t have a “points” concept.

We solved it with webhooks and coupon codes.

The flow:

1. User accumulates points in app database
2. When redeeming, app generates unique Stripe coupon (100% off for one month)
3. Apply coupon to their subscription via Stripe API
4. Webhook confirms application
5. Update points balance in database

Not trivial. Took us a few days to get right. But now it’s a pattern we reuse across projects.

The key insight: Stripe coupons are incredibly flexible. One-time discounts, recurring discounts, percentage or fixed amount, expiration dates. Most discount logic you need is already built into Stripe.

Subscription changes that don’t confuse users

“Can users upgrade or downgrade their plan?”

Yes. Stripe handles this automatically through proration.

Proration means: If user upgrades mid-cycle, they pay the difference immediately. If they downgrade, they get credit applied to next billing.

Stripe calculates this. You just call the API to change subscription tier.

Where teams mess up: Not explaining this to users.

We show a clear preview:

• “You’ll be charged $15 today (prorated for 12 days remaining)”
• “Your next bill on Feb 15 will be $40”

Transparent. No surprise charges. No angry support emails.

The UI pattern that prevents support tickets:

When user clicks “Upgrade to Pro”:

Simple. Clear. User knows exactly what happens.

Downgrade timing strategy:

For downgrades, we always apply the change at the end of the current billing period, not immediately.

Why? User already paid for the month. Let them use what they paid for. Apply downgrade when their next bill would come.

This feels fair. Users appreciate it. Some even change their mind and stay on the higher tier because you weren’t aggressive about it.

Trial periods that convert

Standard trial mistake: Ask for credit card, start trial, never remind user it’s ending, charge them unexpectedly, get angry email.

Better approach:

• Require card for trial (reduces fake signups by 80%)
• Send reminder 3 days before trial ends
• Send reminder 1 day before trial ends
• Make cancellation obvious and easy

Webhook for trial ending:

Stripe sends an event 3 days before the trial ends. We catch it and send a reminder email to the user.

Users appreciate the reminder. They either cancel (which they were going to do anyway) or they stay because you were upfront.

Conversion rates improve when users feel in control.

The optimal trial length debate:

We’ve tested 7, 14, and 30-day trials across different apps.

• 7 days: High urgency, good for simple products where value is immediate
• 14 days: Sweet spot for most apps – enough time to build habit, not so long they forget
• 30 days: Works for complex products with learning curve, but conversion rates drop because users forget they signed up

For subscription apps, we default to 14 days unless there’s a specific reason to go shorter or longer.

One more thing about trials: Show users their trial status prominently in the app. A small badge showing “Trial: 5 days left” reminds them of the value and reduces surprise when billing starts.

The Real Challenge: Business Logic, Not Integration

Stripe integration itself? 2-3 days if you know what you’re doing.

The business logic around payments? 1-2 weeks.

What takes time:

• Webhook handling: Every Stripe event needs proper handling – payment succeeded, payment failed, subscription canceled, subscription updated
• State synchronization: Your database needs to match Stripe’s reality
• Edge cases: User cancels then immediately resubscribes. User changes plan twice in one day. User’s card fails but they update it before grace period ends
• UI for every scenario: Success states, failure states, pending states, grace period states
• Refund flow: How do you handle refunds? Full? Partial? Does it affect subscription status?

Refunds without losing customers

Refund request comes in. What do you do?

Bad approach: Issue refund, immediately lock user out, mark as churned.

Better approach:

1. Issue refund through Stripe (instant)
2. Keep their access until end of billing period they paid for
3. Send friendly email explaining what happened
4. Offer option to resubscribe at discount if it was a mistake

We’ve seen users refund by accident (clicked wrong button), then get locked out immediately. They’re frustrated. They don’t come back.

Refunds handled well can actually reduce churn. User knows they can trust you.

What This Means For Your Project

If you’re planning a mobile app with payments:

Budget 1-2 weeks for payment implementation, not “a few days.” Stripe integration is quick. The business logic, webhook handling, and edge cases take time.

Decide payment strategy before UI work. Will you use RevenueCat or direct Stripe? This affects your entire subscription management approach.

Plan for failed payments from day one. It’s not an edge case. It’s 20-30% of your payment volume.

Add Apple Pay if targeting iOS users. Two lines of code, 40% conversion boost. Why wouldn’t you?

Test the entire payment cycle. Sign up, subscribe, fail a payment, retry, upgrade plan, downgrade plan, cancel, refund. Every scenario needs to work smoothly.

The MVP Exception: When Simple Beats Perfect

For MVPs with limited budgets, we often recommend:

Start with Stripe Checkout (hosted pages) instead of custom payment forms.

Why? Because:

• Stripe handles the UI
• PCI compliance is their problem
• Apple Pay / Google Pay built in
• Works on mobile and web
• 1 day implementation instead of 1 week

The tradeoff: Less control over design and flow.

For MVP validating the business model? Usually worth it.

For production app with specific UX requirements? Build custom integration.

We’ve done both dozens of times. The choice depends on your stage and budget.

Ready to Build Payments Right?

We’ve built this into a repeatable process. When agencies partner with us for team extension, they get developers who’ve implemented Stripe across multiple apps, not juniors following tutorials.

Want to see how we structure payment systems? I can walk you through our webhook architecture and the business logic decisions we make for different use cases.

At Apps Value, we build Flutter and React Native applications with payment systems proven across real production apps. Modern technology, real business results.