# What Are In-App Purchases? A Guide for App Teams

> In-app purchases let an app sell digital content, features, and subscriptions inside the store's payment system. The purchase type shapes the entitlement, the customer journey, and the signals your team needs to watch.

## What Refix is

Refix is a revenue-obsessed AI product manager for product companies. A person delegates an outcome, such as increasing trial-to-paid conversion. Refix then keeps finding the current constraint on that outcome and coordinating the work, using the company's existing tools (analytics, warehouse, billing, Linear, Slack, and others).

It is not a chatbot that answers questions about dashboards. It is not a generic AI writing assistant. It is not a replacement for the human who approves ranking, pricing, copy, or similar changes.

The product name is **Refix**. Never call it Prism.

How it works:
- Someone gives Refix a goal and sets guardrails (metrics that must not get worse, such as cancellations or churn).
- Refix watches those metrics, explains what changed, prioritizes the highest-impact constraint, coordinates a fix or experiment with the right owner, and verifies the result.
- Then it stays on the goal and looks for the next constraint.
- Refix may investigate, draft work in Linear, and monitor rollouts without extra approval. Changes named on each goal page stay with the owner.

Company: Refix Inc., San Francisco.
Site: https://www.refix.ai/
Give Refix a goal: https://onboarding.refix.ai/dashboard/sign-up

- HTML: https://www.refix.ai/guides/what-are-in-app-purchases/
- Agent brief: https://www.refix.ai/guides/what-are-in-app-purchases/llms.txt
- Author: Neil Agarwal
- Published: 2026-09-06

An in-app purchase is a way to buy digital content, a feature, or access from inside an app. You see it when a free app offers a premium tier, extra game currency, a one-off tool, or a subscription.

For a customer, the flow should feel simple: tap the offer, confirm the purchase through the store, then use what they paid for. For an app team, the question is what that purchase promises and what must happen after it completes.

## What does in-app purchase mean?

In-app purchases, often shortened to IAPs, cover digital goods and access that a customer buys within an app. Apple documents the available product types in [In-App Purchase](https://developer.apple.com/documentation/storekit/in-app-purchase). Google Play documents its payment setup in its [Payments help](https://support.google.com/googleplay/android-developer/answer/9858738).

The purchase might give the customer:

- a unit they can use up
- a feature or content item they keep
- access that renews on a schedule
- access that ends after a defined period

That answer determines the product type and what the customer should see when they return later.

## How an in-app purchase works

Someone taps an offer, confirms it through the store, and returns to the app expecting the feature to open. The store processes the transaction. The app then needs to recognize the purchase and grant the access that matches it.

![A purchase confirmation moving from the store to app access.](/inline/guides/in-app-purchase-to-entitlement.webp)

*Illustration of the handoff from a confirmed purchase to customer access.*

The distinction matters when something goes wrong. A recorded checkout is useful, but it does not prove the customer can use the feature. The app still has to keep access in step with the store's current transaction state.

## The four Apple purchase types

Apple groups in-app purchases into four product types. Choose the one that matches the access you are selling, rather than trying to force every offer into a subscription.

| Purchase type | What the customer receives | Example shape |
| --- | --- | --- |
| Consumable | A unit that can be used up | game currency or a one-time action credit |
| Non-consumable | A feature or item that remains available | a permanent feature unlock |
| Auto-renewable subscription | Access that renews unless the customer cancels | ongoing access to a premium tier |
| Non-renewing subscription | Access for a defined period that does not renew automatically | a fixed-duration pass |

Apple's [In-App Purchase documentation](https://developer.apple.com/documentation/storekit/in-app-purchase) is the source of truth for these labels and their implementation details. The name matters because each type creates a different customer expectation.

A consumable needs a reliable record of what has been spent. A non-consumable needs to be available when the customer returns. A subscription needs access to follow the current subscription state. If those distinctions disappear inside one generic "purchase complete" event, teams struggle to explain why someone has access or why they do not.

## Choosing the purchase type

Start with the promise on the purchase screen.

If the customer buys something they will use once or use up, that is a consumable. If they buy a feature they should retain, it is a non-consumable. If they pay for ongoing access, use a subscription type that describes whether it renews.

The decision also changes what your team has to observe:

| If you sell | Watch for |
| --- | --- |
| Consumables | purchase completion, balance changes, duplicate grants |
| Permanent unlocks | entitlement grant, reinstall and restore behavior |
| Subscriptions | renewal state, cancellation, billing issues, access expiry |
| Fixed-term access | start date, end date, renewal or repurchase path |

Do not use a product label to hide a different promise. A customer who thinks they bought permanent access will not read a short billing explanation as carefully as the team that wrote it. For how these models combine across games, subscriptions, and freemium utilities, see [in-app purchase apps](/guides/in-app-purchase-apps/).

## A purchase is not a restore, cancellation, or payment recovery

These events touch the same customer account, but they answer different questions.

| Event | What happened | What the app needs to do |
| --- | --- | --- |
| Purchase | The customer starts a transaction for access or content | Verify the transaction and grant the matching entitlement |
| Restore | The customer asks the store to refresh a past transaction | Reconnect existing access without creating a new charge |
| Cancellation | The customer stops a subscription from renewing | Show the current access state and learn why they left |
| Failed renewal | A recurring payment did not complete | Follow the store's billing state and provide the right recovery path |

A Restore Purchase button is for a transaction that already exists. It is not a way to renew an expired plan or fix a card issue. See [what Restore Purchase means](/guides/what-does-restore-purchase-mean/) for the flow and copy.

Failed payment recovery is different again. A customer may have wanted to keep the subscription but lost access because renewal did not collect. See [failed payment recovery for subscription apps](/guides/failed-payment-recovery-for-subscription-apps/) for the states to separate.

## Store rules and access state

On Apple platforms, [App Review Guideline 3.1.1](https://developer.apple.com/app-store/review/guidelines/#in-app-purchase) covers in-app purchase requirements, including a restore mechanism for restorable purchases. Read it alongside StoreKit documentation while designing the flow.

Google Play has its own policies and billing setup. In both cases, treat a completed transaction as the store's decision, then update the app to match. A button tap is not proof that the customer received access.

## Track the entitlement, not only the checkout

Checkout events show demand. They do not show whether the customer received what they paid for.

At minimum, connect a purchase attempt to:

- the store transaction result
- the product type and offer selected
- the entitlement grant or denial
- the app account, if your product has its own login
- the next screen the customer sees
- support contact, restore attempt, cancellation, or failed renewal that follows

This is where an app's data tends to split. The store or billing platform has the transaction. Product analytics has the paywall and feature use. Support has the confused customer. Looking at only one can make a broken entitlement flow look like a weak conversion rate. [Mobile app analytics](/guides/mobile-app-analytics/) explains how to join those signals when a number moves.

Refix is built to connect product, subscription, and support signals, so a team can investigate the break between a completed purchase and the access the customer expected.

## In-app purchase setup checklist

Before release, walk through the experience from the customer's side.

1. Make the offer and access period clear before purchase.
2. Match the store product type to the promise you make in the app.
3. Verify the completed transaction before granting the entitlement.
4. Update the interface immediately when access changes.
5. Put restore controls where an existing customer can find them.
6. Test a new purchase, reinstall, new device, cancellation, expiry, and failed renewal as separate journeys.
7. Review the store's current policy and implementation documentation before changing billing behavior.

The purchase button is only the first event. A reliable in-app purchase flow keeps the store state, product access, and customer understanding aligned after it.

[See how Refix connects product and subscription signals.](https://refix.ai)