Inside In-App Purchases: How They Really Work From Code to Checkout

Once you launch an app and see a “Subscribe for $9.99/month” or “Buy 100 Gems for $4.99” screen, you’ve entered the world of in-app purchases (IAPs). They’re the financial backbone of free-to-play mobile games, streaming services, and even utility apps. But beneath that simple button click lies a surprisingly complex system of store receipts, server-side validation, and economic psychology.

Here’s the truth: IAPs aren’t just about charging a card. They’re a marriage of platform rules, security protocols, and user behavior design. Let’s break down how they actually work from code to checkout.

The Three Flavors of IAP

Before diving into the mechanics, know that in-app purchases aren’t one-size-fits-all. Apple and Google categorize them into three types, and each behaves differently:

• Consumables: Single-use items that get used up (e.g., coins, extra lives, boosters). You can buy them repeatedly.
• Non-Consumables: Permanent unlocks (e.g., removing ads, a premium level pack). Once purchased, they’re tied to the user’s account forever.
• Subscriptions: Recurring payments for ongoing access (e.g., premium features, cloud storage, streaming). They auto-renew until the user cancels.

The platform handles the payment flow, but you as the developer must manage what happens after the money clears.

The Purchase Flow: Step by Step

When a user taps “Buy,” a dance starts between your app, the app store’s servers, and your own backend. Here’s the simplified version:

1. Product Request: Your app fetches a list of available products (with prices) from Apple/Google’s servers. You never store prices locally—they’re set in the store console.
2. User Initiates Purchase: Your app sends a purchase request to the store. The store handles the payment UI and authentication (Face ID, Touch ID, or password).
3. Store Confirms: The store returns a receipt (a cryptographically signed JSON blob) to your app. This receipt contains details: product ID, transaction ID, date, and a unique identifier for the user.
4. Client Receives Receipt: Your app gets the receipt data. This is where many developers make a critical mistake.

Why Client-Side Validation Is a Trap

The biggest rookie error is trusting the receipt on the user’s device. A hacked app or a jailbroken phone can spoof receipts to pretend a purchase happened. This is why server-side receipt validation is non-negotiable.

The secure flow looks like this:

• Your app sends the receipt to your own backend server (over HTTPS).
• Your server forwards the receipt to Apple’s or Google’s validation endpoint.
• The platform’s server returns the real purchase status—expired, valid, canceled, refunded.
• Your server then updates your own database (e.g., adding coins or extending the subscription).
• Your server tells the app: “Yes, this is valid. Go ahead and unlock.”

This ensures that even if a user modifies their device, your backend has the final say. It also protects against refunds: if Apple processes a refund later, your server can detect it during a periodic validation check and revoke access.

The Dark Art of Receipt Parsing

Receipts aren’t just proof of payment—they’re mini-data packages containing:

• Transaction ID: Unique per purchase. Duplicate detection is crucial.
• Original Purchase Date: Important for subscriptions and non-consumables.
• Expiration Date (subscriptions only): The key to knowing when to stop service.
• In-App Ownership Type: Whether the user bought it or got it via family sharing.

For subscriptions, you must check the latest_receipt_info field carefully. Apple’s receipt v2 even includes a pending_renewal_info array that tells you if a subscription is about to expire or was voluntarily cancelled. This lets you send “Your free trial ends tomorrow” push notifications.

The Economics of Pricing and Psychology

The technical side is only half the story. IAPs work because of deliberate design choices that exploit human psychology:

• Tiered Pricing: $0.99, $9.99, $99.99. The middle option often feels like the “best value” even if the math doesn’t support it.
• Currency Confusion: Selling “Gems” or “Coins” instead of dollars distorts perception. You lose track of real money spent.
• Scarcity Timers: Free-to-play games use “energy” systems that recharge over time. Buying energy skips the wait, leveraging impatience.
• Subscription Anchoring: Offering a $99/year tier next to $9.99/month makes the annual price seem cheaper (even if it’s not much).

These aren’t accidental. Platforms like Apple require you to state exactly what the user gets, but they don’t stop you from pricing in ways that maximize conversion.

The Thin Line Between Fair and Predatory

Not all IAPs are evil, but the line gets drawn at “whales”—users who spend thousands. Games like Candy Crush or Clash of Clans deliberately design progression to be frustrating without payments, then offer “time savers.” This is called pay-to-win and is legal but controversial.

Apple and Google have rules against misleading IAPs (e.g., a subscription that auto-renews without clear disclosure). But they rarely enforce against psychological tricks, only outright fraud.

What Every Developer Must Know Before Shipping IAP

• Test on Sandbox Environments: Both stores have test accounts that simulate purchases without real money. Use them religiously.
• Handle Edge Cases: What if the user buys an item while offline? The receipt still arrives, but you need to sync it later.
• Refund Support: Users can request refunds from Apple/Google directly (outside your app). Your backend must check receipts periodically to catch refunds and revoke access.
• Compliance With Store Rules: Apple takes 30% (15% for small businesses). Google takes 15-30%. Violating their policies (e.g., using your own payment system) gets your app removed.

The Double-Edged Sword of Subscriptions

Subscription IAPs are the holy grail for developers—they provide predictable recurring revenue. But they come with churn management. You must monitor expiration_intent (user cancelled) and grace_period (payment failure) fields in receipts. Apple’s subscription status URL lets you get real-time updates via webhooks.

A subscription that fails (credit card expired) enters a 30-day grace period on iOS. During that time, the user still has access. Your server must honor this—cancelling access early violates App Store Review Guidelines.

The Bottom Line

In-app purchases look simple on the surface, but they’re a multi-layered infrastructure of store APIs, receipt verification, database states, and user psychology. The developers who get it right are the ones who treat IAPs as a server-reliant system, not a client-side feature. Build a secure backend, validate every receipt, and always design for the possibility that a user tried to cheat the system. Then, maybe, slap a “Limited Time Offer” on your $99.99 pack—it just might work.