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

Пропущені сповіщення про повернення коштів непомітно позбавляють розробника голосу в тих двох рішеннях про повернення, де він узагалі може його мати. І CONSUMPTION_REQUEST від Apple, і перевірка чарджбеку в Google Play починаються зі сповіщення, і обидва процеси мають короткий термін: 12 годин в Apple, 24 години в Google. Якщо в момент надходження повідомлення ваш сервер не працює, повільно відповідає або неправильно налаштований, магазин не чекатиме. Він ухвалить рішення на основі того, що вже має.

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

Як кожен магазин доставляє сповіщення про повернення коштів

Apple надсилає App Store Server Notifications безпосередньо на HTTPS URL, який ви вказуєте в App Store Connect. Google не звертається до вашого сервера напряму. Він публікує Real-time developer notifications у topic Google Cloud Pub/Sub, а ваша підписка на цей topic або надсилає їх (push) на ваш ендпоінт, або чекає, поки сервер сам їх забере (pull).

Що Apple вважає невдачею

Документація Apple конкретна. Поверніть будь-який статус від 200 до 206, і доставку завершено. Поверніть 40x або 50x, і Apple повторить спробу. Будь-який інший код Apple теж вважає невдалим. Кожну спробу записують із полем sendAttemptResult, і його значення читаються як перелік реальних збоїв: TIMED_OUT, TLS_ISSUE, CIRCULAR_REDIRECT, NO_RESPONSE, PREMATURE_CLOSE, UNSUCCESSFUL_HTTP_RESPONSE_CODE і ще кілька. Щодо TIMED_OUT Apple радить перевірити, чи не обробляє ваш сервер повідомлення ще до відповіді.

Що Google вважає невдачею

У push-підписці код успіху від вашого ендпоінта і є підтвердженням. У pull-підписці сервер має підтвердити кожне отримане повідомлення, інакше Pub/Sub доставить його знову. Стандартний термін підтвердження становить 10 секунд, максимальний 600 секунд. Посібник Google з RTDN додає ще одне правило, яке варто повторити: сповіщення лише повідомляє, що щось змінилося, тож повний стан покупки все одно треба отримати через Google Play Developer API.

Чому графік повторів Apple не вкладається у 12-годинне вікно

Інтервали повторів Apple відраховують від попередньої спроби, а не від першої. Якщо їх скласти, для одного сповіщення V2, яке ваш сервер раз у раз не приймає, вийде така хронологія.

Apple просить відповісти протягом 12 годин після отримання CONSUMPTION_REQUEST. Якщо ваш сервер не працював під час першої доставки і повтору через годину, наступна спроба надійде через 13 годин після першої. Apple не уточнює, чи отримує запит, уперше прийнятий під час повтору, нові 12 годин. Обережніше вважати, що відлік почався з першої спроби. Отже, самі лише повтори не врятують запит, який ви пропустили більш ніж на годину.

Чи повторює Apple доставку після HTTP 400?

Так, згідно з документацією. Apple називає 40x і 50x кодами, що запускають повтор. У березні 2026 року один розробник написав на форумах Apple, що повтори після відповідей 400 начебто припинилися, потім повідомив, що доставка відновилася через день чи два, і Apple попросила надіслати звіт через Feedback Assistant. Вважайте задокументовану поведінку правилом, а власний моніторинг доказом.

Відновлюйте пропущені сповіщення App Store через Get Notification History

Get Notification History повертає сповіщення версії 2, які Apple намагалася надіслати на ваш сервер за обраний вами проміжок часу. Кожен запис містить повний підписаний payload, тож його можна передати тому самому обробнику, що й живе сповіщення. Кожен запис також має масив sendAttempts до шести елементів: один для першої спроби і по одному для кожного з п'яти повторів.

• startDate і endDate обов'язкові, а startDate має бути в межах останніх 180 днів у продакшні або останніх 30 днів у sandbox.
• Установіть onlyFailures у true, щоб отримати лише сповіщення, які не дійшли до вашого сервера, а також ті, доставку яких Apple ще повторює.
• Фільтруйте за одним notificationType, наприклад CONSUMPTION_REQUEST або REFUND, або за transactionId одного клієнта, але не за обома в одному запиті.
• Кожен виклик повертає до 20 записів. Продовжуйте викликати з paginationToken, поки hasMore дорівнює true, і щоразу надсилайте те саме тіло запиту.

Для повернень коштів важливе одне застереження. Apple зазначає, що записи історії відображають стан покупки на момент першого надсилання сповіщення, а не поточний. Тож відновлений REFUND є фактом про минуле. Перш ніж відкликати доступ, перевірте поточний стан через ендпоінти статусу транзакції або підписки.

