Реалізація внутрішньоігрового магазину мобільної гри
Внутрішньоігровой магазин — центральна точка монетизації гри. Гравець відкриває його з намірою потратити. Завдання реалізації: не заважати цьому намірові технічними проблемами та зробити процес покупки максимально простим.
Архітектура каталогу
Каталог магазину зберігається на сервері — ніяких захардкодованих цін та товарів на клієнті. Це дозволяє змінювати пропозиції без апдейту застосунку, проводити A/B-тести та запускати акції у реальному часі.
Структура товара:
{
"productId": "gems_pack_medium",
"type": "iap_consumable",
"storeProductId": {
"ios": "com.mygame.gems.500",
"android": "gems_500"
},
"displayName": "500 кристалів",
"description": "Плюс 50 бонусних кристалів",
"gemAmount": 500,
"bonusGemAmount": 50,
"badge": "best_value",
"position": 2,
"isVisible": true
}
storeProductId — різні для iOS та Android, так як product ID у App Store та Google Play незалежні. Клієнт вибирає потрібний по платформі при відображенні.
Покупка IAP: технічний потік
// 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):
// Верифікація на сервері
let serverVerified = await verifyWithServer(transaction)
if serverVerified {
await transaction.finish()
return .success
} else {
// Не финишуємо транзакцію — не видаємо товар
return .verificationFailed
}
case .unverified:
return .verificationFailed
}
case .userCancelled: return .cancelled
case .pending: return .pending
}
}
Не викликаємо transaction.finish() до видачи товара. Якщо финишувати транзакцію до підтвердження доставки — при сбої сервера товар не виданий, транзакція завершена, восстановити неможливо. Тільки після serverVerified = true.
Віртуальна валюта
Кошелек віртуальної валюти зберігається на сервері. Клієнт відображає баланс, отриманий з сервера при останній синхронізації, та оновлює після кожної транзакції.
Логіка поповнення:
POST /shop/purchase
{ "productId": "gems_pack_medium", "receiptData": "...", "userId": "..." }
→ Сервер верифікує receipt у Apple/Google
→ Перевіряє, що транзакція не була оброблена ранее (idempotency by transactionId)
→ Зачисляє 550 gems на баланс гравця
→ Повертає { "newBalance": 1050, "transactionId": "..." }
Idempotency обов'язкова: якщо клієнт відправив запрос двічі (сбій мережи → retry), товар повинен бути виданий один раз, а не двічі.
Історія покупок
Екран історії покупок — часте вимога та хороша практика для зниження чарджбеків. Гравець видит всі транзакції з датою, сумою та виданим товаром. Це зменшує «я не пам'ятаю що купив» як причину dispute.
Технічно: таблиця purchase_history на сервері, пагінований API, клієнтський список з pull-to-refresh.
Ротируючі пропозиції та акції
Daily Deals, Flash Sales, персоналізовані офферы — окремий тип позицій магазину з validUntil timestamp. Клієнт показує таймер зворотного відліку.
Для персоналізації: Firebase Remote Config або собственный recommendation engine вибирает офферы на основі поведення гравця (що купував, до якого рівня дійшов, як давно не відкривав магазин).
Restore Purchases
На iOS обов'язкова кнопка «Восстановити покупки» для non-consumable IAP та підписок. Реалізація через Transaction.currentEntitlements у StoreKit 2. На Android — автоматично при вході у Google Play, але кнопка у налаштуваннях усе рівно гарна як UX.
Терміни: базовий магазин з кількома товарами, IAP-інтеграцією та серверною верифікацією — 5 днів. Повна реалізація з ротируючими пропозиціями, історією, підписками та аналітикою — 2 тижні.