How to Set Up In-App Purchases

Understanding how to set up in-app purchases is a critical milestone for digital goods monetization. Whether you are developing for iOS, Android, or building a cross-platform solution, setting up in-app purchases involves configuring products in Apple App Store Connect and Google Play Console, integrating native APIs, and managing server-side receipt validation. This guide provides an enterprise-grade architectural blueprint to help business owners, product managers, and software engineers safely implement, secure, and scale in-app billing systems while ensuring absolute compliance with current store policies.

Understanding In-App Purchase (IAP) Models

Consumable vs. Non-Consumable Products

Consumable in-app purchases represent temporary items or utilities that a user drains through application usage and can buy repeatedly. Common examples include virtual currency, health points, extra attempts, or short-term processing credits. From an API design standpoint, once a consumable purchase succeeds, the application must explicitly instruct the platform billing framework that the product has been delivered. On iOS, using the modern Apple StoreKit API, you process transactions and mark them finished. On Android, the developer must invoke Google’s consumption routines. If the app fails to register consumption, the store prevents the user from purchasing that item again, assuming a delivery failure occurred.

Managing consumables requires a bulletproof transactional database ledger on your server backend. Because these items are consumed, their state is not retained by Apple or Google over multiple devices or reinstalls. If a user uninstalls the app and reinstalls it, or switches to a new phone, the stores do not provide a native restore function for consumables. Therefore, your backend database must act as the primary source of truth, attributing consumable balances (such as virtual gold or token reserves) to a centralized user account instead of local app state.

Non-consumable products are purchased once and remain permanently bound to the user's platform identity. Examples include ad removal, premium level packs, advanced editing tools, or offline map downloads. Because these digital goods monetization products never expire, Apple and Google track them indefinitely on their servers. When a user changes devices or logs in on a clean install, the client-side system queries the platform's billing cache to automatically restore access to these non-consumables.

Architecting non-consumables requires localized entitlement checks. Developers must build UI pathways that seamlessly toggle features based on native transaction arrays. While server-side databases should store non-consumable entitlements for multi-platform synchronization, the mobile clients can rely on local, cryptographically signed platform receipts to grant lifetime access.

Auto-Renewable vs. Non-Renewing Subscriptions

Auto-renewable subscriptions are the engine of modern mobile SaaS and content applications. Under this model, users are billed automatically at the end of each billing cycle (such as weekly, monthly, or annually) unless they manually terminate the subscription through their native device account settings. Platforms handle the complex recurring payment processing, but developers must manage the complex logic of subscription status. You must build systems that handle billing grace periods, account holds (when a card fails), free trials, introductory offers, and voluntary or involuntary churn.

To manage auto-renewable subscriptions effectively, developers should utilize modern event-driven webhooks, specifically App Store Server Notifications V2 and Google Play Real-Time Developer Notifications (RTDN). These systems push real-time cryptographically signed updates directly to your server whenever a subscription auto-renews, fails to charge, enters a grace period, or is canceled. This server-side state machine ensures users never lose access due to sync delays, and protects against fraudulent usage of premium tiers.

Non-renewing subscriptions allow users to purchase premium access for a finite, fixed duration (e.g., a "3-Month Season Pass" or a "1-Year Archive Access") without automatically charging their account again at the end of the term. The stores treat these products technically like consumable or non-consumable one-time purchases, meaning they do not automate the billing cycle renewal or provide built-in expiration webhooks.

Consequently, the developer's server is solely responsible for storing the exact date of purchase, calculating the precise expiration timestamp, sending push notifications alerting the user of impending expiration, and updating the local app status once the end of the subscription is reached. Non-renewing subscriptions are often utilized in specialized academic, seasonal, or heavily regulated fields where automatic debiting of corporate credit cards is prohibited by organizational policy.

Crucial Prerequisites Before Implementation

Developer Account Requirements

Before writing a single line of in-app billing integration code, businesses must establish official developer accounts. To distribute applications and process purchases on iOS devices, enrolling in the Apple Developer Program is mandatory. Organizations must pay an annual fee of $99 (or $299 for the Enterprise Program). During registration, organizations must provide a valid D-U-N-S (Data Universal Numbering System) number to verify their legal business identity. Apple verifies this database record thoroughly, and any mismatches between your official corporate registration names and your Apple Developer application will stall the onboarding process.

