Перевіряйте серверні сповіщення App Store, перш ніж діяти щодо повернення коштів, бо надіслати запит на ваш webhook URL може будь-хто

Будь-хто, хто дізнається ваш webhook URL, може надіслати на нього повернення коштів. Це незручна правда, що стоїть за кожним серверним сповіщенням App Store і кожним Google Play Real-time developer notification: доки ви його не перевірили, повідомлення є лише HTTPS POST із якимось JSON усередині. Якщо ваш сервер скасовує підписку, забирає кредити або блокує акаунт лише тому, що в запиті написано REFUND, ви передали цю владу кожному, хто вміє написати команду curl.

Обидва магазини дають вам спосіб перевірки. Apple підписує саме сповіщення, тож ви можете перевіряти серверні сповіщення App Store, маючи лише кореневий сертифікат Apple. Google Play іде іншим шляхом. Повідомлення не підписане, але доставку через Pub/Sub можна підписати, і Google у будь-якому разі радить підтверджувати кожну зміну через свій API. Нижче пояснюємо, що доводить кожен із варіантів і чого коштує помилка в будь-який бік.

Що насправді підписує кожен магазин

Як перевіряти серверні сповіщення App Store

Документація Apple описує signedPayload як рядок із трьох компонентів у кодуванні Base64URL, розділених крапками: заголовка, корисного навантаження та підпису, підписаний відповідно до специфікації JSON Web Signature. Декодувати корисне навантаження легко. Щоб йому довіряти, потрібні чотири перевірки.

• Прочитайте масив x5c із декодованого заголовка. Apple документує порядок: спершу сертифікат із ключем підпису, далі проміжний сертифікат Apple, потім кореневий сертифікат Apple.
• Перевірте цей ланцюжок щодо кореневого сертифіката Apple, який ви самі завантажили з PKI-сайту Apple, на практиці це Apple Root CA - G3. Ніколи не довіряйте кореневому сертифікату, що прийшов усередині повідомлення, бо зловмисник може покласти туди будь-який сертифікат.
• Переконайтеся, що проміжний сертифікат містить розширення Apple Worldwide Developer Relations 1.2.840.113635.100.6.2.1, а потім перевірте підпис JWS відкритим ключем кінцевого сертифіката.
• Зіставте декодовані дані зі своїм застосунком: bundleId, appAppleId у production та environment. Дійсний підпис Apple на застосунку іншого розробника або на покупці з sandbox, що надійшла на ваш production endpoint, однаково не є вашим поверненням коштів.

Потім повторіть те саме для вмісту. Об'єкт data містить signedTransactionInfo і signedRenewalInfo, і кожен із них є окремим JWS зі своїм ланцюжком x5c. Обробник REFUND, який перевіряє конверт, але читає транзакцію без перевірки, залишив пролом посередині.

Використовуйте бібліотеку Apple замість власної реалізації

Apple публікує App Store Server Library для Swift, Java, Python і Node. Її SignedDataVerifier приймає ваші кореневі сертифікати, прапорець онлайн-перевірок, середовище, ваш bundle ID, а для production також ваш appAppleId. Код Node показує, що саме вона вимагає: рівно три сертифікати в ланцюжку, розширення кінцевого сертифіката Apple 1.2.840.113635.100.6.11.1 і розширення проміжного сертифіката, дати чинності сертифікатів, а також збіг bundle ID, app ID і середовища. Коли онлайн-перевірки ввімкнено, вона також запитує в OCSP responder, чи не відкликано кінцевий і проміжний сертифікати.

Чи достатньо списку дозволених IP?

Ні. Apple радить додати підмережу 17.0.0.0/8, якщо вашому серверу потрібен список дозволених адрес, і це стосується як sandbox, так і production. Це зменшує шум. Але не доводить, що повідомлення справжнє, і перестає працювати, щойно мережа Apple зміниться так, що ви про це не дізнаєтеся. Справжнім бар'єром залишайте перевірку підпису.

