Реализация серверной верификации покупок (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.
Свяжитесь с нами, чтобы обсудить детали вашего проекта. Закажите аудит текущей схемы валидации — мы выявим уязвимости и предложим оптимальное решение. Получите консультацию по вашему проекту — мы оценим сроки и предложим оптимальное решение.