For Android deployments, you must configure a Google Play Console merchant account. Establishing a Google Play Developer account requires a one-time registration fee of $25. Google similarly enforces verification processes for developers, particularly organizations, requiring official tax identification paperwork, proof of corporate status, and physical address verification.

Additionally, both platforms enforce strict role-based access control (RBAC). The corporate account owner must grant specific administrative, developer, and financial permissions to internal team members. For example, developers need access to upload bundles and configure product metadata, but only team members with assigned financial roles should view banking routing lines, set pricing strategies, or read sensitive monthly payout statements.

Configuring Tax, Banking, and Active Agreements (Caution: Compliance)

Many developers write billing code first, only to realize their in-app purchases fail to load during testing because their legal agreements are incomplete. In App Store Connect, developers must navigate to the "Agreements, Tax, and Banking" section to review, accept, and sign the Paid Apps Agreement. This contract governs the transaction fees, regional tax collection obligations, and payout terms. Developers must supply a verified IBAN or routing number for corporate bank deposits, submit a comprehensive tax profile, and complete the mandatory tax forms (such as the United States W-8BEN-E or W-9 forms) to prevent automatic maximum tax withholding on international earnings.

On the Android side, developers must link their Google Play Console to a verified Google Payments Merchant Profile. The setup process requires inputting your company’s legal entity registration details, physical address, and banking coordinates for payouts.

Both Apple and Google act as the "Merchant of Record" (MoR) in dozens of storefront jurisdictions worldwide, which means they calculate, collect, and remit local sales taxes and Value Added Tax (VAT) directly to sovereign tax authorities on your behalf. However, certain regions require self-filing or involve complex tax withholding laws. This necessitates a careful, professional review of your payout profiles by your legal and financial teams to ensure alignment with international tax compliance guidelines.

How to Configure In-App Purchases for iOS

Setting Up Products in App Store Connect

Creating your digital inventory within App Store Connect configuration is the first technical step for iOS. After logging into the console, select "My Apps" and navigate to your application dashboard. In the sidebar under the "Features" heading, click on "In-App Purchases" or "Subscriptions." Click the "+" button to register a new product.

You must select from the available categories: Consumable, Non-Consumable, or Auto-Renewable Subscription. Next, supply a unique "Reference Name" (this is internal-facing only and used to track the product inside dashboards) and a globally unique "Product ID." It is an industry standard to use reverse-domain name notation for your Product IDs:

com.yourcompany.yourapp.consumable.gems_100

com.yourcompany.yourapp.subscription.premium_monthly

Setting up localized metadata is mandatory. You must provide a "Display Name" and a "Description" for every country or territory you plan to support. These strings are retrieved dynamically via the StoreKit SDK and displayed to users on your custom purchase screens.

Furthermore, you must establish a default price tier. Apple then automatically generates equivalent localized prices across 175 storefronts based on local currency fluctuations.

Finally, do not forget the "Review Information" section. Apple's app review team requires a clear, functional screenshot of your application's subscription paywall or purchase triggers, along with descriptive testing instructions, to verify that your purchase flow behaves exactly as promised.

Integrating Apple StoreKit Native API

The implementation of iOS billing relies entirely on Apple StoreKit API, with StoreKit 2 representing the modern standard using Swift's native concurrency model. To fetch product data securely from Apple's servers, use the Product.products(for:) function. This async call takes a collection of your registered Product IDs and retrieves the verified metadata, localized pricing, and currency symbols:

import StoreKit

let productIDs = ["com.yourcompany.yourapp.subscription.premium_monthly"]
do {
    let storeProducts = try await Product.products(for: productIDs)
    for product in storeProducts {
        print("Product: \(product.displayName), Price: \(product.displayPrice)")
    }
} catch {
    print("Failed to fetch products from App Store Connect: \(error)")
}

To initiate a transaction, pass the retrieved @@CODE0@@ object to the @@CODE1@@ method. This triggers the native Apple confirmation sheet. Once the user authenticates with FaceID/TouchID, the async call yields a Product.PurchaseResult indicating the outcome:

