In-App Purchases and Subscriptions: A Founder Guide to App Billing

Adding payments to a mobile app sounds simple until you meet the details. Apple and Google each run their own billing systems, each with different product types, receipt formats, refund flows, and rules about what you can sell and how. Get it wrong and you may face rejected app reviews, lost revenue, or angry customers who paid but cannot access what they bought.

This guide gives founders a clear mental model of in-app purchases and subscriptions, the architecture that keeps them reliable, and the mistakes worth avoiding.

First, Decide What You Are Selling

Billing design starts with the product, not the code. Common models include:

• Auto renewing subscriptions. Monthly or yearly access that renews until cancelled. Best for ongoing value.
• Consumables. Items used up and bought again, such as credits, coins, or boosts.
• Non consumables. One time purchases that unlock something permanently, such as a feature pack or an ad free upgrade.
• Physical goods and services. Things consumed outside the app, such as food delivery or ride bookings, which usually use regular payment gateways instead of store billing.

The distinction between digital and physical matters. Store policies generally require platform billing for digital features and content consumed in the app, while real world goods and services typically do not. Because policies and regional rules evolve, verify the latest guidelines for each store and market before launch.

A Real-World Example

Take a hypothetical language learning app. It offers a free tier, a monthly premium plan, and a yearly plan with a discount. A user subscribes on an iPhone, later logs in on an Android tablet, and expects premium to be active there too.

A naive build stores "isPremium" locally after the purchase. On the tablet, nothing is unlocked, and support tickets pile up. A better build records every verified purchase on the backend, linked to the user account. The tablet app asks the server for the user's entitlements and unlocks premium immediately. When the user later cancels on the phone, the store notifies the backend, which keeps access until the paid period ends. The difference is simple: the server owns the truth, and the app only displays it.

The Architecture That Works

Reliable billing has four parts that work together.

1. Store products

Define your products and subscription groups in App Store Connect and Google Play Console. Keep product identifiers consistent across platforms and plan how you will add intro offers, free trials, or promotional pricing later.

2. The app client

The app presents prices, starts the purchase, and finishes the transaction. It should show localised prices from the store, never hard coded numbers, since currencies and taxes vary. Our guide to paywall design that converts covers how to present the offer well.

3. The backend

The server validates purchase tokens with the store, creates or updates the user's entitlement, and exposes it through your API. It also receives server to server notifications about renewals, cancellations, and refunds.

4. Entitlements

An entitlement describes what a user may access, with a status and expiry. Features check entitlements, not raw purchases. This lets you change pricing, add plans, or grant access through promotions without touching feature code.

Step by Step: Implementing Billing

1. Write the product catalogue. List plans, durations, trial rules, and what each unlocks. Decide whether you need monthly, yearly, or lifetime options.
2. Configure products in both stores. Set up agreements, tax and banking details, subscription groups, and test accounts. This administrative step often takes longer than expected, so start early.
3. Choose your approach. Use a billing platform to speed up development and unify iOS and Android state, or integrate store APIs directly for maximum control. Weigh cost, flexibility, and the maintenance burden.
4. Build the purchase flow. Fetch products, show localised prices, handle cancellation and pending states, and complete the transaction only after your backend confirms it.
5. Validate on the server. Send purchase tokens to your backend, verify them with the store, and store the result against the user's account.
6. Handle store notifications. Subscribe to server notifications for renewals, expirations, billing retries, refunds, and revocations. Update entitlements automatically.
7. Implement restore purchases. Provide a clear button that re-syncs access for users on new devices, as stores expect this.
8. Make it idempotent. The same notification may arrive twice. Processing it twice must not grant double credits. See our guide on idempotency keys for the pattern.
9. Test every state. Use sandbox and test tracks to simulate purchase, renewal, cancellation, refund, billing failure, and plan upgrade or downgrade.
10. Add analytics. Track trial starts, conversions, renewals, and churn so you can improve the offer over time.

Edge Cases That Cause Real Support Tickets

• Pending purchases. Some payment methods complete later. Do not unlock access until the purchase is confirmed.
• Billing retry and grace periods. When a card fails, stores keep trying for a period. Decide whether to keep access during the grace window, and message the user kindly.
• Refunds. The store can refund without your involvement. Your backend must react, or users keep premium for free.
• Family sharing and multiple devices. Plan how a single purchase maps to a user account or household.
• Account linking. If users can purchase before signing in, decide how to attach the purchase to an account later without losing it.
• Price changes. Stores have specific rules about notifying existing subscribers. Misusing them can lead to unintended cancellations.