Як перевіряти сповіщення про повернення коштів у Google Play

Google Play публікує повідомлення RTDN у ваш власний топік Pub/Sub, і роль Pub/Sub Publisher у ньому має бути лише в сервісного акаунта google-play-developer-notifications@system.gserviceaccount.com. Далі ваша підписка доставляє повідомлення одним із двох способів, і кожен має свій доказ.

• Pull-підписка: ваш сервер відкриває автентифіковане з'єднання з Pub/Sub і отримує повідомлення. Публічного endpoint немає, тож стороннім нікуди надсилати запити.
• Push-підписка з увімкненою автентифікацією: Pub/Sub підписує JSON Web Token і надсилає його в заголовку Authorization як Bearer-токен. Посібник Google радить перевірити підпис токена і переконатися, що його claims email та audience збігаються з налаштованими вами значеннями, а приклад коду також вимагає, щоб email_verified мав значення true. Токен може бути давністю до однієї години.
• Push-підписка без автентифікації: будь-що, що може дістатися до URL, здатне надіслати повідомлення у формі RTDN.

Чому Google хоче, щоб ви підтверджували через API

Навіть ідеально автентифікований RTDN не розповідає всієї історії. Посібник Google із налаштування прямо каже, що ці сповіщення лише повідомляють про зміну стану покупки, і щоб отримати повний статус, потрібно викликати Google Play Developer API. Для voidedPurchaseNotification це означає знайти покупку у Voided Purchases API або отримати її поточний стан, перш ніж щось відкликати. Виклик API автентифікується вашим власним сервісним акаунтом, тож його відповідь зловмисник підробити не може.

Скільки коштує підроблене або відхилене повернення

Підроблене сповіщення про повернення коштів, якому ви повірили, коштує вам клієнта, що платить. Ви блокуєте людину, чиї гроші досі у вас, вона відкриває звернення до підтримки, а дехто піде в магазин і попросить те повернення, яке ваша система вже вдала, що надала. Підроблена покупка або продовження коштує в протилежний бік: ви надаєте обчислення на GPU, платні виклики сторонніх API, сховище й виплати авторам під дохід, якого ніколи не було.

Протилежна помилка тихіша і часто більша. Верифікатор, що відхиляє справжні повідомлення через неправильний appAppleId, налаштування sandbox у production або застарілий кореневий сертифікат, втрачає саме ті два процеси повернення коштів, де важать ваші докази. Apple просить дані про споживання протягом 12 годин після CONSUMPTION_REQUEST. Google дає 24 години, щоб відповісти на розгляд chargeback через orders.reviewrefund, а для замовлень, оформлених після August 3, 2026, програний chargeback у Google Play коштує вам ціну покупки за вирахуванням сервісного збору Play, плюс комісію, яку стягує банк покупця.

Не дайте помилці перевірки з'їсти дедлайн

• Зберігайте сирий запит перед перевіркою, щоб відхилене повідомлення ніколи не губилося насправді.
• Надсилайте сповіщення про кожен збій перевірки. Одне підроблене повідомлення є шумом. Коли збоять усі повідомлення одночасно, це ваша власна помилка.
• В Apple можна повторно обробити те, що ви відхилили. Get Notification History повертає оригінальний signedPayload за останні 180 днів, тож виправте верифікатор і проженіть через нього збережені або відновлені payloads ще раз.
• У Google розгляд chargeback, що очікує, існує лише у своєму сповіщенні, тож неправильно налаштований push audience означає пропущений розгляд. Перевіряйте це за допомогою Send Test Message у Play Console після кожної зміни.

RefundHalt перевіряє сповіщення обох магазинів, підтверджує повернення коштів через API магазинів, перш ніж щось змінити, і відповідає на CONSUMPTION_REQUEST та розгляди chargeback у їхні терміни, тож фальшиве повідомлення не коштуватиме вам клієнта, а справжнє не прослизне повз.