let result = try await product.purchase()
switch result {
case .success(let verificationResult):
    // The transaction is cryptographically signed
    switch verificationResult {
    case .verified(let transaction):
        // Deliver the digital good to the user
        await transaction.finish()
    case .unverified(_, let error):
        // The cryptographic signature failed validation checks
        print("Unverified transaction found: \(error)")
    }
case .pending:
    // Awaiting parent authorization (Ask to Buy) or banking clearing
    break
case .userCancelled:
    // User voluntarily closed the system payment interface
    break
@unknown default:
    break
}

Developers must implement a continuous, detached Swift Task to monitor Transaction.updates as soon as the app launches. This background listener captures renewals, refunds, or payment fixes processed directly outside the app via Apple Support or system billing controls, ensuring your local entitlement caching remains perfectly in sync with Apple's database.

Handling App Store Review Guidelines for Digital Goods

Navigating Apple's App Store Review Guidelines is critical to avoid submission rejections. Guideline 3.1.1 dictates that any digital content, functionality, or services unlocked within an iOS application must utilize Apple's native in-app purchase mechanism. Attempting to bypass this rule by utilizing web-views, external credit card forms (e.g., Stripe, Adyen), or redirecting users to a web portal to complete a transaction for digital content will result in an immediate rejection or account suspension. There are limited exemptions, such as "Reader Apps" (apps designed to consume previously purchased magazines, books, or media) or physical goods distribution, which can use alternative payment methods.

To pass app review, your subscription purchase screen must clearly display the terms of the subscription, including the localized price, billing interval (e.g., "$9.99/month"), duration of free trials, and clear instructions explaining how a user can cancel their subscription through their Apple ID account settings.

Furthermore, you must provide accessible links to your Terms of Use (EULA) and Privacy Policy directly on the subscription purchase page. If you are selling non-consumable goods or active subscriptions, you must also provide a prominent "Restore Purchases" button on the UI, allowing users to restore their entitlements on new devices without re-purchasing.

How to Configure In-App Purchases for Android

Setting Up a Merchant Profile in Google Play Console

To enable digital goods monetization on Android, you must configure your monetization parameters inside the Google Play Console merchant account. Under the "Monetize" section in the main sidebar, select "Monetization setup." Ensure your account is correctly linked to your verified Google Payments Merchant Profile. Here, you will set up your public licensing key, configure your merchant currency preferences, and define tax rate templates according to your company's regional fiscal obligations.

Without linking a validated Google Payments account, the console will restrict you from adding paid products, throwing errors when your application attempts to query billing profiles during run-time.

Creating Digital Products and Subscriptions

Within the Google Play Console, inventory is managed under two categories: "In-app products" (for consumables and non-consumables) and "Subscriptions." To create a product, click "Create product" and provide a distinct "Product ID" using a similar naming structure to iOS. Google Play requires a "Title," a "Description," and a localized pricing definition.

Google’s subscription model offers excellent commercial flexibility. Unlike the traditional fixed pricing of some platforms, Google utilizes a structured hierarchy of "Subscriptions," "Base Plans," and "Offers":

• Subscription: The parent product shell (e.g., "Premium Membership").

• Base Plans: Configured within the subscription, these define the specific duration and pricing structures (e.g., "Monthly Auto-Renewing Base Plan for $9.99" or "Prepaid 3-Month Plan for $24.99").

• Offers: Promotional variants built on top of a Base Plan, providing introductory pricing, free trials, or upgrade discounts (e.g., "Free Trial for 7 days, then standard monthly base plan price").

This architectural hierarchy allows Android developers to adjust promotional pricing campaigns, experiment with free trials, or switch billing cadences without creating entirely new product listings, keeping their client-side application codebase clean.

Integrating the Google Play Billing Library

To implement the payment code on Android, you must integrate the Google Play Billing Library (version 6 or 7) into your build files. Declare the dependency inside your module's build.gradle file:

dependencies {
    implementation "com.android.billingclient:billing:7.0.0"
}

Next, instantiate and initialize the @@CODE0@@ on your application's main thread. This requires passing a @@CODE1@@ callback to capture the result of asynchronous checkout interactions:

BillingClient billingClient = BillingClient.newBuilder(context)
    .setListener(new PurchasesUpdatedListener() {
        @Override
        public void onPurchasesUpdated(BillingResult billingResult, List<Purchase> purchases) {
            if (billingResult.getResponseCode() == BillingClient.BillingResponseCode.OK && purchases != null) {
                for (Purchase purchase : purchases) {
                    handlePurchase(purchase);
                }
            }
        }
    })
    .enablePendingPurchases()
    .build();

