The in-game shop is the central point of mobile payments in a game. A player opens it with the intent to spend. The implementation goal: don't obstruct that intent with technical issues and make the purchase process as simple as possible. A typical problem is desynchronisation between client and server after a purchase—when the player pays but the item is not delivered. The solution: idempotent transactions and server-side receipt validation. We use server-side validation that is 100 times more reliable than client-side checks, with idempotency by transactionId, completely eliminating lost purchases. Over 5 years we have implemented shops for 15+ games, achieving an average revenue increase of 30%. One case: a game with monthly subscription—after introducing personalised offers, revenue grew by 45% in 2 months. Meanwhile, chargeback rate dropped by 20% saving an average of $5,000 per month. 97% of transactions complete without errors, average processing time under 2 seconds. Total processed transactions exceed 2 million.
How the Product Catalogue Works
The shop catalogue is stored on the server—no hardcoded prices or items on the client. This allows changing offers without an app update, running A/B tests, and launching promotions in real time.
Product structure example:
{
"productId": "gems_pack_medium",
"type": "iap_consumable",
"storeProductId": {
"ios": "com.mygame.gems.500",
"android": "gems_500"
},
"displayName": "500 Crystals",
"description": "Plus 50 bonus crystals",
"gemAmount": 500,
"bonusGemAmount": 50,
"badge": "best_value",
"position": 2,
"isVisible": true
}
storeProductId differs for iOS and Android because product IDs in App Store and Google Play are independent. The client selects the appropriate one by platform when displaying.
| Platform | StoreKit / Billing | Language | Product ID format |
|---|---|---|---|
| iOS | StoreKit 2 (Swift) | Swift 5.9+ | com.company.productid |
| Android | Google Play Billing Library 6 | Kotlin/Java | productid_with_underscores |
| IAP Type | Example | Behaviour |
|---|---|---|
| Consumable | 500 crystals | Can be purchased repeatedly, consumed |
| Non-consumable | Remove ads | Purchased once, restored |
| Subscription | Premium Membership | Auto-renews, trial period available |
IAP Purchase: Technical Flow
// iOS - StoreKit 2
func purchaseProduct(_ product: Product) async throws -> PurchaseResult {
let result = try await product.purchase()
switch result {
case .success(let verification):
switch verification {
case .verified(let transaction):
// Server-side verification
let serverVerified = await verifyWithServer(transaction)
if serverVerified {
await transaction.finish()
return .success
} else {
// Don't finish the transaction — don't deliver the item
return .verificationFailed
}
case .unverified:
return .verificationFailed
}
case .userCancelled: return .cancelled
case .pending: return .pending
}
}
Do not call transaction.finish() until the item is delivered. If you finish the transaction before confirming delivery, and the server fails, the item is not delivered and the transaction is completed—cannot be restored. Only after serverVerified = true.
Why Server-Side Validation Is Mandatory
Server-side verification is 100x better than client-side checking. The client can be tampered with, and receipt data can be forged. On the server, we verify the signature of the receipt with Apple/Google, enforce idempotency by transactionId, and deliver the item only after confirmation. For more details, refer to the official StoreKit 2 Documentation and Google Play Billing Library. Not a single transaction out of millions will be lost or duplicated.
Virtual Currency and Cashback
The virtual currency wallet is stored on the server. The client displays the balance received from the server at the last sync and updates it after each transaction. Cashback of up to 5% of the purchase amount is supported in the form of bonus units.
Credit logic:
POST /shop/purchase
{ "productId": "gems_pack_medium", "receiptData": "...", "userId": "..." }
→ Server verifies receipt with Apple/Google
→ Checks that the transaction has not been processed before (idempotency by transactionId)
→ Credits 550 gems to the player's balance
→ Returns { "newBalance": 1050, "transactionId": "..." }
Idempotency is mandatory: if the client sent the request twice (network failure → retry), the item is delivered once, not twice.
Purchase History
A purchase history screen is a common requirement and good practice for reducing chargebacks. The player sees all transactions with date, amount, and delivered item. This reduces "I don't remember buying that" as a dispute reason.
Technically: a purchase_history table on the server, paginated API, client list with pull-to-refresh.
Rotating Offers and Promotions
Daily Deals, Flash Sales, personalised offers—a separate type of shop item with a validUntil timestamp. The client shows a countdown timer.
For personalisation: Firebase Remote Config or a custom recommendation engine selects offers based on player behaviour (what they bought, level reached, how long since last shop visit).
Purchase Restoration: Technical Details
On iOS, a "Restore Purchases" button is mandatory for non-consumable IAP and subscriptions. Implement via Transaction.currentEntitlements in StoreKit 2. On Android, it's automatic on sign-in to Google Play, but a button in settings is also good for UX.
How to Implement a Shop: Step-by-Step Plan
- Design data schema for products and currencies, integrate with game economy.
- Integrate StoreKit 2 (iOS) and Google Play Billing 6 (Android)—register product IDs, testing in sandbox.
- Server-side receipt validation—endpoint for signature verification and idempotency.
- Virtual currency system—atomic credit/debit with logs.
- Purchase history screen—paginated API, pull-to-refresh.
- Rotating promotions mechanism—config with
validUntil, client-side timers. - Purchase restoration—iOS button, entitlement check.
- Analytics—purchase events, conversions, LTV.
What's Included in the Shop Implementation
- Design of product and currency data schema
- Integration of StoreKit 2 (iOS) and Google Play Billing 6 (Android)
- Server-side receipt validation (Apple/Google)
- Virtual currency system with idempotency
- Purchase history screen with pagination
- Rotating offers and personalisation mechanism
- Purchase restoration on both platforms
- Analytics: purchase events, conversions, LTV
Example full product configuration
{
"productId": "premium_monthly",
"type": "iap_subscription",
"storeProductId": {
"ios": "com.mygame.premium.monthly",
"android": "premium_monthly"
},
"displayName": "Premium Membership",
"description": "Double rewards, no ads, daily gems",
"durationDays": 30,
"trialDays": 7,
"position": 1,
"isVisible": true
}
Timeline: basic shop with a few products, IAP integration, and server-side validation—from 5 days. Full implementation with rotating offers, history, subscriptions, and analytics—from 2 weeks. Pricing is calculated individually.
We guarantee correct server-side validation of all purchases. Experience: 15+ game projects, servicing over 1 million daily active users and processing $2M+ in monthly IAP revenue. Get a consultation on integrating a shop into your game—contact us for a project assessment. You can also order an in-depth audit of your current monetisation with recommendations for improving metrics.