Сповіщення V1 так відновити не вдасться

Get Notification History охоплює лише версію 2. Сповіщення V1 Apple повторює тричі, через 6, 24 і 48 годин після попередньої спроби, і якщо всі вони невдалі, історії для повторного відтворення немає. Це ще одна причина перевести на V2 кожен застосунок, який досі працює на V1.

Відновлюйте пропущені сповіщення Google Play про повернення коштів

Страховкою в Google є сам Pub/Sub. Поки існує ваша підписка, повідомлення, яке ніхто не підтвердив, лишається там протягом терміну зберігання: 7 днів за замовчуванням і до 31 дня, якщо його збільшити. Щойно ваш ендпоінт знову запрацює, доставка відновиться. Два налаштування можуть непомітно звести це нанівець.

• Dead-letter topic переносить повідомлення з вашої підписки після заданої кількості невдалих спроб доставки. За замовчуванням це 5, і зі стандартною політикою негайної повторної доставки п'ять спроб можуть минути дуже швидко. Якщо ви його використовуєте, стежте за dead-letter topic як за другою поштовою скринькою.
• Підписка без активності підписника, тобто без відкритих з'єднань, активних pull-запитів чи успішних push-доставок, за замовчуванням спливає через 31 день. Ендпоінт, який не працює місяць, може втратити саму підписку разом з усім, що в ній чекало.

Для скасованих покупок є 30-денний резерв

Для повернень, які вже відбулися, резервом на основі pull є Voided Purchases API. Він показує скасовані покупки за останні 30 днів, до 1000 на сторінку, з квотою 6000 запитів на день і 30 запитів за будь-які 30 секунд для кожного застосунку. Передайте type 1, щоб разом з одноразовими продуктами отримати й підписки. Щоденний запуск виявляє кожне повернення, яке пропустив ваш конвеєр сповіщень, і тримає доступи та цифри доходу точними.

Для перевірок чарджбеків резерву немає

PendingRefundReviewNotification працює інакше. Воно містить pendingRefundToken, який треба передати в orders.reviewrefund, і з моменту отримання у вас є 24 години, щоб надіслати свою позицію щодо повернення та докази використання. Google фіксує ваш перший виклик і ігнорує решту. Документація Google не описує жодного ендпоінта зі списком очікуваних перевірок, тож якщо це повідомлення Pub/Sub загубиться, разом із ним загубляться й ваші докази для цього чарджбеку.

Скільки коштує пропущене сповіщення про повернення

Пропущене сповіщення про вже остаточне повернення коштує вам лише облікової роботи. Ви знаходите його пізніше у Voided Purchases API або Get Notification History, відкликаєте доступ, якщо цього вимагає ваша політика, і звіти наздоганяють реальність. Неприємно, але дешево.

Пропущене сповіщення в одному з двох процесів, які можна оскаржити, коштує реальних грошей, бо магазин вирішує без ваших доказів. В Apple це означає, що рішення про повернення ухвалюють без ваших даних про споживання. У Google Play для замовлень, оформлених після 3 серпня 2026 року, програний чарджбек коштує вам ціни покупки за вирахуванням сервісного збору Play, плюс комісії за чарджбек, яку стягує банк покупця. Google покриває лише власний сервісний збір.

А гроші, які ви витратили на надання покупки, зникли ще до початку суперечки.

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

Нічого з цього не повертається, коли повернення коштів проходить. Докази, які ви надсилаєте протягом цих 12 або 24 годин, є вашим єдиним важелем, і пропущене сповіщення забирає його.

Надійна процедура відновлення

• Спочатку підтверджуйте. Збережіть сирий payload, поверніть код успіху, а потім обробіть його в черзі.
• Кожні кілька хвилин опитуйте Get Notification History від Apple з onlyFailures щодо CONSUMPTION_REQUEST, щоб збій коштував лише кількох хвилин 12-годинного вікна.
• Щодня запускайте перевірку Get Notification History з onlyFailures за останні кілька днів для всіх типів і повторно обробляйте знайдене.
• Щодня викликайте Voided Purchases API з type 1 для кожного застосунку в Google Play і звіряйте результат із уже записаними поверненнями.
• У Pub/Sub тримайте термін зберігання повідомлень 7 днів або більше, налаштуйте сповіщення для dead-letter topic, якщо він є, і сповіщення про накопичення недоставлених повідомлень.
• Перевіряйте весь шлях також у продакшні. Sandbox від Apple надсилає кожне сповіщення один раз без повторів, а Request a Test Notification разом із Get Test Notification Status точно показують, як відповів ваш сервер.

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