Реалізація серверної верифікації покупок (Receipt Validation)
Клієнт надіслав баг-репорт: користувач купив Premium, отримав токен транзакції, відновив додаток з резервної копії на іншому пристрої — і Premium знову активний без повторної оплати. Класика. Причина — валідація тільки на клієнті: додаток перевіряє локальний receipt або trust-флаг від StoreKit, не звіряючись із сервером. Ми — команда мобільних розробників з понад 7-річним досвідом впровадження in-app покупок. За цей час ми реалізували серверну валідацію для 30+ проєктів і переконалися: без неї втрати від шахрайства можуть сягати 15% виручки. Середня економія для клієнтів становить від 15 до 20% доходів — вражаюча цифра.
Що таке Receipt Validation?
Receipt Validation — це процес перевірки автентичності чека покупки на стороні сервера з використанням офіційних API магазинів додатків. Тільки серверна валідація гарантує, що покупка справді здійснена і не була підроблена. Без неї будь-який додаток вразливий для атак.
Чому клієнтська валідація небезпечна?
На iOS StoreKit 2 повертає Transaction із підписом Apple. Можна верифікувати підпис локально через Transaction.verificationResult, але це не захищає від replay-атак: зловмисник перехоплює валідний receipt одного користувача і підставляє його в інший акаунт. На Android ситуація аналогічна — BillingClient.queryPurchasesAsync() повертає Purchase об'єкти, які клієнт не повинен трактувати як підтвердження без серверної перевірки purchaseToken.
Найчастіша схема шахрайства — receipt sharing: один receipt поширюється між користувачами через форуми. Без серверної бази, що фіксує який originalTransactionId (iOS) або orderId (Android) вже використаний, це не виявити.
Як захиститися від receipt sharing?
Створіть таблицю purchase_receipts з унікальним індексом по original_transaction_id та product_id. При кожній верифікації перевіряйте, чи не використано вже цей чек іншим користувачем. Якщо так — відхиляйте запит. Це блокує поширення одного чека на безліч акаунтів. Додатково використовуйте Server Notifications для відстеження повернень і скасувань.
Чому Server Notifications критичні?
App Store Server Notifications V2 і Real-time Developer Notifications від Google надсилають події в реальному часі: DID_RENEW, EXPIRED, REFUND, GRACE_PERIOD_EXPIRED. Без них ваш сервер дізнається про зміни статусу підписки із затримкою до 24 годин, що дозволяє користувачам зі скасованою підпискою продовжувати користуватися контентом. Налаштування webhook-обробника — обов'язковий крок для захисту від застарілих даних.
Як улаштована нормальна серверна верифікація
Сторона iOS (App Store Server API). Старий підхід — POST на https://buy.itunes.apple.com/verifyReceipt з base64-encoded receipt-data — застарів. Apple просуває App Store Server API v1: клієнт передає серверу transactionId з Transaction.id (StoreKit 2), сервер виконує GET /inApps/v1/history/{transactionId} з JWT-токеном (підписаним ES256 ключем з App Store Connect). Відповідь — JWSTransaction, який потрібно декодувати і верифікувати підпис через Apple Root CA.
Паралельно потрібно підписатися на App Store Server Notifications V2: Apple пушить події на ваш endpoint. Детальніше — в App Store Server Notifications V2.
Сторона Android (Google Play Developer API). Для разових покупок — purchases.products.get з packageName, productId, purchaseToken. Для підписок — purchases.subscriptions.v2.get. Авторизація через Service Account з роллю Financial data viewer — це мінімально необхідні права. Відповідь містить purchaseState (0 = Purchased, 1 = Canceled, 2 = Pending) та acknowledgementState — якщо 0, потрібно викликати purchases.products.acknowledge, інакше Google поверне гроші автоматично через 3 дні. Детальніше — в Google Play Developer API.
Ідемпотентність і захист від replay. У базі зберігаємо таблицю purchase_receipts з унікальним індексом по original_transaction_id + product_id. При кожному запиті на верифікацію спочатку перевіряємо наявність запису — якщо вже верифіковано з іншим user_id, відповідаємо помилкою.
purchase_receipts id uuid PK user_id uuid FK platform enum('ios','android') original_transaction_id varchar UNIQUE (per product) product_id varchar purchase_state smallint expires_at timestamptz -- для підписок raw_payload jsonb -- оригінальна відповідь від Apple/Google verified_at timestamptz Стек та інтеграція
Серверна частина найчастіше Node.js (бібліотека app-store-server-api) або Python (google-auth + googleapiclient). Для Node зручний пакет node-apple-receipt-verify для легасі-endpoint, але краще одразу брати app-store-server-api від Apple — підтримує JWT-авторизацію та верифікацію JWS з коробки.
На стороні клієнта iOS — мінімум коду: отримати Transaction.id з Transaction.all або з updates потоку, відправити на бекенд. Не передавайте весь appStoreReceiptURL — це легасі, і файл може бути невалідним на симуляторі.
На Android клієнт передає purchaseToken та productId з Purchase.purchaseToken. Важливо: токен може бути одним для кількох productId при апгрейді підписки — враховуйте це в логіці.
Порівняння підходів iOS та Android
| Критерій | iOS (App Store Server API) | Android (Google Play Developer API) |
|---|---|---|
| Протокол | REST з JWT-авторизацією | REST з OAuth2 (Service Account) |
| Тип ключа | ES256 (App Store Connect) | JSON-ключ Service Account |
| Перевірка підпису | JWS (Apple Root CA) | Відповідь API (HTTPS) |
| Нотифікації | Server Notifications V2 | Real-time Developer Notifications |
| Захист від replay | unique transactionId |
unique purchaseToken |
Порівняння клієнтської та серверної валідації
| Критерій | Клієнтська валідація | Серверна валідація |
|---|---|---|
| Безпека | Вразлива до replay та підробки | Висока, з перевіркою на стороні магазину |
| Захист від sharing | Неможливий | Блокується унікальністю транзакції |
| Синхронізація статусу | Тільки на пристрої | На всіх пристроях через сервер |
| Сповіщення про зміни | Немає | Server Notifications |
Процес роботи
Починаємо з аудиту поточної схеми валідації — де саме перевіряється receipt, чи є серверна база покупок, чи обробляються Server Notifications. Далі проектуємо схему БД та API-ендпоінти, реалізуємо верифікацію для кожної платформи, налаштовуємо webhook-обробник для Server Notifications, покриваємо тестами з моковими відповідями від Apple/Google. Окремий етап — навантажувальне тестування ендпоінта верифікації, оскільки при пікових запусках (акція, фіча в топі App Store) він отримує все одразу.
Що входить у роботу
- Аудит поточної схеми валідації та вразливостей.
- Проектування бази даних покупок та API-ендпоінтів.
- Реалізація верифікації для iOS (App Store Server API v1) та Android (Google Play Developer API).
- Налаштування Server Notifications (App Store Server Notifications V2 та Real-time Developer Notifications).
- Написання тестів з моковими відповідями від Apple/Google.
- Інтеграційне та навантажувальне тестування.
- Документація API та інструкція для розробників.
Терміни — від 2 до 5 днів, залежить від наявності серверної інфраструктури та кількості типів покупок (разові, підписки, consumable, non-consumable). Якщо сервер уже є і потрібно лише додати верифікацію — ближче до 2 днів. Повна архітектура з нуля плюс міграція наявних користувачів — до 5.
Зв'яжіться з нами, щоб обговорити деталі вашого проєкту. Замовте аудит поточної схеми валідації — ми виявимо вразливості та запропонуємо оптимальне рішення. Отримайте консультацію щодо вашого проєкту — ми оцінимо терміни та запропонуємо оптимальне рішення.