Web Checkout and Alternative Payments

Many apps also offer web based purchases through a payment gateway, which can reduce fees and offer more flexible pricing. Store policies on linking out to web payments differ by region and have been changing, so treat this as a decision to revisit regularly with current rules in hand. If you support multiple purchase channels, your backend should merge them into one entitlement system so a user who pays on the web is recognised in the app, and vice versa. For India focused products, also consider local payment methods, as explored in our guide to UPI and wallet integration.

Key Benefits of Getting Billing Right

• Predictable revenue. Accurate subscription state means accurate reporting and forecasting.
• Fewer support tickets. Users whose purchases sync across devices rarely need to ask for help.
• Protection from fraud and abuse. Server side validation closes the easy loopholes.
• Flexibility to experiment. Clean entitlements make it easy to test pricing, trials, and bundles.
• Smooth app review. Following store rules reduces the risk of rejection at launch or during updates.

Mistakes to Avoid

Trusting the client

Any logic that grants premium access based only on what the app says can be bypassed. Always verify on the server.

Hard coding prices and plans

Hard coded values break when you add regions or change plans. Load products dynamically and drive features from entitlements.

Leaving cancellation unclear

Hiding how to cancel hurts trust and can violate store rules and consumer protection expectations. Be transparent about renewal terms and how to manage subscriptions.

Launching without monitoring

Watch for failed validations, missed notifications, and sudden drops in renewals. Billing bugs are quiet and costly.

Pricing and Trial Strategy

Technical correctness is only half the story. How you structure plans shapes how many people subscribe and stay. A few principles help:

• Offer a clear yearly option. Annual plans usually improve retention, since users commit for longer, and they bring cash in earlier. A visible saving against the monthly price makes the choice obvious.
• Use trials deliberately. A free trial lowers the barrier, but only helps if users reach value during it. Design onboarding so people experience the main benefit before the trial ends.
• Remind before renewal. A short notice before charging builds trust and reduces chargebacks and angry reviews.
• Test, do not guess. Run controlled experiments on price points and paywall copy rather than copying a competitor. What works for another audience may not suit yours.
• Localise prices. Purchasing power varies widely between markets, so regional pricing tiers can improve conversion in places such as India compared with a single global price.

For example, a team could compare two paywall versions across a few thousand new users and measure trial starts and paid conversions for each. Even a modest improvement compounds over time because every future cohort benefits from the better design.

Working With a Development Partner

Billing touches design, mobile code, backend, analytics, and legal considerations at once, which is why it is worth planning early. If you are building a subscription product and want a team that has handled these details before, explore our mobile app development service, or use the app cost calculator to estimate your scope.

Whatever you choose, keep a short internal runbook describing how purchases flow through the system. When a customer writes in about a missing subscription, support should be able to trace the purchase, check the entitlement, and fix the problem within minutes.

Conclusion

In-app billing rewards careful planning. Decide what you are selling, let the server own entitlements, validate every purchase, listen to store notifications, and test all the awkward states before launch.

Done well, billing fades into the background and your customers simply get what they paid for. That quiet reliability is what turns a good app into a sustainable business.

Frequently Asked Questions

Do we have to use Apple and Google billing for digital goods?

In most cases, digital content and features sold inside an app must use the platform's billing system, though rules differ by region and have been changing. Check the current policies for each store and market before designing your flow.

What is an entitlement?

An entitlement is your backend's record of what a user is allowed to access, such as a premium plan. It should be driven by verified purchase data, not by what the app claims locally.

Why do we need server side receipt validation?

Client side checks can be tampered with. Validating purchases and listening to store notifications on your server keeps access control accurate and protects revenue from fraud and refunds.

Should we use a billing platform like RevenueCat?

Many small teams do, because it handles receipt validation, cross platform subscription state, and analytics. Building in house gives more control but needs ongoing maintenance as store rules and APIs change.

How do we handle refunds and failed renewals?

Subscribe to store server notifications, update entitlements when a refund or expiry arrives, and use grace periods and billing retry states to recover users whose payment failed.