billingClient.startConnection(new BillingClientStateListener() {
    @Override
    public void onBillingSetupFinished(BillingResult billingResult) {
        if (billingResult.getResponseCode() == BillingClient.BillingResponseCode.OK) {
            // The client is connected and ready to query products
        }
    }
    @Override
    public void onBillingServiceDisconnected() {
        // Automatically attempt reconnection here using exponential backoff
    }
});

To complete purchases, you must fetch products using @@CODE0@@. Once selected by the user, launch the platform interface via @@CODE1@@.

Crucially, every successful Android purchase must be acknowledged via @@CODE0@@ (or consumed via @@CODE1@@ for consumables) within a strict three-day window. If your app or backend server fails to send this acknowledgment, Google will automatically assume a delivery failure, cancel the transaction, and issue a full refund to the user.

Securing Transactions: Server-Side Receipt Validation

Why Client-Side Validation is a Security Risk

Relying entirely on mobile client-side code to verify transaction success exposes your application to severe security vulnerabilities. On compromised, rooted, or jailbroken devices, attackers can easily download memory-patching or proxy-intercept utilities (such as Lucky Patcher, LocalAPStore, or Frida) to compromise local runtime code. These tools intercept native network calls to store endpoints, returning forged success payloads.

If your application simply evaluates local variables like isPurchased = true or executes a basic localized signature verification, these manipulation tools can trick your code into granting premium features without processing any payment.

Furthermore, relying solely on client-side verification exposes your app to replay attacks and man-in-the-middle (MITM) attacks. Here, an attacker sniffs a valid purchase payload from a previous low-cost transaction and replits it against other app instances or endpoints to unlock high-value items. Since client-side code cannot securely check if a unique transaction ID has already been processed or associated with a different user account, preventing fraud without a central database is incredibly difficult.

Implementing Secure Server-to-Server Verification

To achieve real fraud prevention in IAP workflows, you must route receipt verification through a secure, server-side receipt validation system. Under this approach, the mobile client receives a cryptographically signed transaction token from the store (a StoreKit JWS token on iOS or a purchase token on Android) and immediately uploads it to your secure, HTTPS-pinned private backend API server. Your server then performs cryptographic verification directly with Apple or Google APIs:

[ Mobile App ] -- (1) Send Transaction Token --> [ Your Server ]
                                                      |
                                           (2) Verify Receipt Token
                                                      |
                                                      v
[ App Store / Google Play API ] <---------------------+
                                                      |
                                            (3) Return verified JSON State
                                                      |
                                                      v
[ Mobile App ] <-- (4) Grant Entitlement <--- [ Your Server ]

On iOS, you verify the transaction token using Apple's App Store Server API. This involves validating Apple's JSON Web Signature (JWS) format. If you are supporting legacy iOS devices, you might use the /verifyReceipt fallback endpoint (with a secure Shared Secret), but modern apps should verify the JWS metadata natively on their backend or query the App Store Server API using JWT (JSON Web Tokens) generated using your private developer keys.

On Android, your backend queries the Google Play Developer API via HTTPS, authenticating with a Google Cloud Service Account. Use the @@CODE0@@ and @@CODE1@@ endpoints to retrieve the transaction's current state:

{
  "kind": "androidpublisher#subscriptionPurchaseV2",
  "startTimeMillis": "1710000000000",
  "subscriptionState": "SUBSCRIPTION_STATE_ACTIVE",
  "latestOrderId": "GPA.3312-4412-5512-66120",
  "acknowledgementState": "ACKNOWLEDGEMENT_STATE_ACKNOWLEDGED"
}

By cross-referencing incoming orderId values against a unique database table on your server, you can instantly flag and block duplicate transaction IDs (preventing replay attacks).

Additionally, by registering for App Store Server Notifications V2 and Google Play Real-Time Developer Notifications (RTDN), your backend will receive instant, cryptographically signed webhooks for any lifecycle change (refunds, renewals, cancellations) and adjust user balances accordingly, ensuring secure, accurate synchronization.

How to Test In-App Purchases Safely

Using Apple Sandbox Environment for iOS

