In-App Purchases: Setup, Pricing and Refund Basics

Before you can sell anything inside your game, you need four things in place: a developer account with the store you plan to use, a tax and banking profile that lets the store pay you, a server or backend that can verify receipts, and your app's digital goods mapped out as product IDs. Without those, the setup screens will stall halfway through. This guide walks through in app purchases in the order you actually build them, then covers the pricing and refund decisions that cause the most trouble for small teams.

A store handles the transaction, the tax collection and the refund request. Your app handles delivery of what was bought and the customer support around it. Most avoidable problems come from teams treating those two jobs as one.

Step 1: Define What You Are Selling and How It Is Classified

Product types and their rules

Stores sort products into categories, and the category decides the rules. Consumables are used up and can be bought again, like extra lives or currency packs. Non-consumables are bought once and restored forever, like removing ads or unlocking a level pack. Subscriptions renew on a schedule and need their own product setup and renewal handling.

Write the list of products, their IDs and their type before touching any console. Product IDs are permanent in practice. Renaming one later means creating a new product and losing the purchase history tied to the old one.

Where setup time goes

Most of the calendar time is not code. It is account verification, tax forms, and review of the first product. A first submission with a new payment profile can take longer than later ones. Store review of the app build itself is separate from product approval, so budget for both.

Step 2: Create the Products in the Store Console

Each store has its own console, and each requires a product record with an ID, a name, a description, a price tier and localized display text. Do this before writing client code, because the client fetches the product catalog from the store at runtime and needs real entries to test against.

1. Create the app record in the developer console if it does not exist yet.
2. Fill in the tax and banking details so the store can pay you. This is often the slowest step.
3. Add each product with a type, a unique ID and a price.
4. Add localized titles and descriptions that match what the player actually receives.
5. Move products to a test state and confirm they appear in a store query from the app.

Keep the product catalog in one place, on your own server if you have one, and treat the store consoles as the source of truth for price and availability. That way you change a price in one place and the app reads it on the next launch.

Step 3: Wire Up the Purchase Flow and Verify Receipts

The minimum working flow has five stages:

• The app asks the store what is available.
• The player taps buy and the store shows its own confirmation sheet.
• The store returns a receipt or a signed transaction to the app.
• Your server validates that receipt with the store's verification endpoint.
• Your server grants the item and records the transaction ID so the same receipt cannot be granted twice.

Step four is the one teams skip and later regret. Without server-side validation, a modified client can grant itself goods the player never paid for. Store receipts also need a check against replay: store the transaction ID and reject duplicates.

Pending and interrupted payments

If a payment fails partway through, the store may report a pending state rather than success or failure. Handle pending as its own case and reconcile later instead of retrying the charge. Players who close the app at the confirmation screen are the source of most double grants.

Restoring purchases

Non-consumables need a restore path. A player who reinstalls the app should get back what they already bought. Build a "restore purchases" action early, because reviewers on the app stores routinely test it, and a missing restore is a common rejection reason.

Step 4: Set In-App Purchase Pricing

In app purchase pricing is where the store's constraints meet your economy design. Every major store uses price tiers that map to local currencies in many countries. You pick a tier, not a free-form number, in most cases. That means the price a US player sees is set by the tier, and local prices in other markets are calculated by the store's currency conversion and rounding rules, which you should check per country rather than assume.

Three practical anchors for choosing a tier:

• Place the entry-level purchase low enough that a first-time buyer will try it. Small purchases are easier to justify than large ones.
• Keep the ratio between tiers consistent, so a larger bundle visibly gives better value per unit consumed.
• Compare against what your genre charges, not against unrelated apps. Players calibrate to the game they are already playing.

Store commission, which is a percentage of each sale, comes out of the price you set. Revenue per sale is the tier price minus commission and minus any local tax the store collects and remits. Work your economy in net terms, because gross numbers will mislead your budget.

Verify commission rates and reduced-rate eligibility on the store's own developer site, as they change over time. The table above is a checklist, not a price list.

When you need a payment widget instead of a store

Some selling happens outside the store's billing system: web storefronts, desktop builds, or platforms where you handle payment yourself and need to grant items on the basis of a transaction you can confirm. For that route, a payment widget can take crypto payments and is meant for websites and apps that want to avoid writing their own checkout. Whatever method you use, the receipt or transaction record must still flow into the same server-side grant and deduplication logic described above.

Refund Basics: Who Does What

Refunds are the part where developers most often assume responsibility they do not have. In the Apple App Store and Google Play, the store handles refund requests from consumers and makes the decision. You can flag abuse or provide evidence, but you do not control the outcome. Outside the store, for example in jurisdictions with statutory cancellation rights, the rules vary by country and you must follow local consumer law.

Once a refund is approved, the store reverses the payment and typically notifies you through a server notification. Your job is the follow-up: revoke the item, mark the account, and stop delivering on a subscription. A refund does not always mean an angry player, so keep the message neutral and confirm what changed on the account.

Chargebacks and fraud

Separately from store refunds, a cardholder can dispute a charge with their bank. Stores handle this for their own billing, and the notification reaches you as a reversal. Your only practical defense is a clear record of what was delivered and when, tied to the transaction ID. Keep that log for as long as the store's terms and your local record-keeping rules require.

Common Mistakes to Avoid

Skipping receipt verification

Client-only validation is a placeholder at best. Any server grant path that trusts the client without checking the store's signature or verification endpoint opens the door to free goods. This is the single most expensive shortcut in this list.

Hard-coding prices in the client

Prices live in the store. If you write a price into your binary, the next price change becomes a store release. Read the catalog at runtime and let the store supply the display price, including the local currency symbol.

Forgetting pending and interrupted purchases

Payments fail, networks drop, players close the app at the confirmation screen. If your flow only handles success and failure, pending purchases can be lost or double-granted. Log every transaction state, not just the final one.

Missing restore and poor product descriptions

A missing restore breaks reinstalls for paying players. Vague product descriptions increase refund requests, because the player did not get what the store's sheet led them to expect. Say exactly what the purchase includes.

A Short Checklist Before You Ship

Run through this list on a fresh install and a test account before you submit the build:

• Product list with IDs and types written down and agreed.
• Tax and banking profile complete, and a test payout confirmed if available.
• Server validation on every grant, with transaction ID deduplication.
• Restore path built and tested on a fresh install.
• Pending and interrupted states logged and reconciled.
• Prices read from the store catalog, never hard-coded.
• Refund and chargeback notifications wired to revoke the item.
• Local prices spot-checked in two or three markets.

Get these in place and the rest is iteration on the economy, which is the part you can change without breaking payments. Store rules, commission rates and consumer law differ by market and change over time, so verify the current terms on each store's developer site and your local authority before launch. This article is general information, not financial, legal or tax advice.