Причини скасування підписки зазвичай надходять до вас раніше за запит на повернення коштів, і Google Play передає їх значно більше, ніж Apple

Більшість підписників, які зрештою отримують повернення коштів, спершу скасовують підписку. Це скасування має причину, і два магазини передають її в дуже різному обсязі. Google Play проводить коротке опитування й надсилає відповідь на ваш сервер, разом із довільним текстом. Apple надсилає числовий код, який каже, як закінчилася підписка, а не чому клієнт захотів піти. Читайте обидва сигнали правильно, і ви побачите запити на повернення заздалегідь, поки ще можна щось зробити.

Що Google Play повідомляє про причини скасування підписки

Коли користувач скасовує підписку в центрі підписок Play, Google запитує його про причину. Відповідь потрапляє до ресурсу підписки, який ви отримуєте з purchases.subscriptionsv2.get, у поле canceledStateContext. Цей об'єкт існує лише поки підписка скасована або завершилася, і він показує, хто її завершив: користувач, система Google, ви або заміна, наприклад зміна тарифу.

Якщо скасував користувач, об'єкт userInitiatedCancellation містить два поля. cancelTime показує час скасування. cancelSurveyResult містить відповідь на опитування.

Права колонка відображає наше тлумачення, а не позицію Google. Перші дві колонки взято безпосередньо з довідника API.

У сповіщенні немає причини

Скасована підписка запускає сповіщення для розробників у реальному часі SUBSCRIPTION_CANCELED, тип 3. Google прямо зазначає, що такі сповіщення повідомляють лише про зміну стану покупки. Payload містить токен покупки і більше нічого корисного, тож ваш обробник має викликати purchases.subscriptionsv2.get, щоб прочитати відповідь на опитування.

Що видно в Play Console

Для загальних цифр код не потрібен. Звіти про підписки в Play Console мають картку «Скасування», яка ділить відтік на добровільний, недобровільний та інший, і картку з відповідями на опитування про скасування від користувачів, які вирішили відповісти. Текстові відповіді тих, хто обрав «інше», можна завантажити у CSV з картки «Інші відповіді». Для завантаження потрібен дозвіл View financial data, той самий, який ви надали б інструменту, що читає ваші замовлення.

Що повідомляє Apple і про що мовчить

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

Код 1 єдиний описує рішення клієнта, і він нічого не каже про мотив. Клієнт, який пішов через постійні збої застосунку, і клієнт, який просто завершив проєкт, виглядають однаково.

Сигнал, прихований в AUTO_RENEW_DISABLED

Одне сповіщення Apple варто розглянути уважніше. DID_CHANGE_RENEWAL_STATUS з підтипом AUTO_RENEW_DISABLED зазвичай означає, що клієнт вимкнув автопродовження. Документація Apple додає другий випадок: App Store теж вимикає автопродовження після того, як клієнт запросив повернення коштів.

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

Apple і Google поруч

Де скасування перетворюється на повернення коштів

Скасування зупиняє наступне списання. Останнє воно не повертає. Чи повернуться гроші, залежить від того, у який процес повернення клієнт потрапить далі, а більшість таких процесів відбувається без вас.

• У Google Play покупець може сам отримати повернення протягом 48 годин після покупки, і рішення ухвалює Google.
• Про повернення через підтримку Google або Apple вирішує магазин.
• CONSUMPTION_REQUEST від Apple запитує ваші дані про споживання, строк 12 годин.
• Перевірка чарджбека в Google Play запитує докази через orders.reviewrefund, строк 24 години. Рішення банку щодо чарджбека остаточне.

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

Скільки вам коштує кожна причина

Відповідь на опитування також приблизно показує, скільки вже коштувало обслуговування акаунта. Саме ці гроші залишаються на вас у разі повернення.

Технічні проблеми

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

Вартість

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

Мало користується

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

Знайшов кращий застосунок

Ці клієнти рідко щось оскаржують. Вони пішли до конкурента. Причина корисна для продуктових рішень і майже ніколи для захисту від повернень.

Порядок роботи з причинами скасування

• За кожного SUBSCRIPTION_CANCELED з Google Play викликайте purchases.subscriptionsv2.get і зберігайте canceledStateContext разом із токеном покупки та cancelTime.
• Зберігайте reasonUserInput дослівно, коли причина «інше». Це єдиний довільний текст, який дає будь-який із магазинів.
• За кожного DID_CHANGE_RENEWAL_STATUS від Apple з AUTO_RENEW_DISABLED записуйте подію в лог і вивантажуйте дані про використання акаунта на випадок, якщо надійде CONSUMPTION_REQUEST.
• За кожного сповіщення EXPIRED від Apple записуйте підтип і expirationIntent, щоб добровільний відтік і помилки оплати не змішувалися.
• За скасувань у Google Play через технічні проблеми перевіряйте журнали помилок цього акаунта й зв'язуйтеся з клієнтом до того, як він піде до банку.
• Ведіть журнали використання для кожного акаунта, щоб на CONSUMPTION_REQUEST відповісти протягом 12 годин, а на перевірку чарджбека протягом 24.