Validating your in-app billing mechanics without charging real credit cards requires configuring a sandbox testing environment. In App Store Connect, go to "Users and Access" and locate "Sandbox Testers" under the "Sandbox" submenu. Create a dedicated test account using a real, unlinked email address. When you compile your application on a physical iOS device using your Xcode development signing profile, logging in with this sandbox tester account redirects all payment requests to Apple's sandbox environment.

For rapid local testing, StoreKit Configuration Files (.storekit files) in Xcode allow you to test your purchasing interface, error dialogues, and basic state toggles completely offline without connecting to App Store Connect.

When testing subscriptions, the sandbox accelerates billing cycles to make QA feasible. For example, a standard one-month subscription renews every five minutes in sandbox mode, and caps at a maximum of six renewals before automatically canceling. This behavior lets developers test edge cases like renewals, grace periods, and cancellations in minutes instead of months.

Utilizing Google Play Internal Testing Tracks

On Android, safe integration testing is managed via Lizence Testers and Google Play's Internal Testing Tracks. First, navigate to your Google Play Console settings, locate "License Testing," and add your developers' and QA testers' Google account email addresses. Under the response menu, choose either @@CODE0@@ to trigger mock successful transactions, or simulate error states using @@CODE1@@ or USER_CANCELED to verify your app's error handling.

Next, upload your release-signed APK or Android App Bundle (AAB) directly to the "Internal Testing" track. Only users registered as testers can download this build through the Google Play Store, and any in-app billing requests they initiate will bypass actual billing APIs, displaying Google's mock "Test Card" window.

Much like iOS, Android auto-renewable subscriptions are accelerated for testing purposes:

This accelerated timeline allows your QA engineering team to verify server-side RTDN subscription webhook processing, check expiration behaviors, test grace periods, and validate billing logs under real-world conditions without waiting months for renewals to occur.

App Store Compliance and Commission Structures

Understanding Apple and Google Fee Policies (15% vs. 30% rules)

Your financial models must account for native app store commission rates. By default, both Apple and Google operate on a standard 30% fee structure for digital goods monetization. However, both platforms offer lower commission programs to support smaller businesses and encourage subscription models.

Under the App Store Small Business Program, companies generating under $1 million in cumulative annual revenue across their developer accounts can apply to reduce their Apple platform fee to 15%. This application is not automatic; developers must manually apply through the App Store Connect dashboard.

Google Play offers an automatic 15% service fee on the first $1 million in developer earnings each calendar year. For subscriptions, both platforms reduce their fee to 15% for ongoing auto-renewable subscriptions, though conditions vary by platform (e.g., Google Play applies the 15% rate for subscriptions starting on day one, whereas Apple historically applied this rate after a subscription remained active for 12 consecutive months).

Furthermore, global anti-trust regulations have led to the introduction of alternative payment billing policies in regions like the European Union (under the Digital Markets Act), South Korea, and Japan. In these storefronts, developers can present external payment forms or direct-to-web billing flows.

However, using external payment options does not bypass store commissions entirely. Apple and Google still collect a platform fee for these alternative transactions (typically reduced by 3%, resulting in a 12% or 27% commission rate), and developers must manually track, audit, and report monthly external transaction logs to the stores.

The Importance of the "Restore Purchases" Functionality

Apple App Store Review Guidelines Section 3.1.1 strictly mandates that any app offering non-consumable digital items or active subscriptions must include a prominent, working "Restore Purchases" button. If an app reviewer logs into your app using a test account, logs out, reinstalls the application, and is blocked from restoring their previous purchases, your app submission will be rejected. This requirement is in place so users don't have to pay twice for the same lifetime product or active subscription when switching devices.

Implementing this functionality using StoreKit 2 is straightforward, as the native API can dynamically query current entitlements on demand:

do {
    // Force a synchronization check with App Store server
    try await AppStore.sync()
    
    // Check for verified active entitlements
    for await result in Transaction.currentEntitlements {
        if case .verified(let transaction) = result {
            // Unlock features matching the transaction productID
            await transaction.finish()
        }
    }
} catch {
    print("Restore purchases synchronization failed: \(error)")
}

Google Play does not strictly enforce a "Restore" button because the Android Billing Library automatically queries local cached transactions on startup and updates app states. However, adding a manual "Sync Purchases" or "Restore" trigger in your Android settings screen is still highly recommended to prevent sync delays, align cross-platform data, and provide a clear, reliable path for users troubleshooting billing issues.