Retention Messaging API від Apple виводить ваш текст на екран скасування, але запити на повернення коштів через нього не проходять

Підписникам, які натискають «Скасувати» на iPhone, тепер можна показати вибране вами повідомлення, дешевший план або знижку ще до підтвердження. Це Retention Messaging API від Apple, і вперше розробник має голос на власному екрані скасування Apple. Це досі попередня версія, до якої треба подати заявку. І вона має жорстку межу, важливу для всіх, кого турбують повернення коштів: вона звертається до людей, які збираються припинити платити, а не до тих, хто просить гроші назад. Такі запити йдуть до Apple іншим шляхом.

Що робить Retention Messaging API від Apple

Retention Messaging API це сервіс типу «сервер до сервера». Ви заздалегідь завантажуєте до Apple тексти й зображення повідомлень, Apple їх перевіряє, а потім ви вибираєте, яке схвалене повідомлення побачить підписник, коли збирається скасувати автопоновлювану підписку. У документації Apple наведено чотири типи повідомлень:

• Текстове повідомлення, яке може містити маркований список.
• Текстове повідомлення із зображенням.
• Повідомлення про зміну плану, яке пропонує іншу підписку з тієї самої групи підписок.
• Повідомлення з промоакцією, яке пропонує знижену ціну на тому самому або іншому рівні. Для цього використовується промоакція, яку ви налаштовуєте в App Store Connect і підписуєте на своєму сервері.

Повідомлення з'являється після того, як клієнт натискає Cancel Subscription на сторінці з деталями підписки. Потім Apple показує сторінку Confirm Cancellation (Підтвердити скасування). Клієнт усе одно може скасувати, натиснути Keep Subscription (Залишити підписку) або прийняти запропоновану вами пропозицію чи план. Приховати вихід не можна, і Apple просить розробників не завантажувати оманливий або неточний контент.

Повідомлення за замовчуванням і потік реального часу

Є два способи роботи. Простий: повідомлення за замовчуванням, тобто текст із зображенням або маркованим списком чи без них, призначений кожному продукту та локалі. Розширений: потік реального часу, у якому Apple викликає ендпоінт Get Retention Message на вашому сервері, а ви відповідаєте ідентифікатором повідомлення. Лише потік реального часу може показувати повідомлення про зміну плану та промоакції.

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

Що Apple передає вашому серверу у виклику в реальному часі

Запит є JWS, підписаним App Store. Після декодування він містить originalTransactionId, appAppleId, productId, userLocale, requestIdentifier у форматі UUID, середовище та signedDate. Apple радить перевіряти, що appAppleId відповідає вашому застосунку, і не відповідати, якщо це не так. Найкорисніше тут originalTransactionId: за ним можна подивитися, що цей підписник насправді робив у вашому застосунку, перш ніж вибрати, що йому сказати.

Де з'являється повідомлення для утримання, а де ні

Apple розміщує повідомлення на одному екрані: це крок Confirm Cancellation після натискання Cancel Subscription, наприклад з Apple Account > Subscriptions або зі сторінки підписки в App Store. Цей екран вирішує, чи відбудеться наступне продовження. Уже отриманих грошей він не стосується.

Запит на повернення коштів це окрема дія. Сторінка підтримки Apple направляє клієнтів на reportaproblem.apple.com, де вони вибирають "Request a refund" (Запит на повернення коштів), причину та покупку, а потім чекають на відповідь від 24 до 48 годин. У вашому застосунку beginRefundRequest зі StoreKit відкриває вікно повернення коштів Apple, і Apple зазначає, що App Store схвалює або відхиляє запит протягом 48 годин. Жоден із цих шляхів не проходить через екран Confirm Cancellation.

Чи може повідомлення для утримання зупинити запит на повернення коштів?

Ні. Запит на повернення коштів ніколи не доходить до екрана, де живе повідомлення. Одна деталь у документації Apple щодо сповіщень робить це наочним. Коли клієнт запитує повернення коштів через ваш застосунок за допомогою API запиту на повернення, Apple сама вимикає автопродовження і надсилає DID_CHANGE_RENEWAL_STATUS з підтипом AUTO_RENEW_DISABLED. Клієнт, який скасовує підписку зі сторінки налаштувань підписок, породжує той самий тип і підтип. Ваш сервер бачить одне сповіщення для двох дуже різних клієнтів, і лише один із них бачив ваше повідомлення для утримання.

Якщо запит на повернення коштів рухається далі, каналом для доказів є CONSUMPTION_REQUEST. Apple надсилає його для запитів на повернення за будь-яким типом продукту, і у вас є 12 годин, щоб відповісти через Send Consumption Information. Відповідати можна лише за згоди клієнта. Після цього рішення Apple надходить як сповіщення REFUND або як REFUND_DECLINED, якщо Apple відхиляє повернення, яке клієнт ініціював у вашому застосунку.

Чи є в Google Play API для повідомлень при скасуванні?

У документації Google про життєвий цикл підписок його немає. Підписник Google Play скасовує підписку в центрі підписок Play, зберігає доступ до кінця поточного платіжного циклу і до того може натиснути Resubscribe (Відновити підписку), щоб скасувати скасування. Google називає це відновленням. Ви дізнаєтеся про скасування пізніше зі сповіщення SUBSCRIPTION_CANCELED, а поле userInitiatedCancellation у ресурсі підписки показує, чому користувач пішов. Пауза, яка, за словами Google, увімкнена за замовчуванням для всіх підписок, є головним вбудованим способом зменшити добровільний відтік.

Щодо повернень коштів, у Google Play є власний канал для доказів. PendingRefundReviewNotification надходить, коли чарджбек потребує перевірки розробником, і у вас є 24 години, щоб відповісти через orders.reviewrefund. Для замовлень, зроблених після 3 серпня 2026 року, Google перекладає на розробника ціну покупки за вирахуванням сервісного збору Play, а також комісії банку за чарджбек, коли чарджбек проходить.

Скільки грошей коштує вам екран скасування

Повідомлення для утримання здаються безкоштовними. Це не так, і рахунки приходять з трьох боків.

Обчислення при кожному перегляді сторінки

Apple викликає ваш ендпоінт, коли активний підписник відкриває сторінку з деталями підписки та кнопкою скасування, а не лише тоді, коли він скасовує. Кожен візит означає запит, який ваш сервер має автентифікувати, обробити й відповісти на нього протягом 700 ms, інакше Apple покаже повідомлення за замовчуванням. Це виключає функцію з холодним стартом, яка іноді працює дві секунди. Ви платите за постійно «теплі» потужності, а також за всі читання з бази даних і платні виклики сторонніх API, які ваша логіка рішень робить на кожен запит.

Знижка це дохід, від якого ви відмовилися

Промоакція, яка втримує підписника, зберігає реальні гроші. Промоакція, яка дісталася тому, хто й так залишився б, це чиста знижка. Ось ілюстрація, а не еталон. Місячний план за $9.99 за половину ціни протягом трьох місяців коштує вам $14.99 за кожну прийняту пропозицію. Якщо кожен третій із тих, хто її прийняв, залишився б і за повною ціною, тисяча прийнятих пропозицій означає близько $5,000 знижки, відданої людям, яким вона не була потрібна. Інший бік балансу: підписники, які справді збиралися піти.

Повернення коштів, яке провокує незручний вихід

Apple залишає кнопку Cancel Subscription на сторінці, тож нікого не можна загнати в пастку, але дратувати все ще можна. Клієнт, який відчуває тиск, має інший варіант: попросити Apple повернути останній платіж. Коли повернення відбувається, гроші йдуть назад, а витрати на обчислення, зберігання, виклики API та будь-які партнерські виплати, пов'язані з цим підписником, уже зроблено. Жодне повідомлення для утримання цих витрат не поверне.

Як використовувати повідомлення для утримання, не збільшуючи частку повернень

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

• Вирішуйте для кожного підписника окремо. Використовуйте originalTransactionId із запиту Apple, щоб переглянути нещодавнє використання. Пропонуйте знижку або дешевший план тим, хто користується продуктом. Тим, хто не відкривав його тижнями, покажіть коротке чесне повідомлення.
• Відповідайте швидко. Прораховуйте рішення заздалегідь, коли змінюються дані про використання, щоб сам запит зводився до одного пошуку, який легко вкладається в 700 ms.
• Напишіть повідомлення за замовчуванням для кожного продукту та локалі. Без нього невдалий виклик означає, що повідомлення не буде взагалі.
• Уважно стежте за AUTO_RENEW_DISABLED. Якщо далі надходить CONSUMPTION_REQUEST для того самого originalTransactionId, перед вами запит на повернення коштів, а не скасування, і 12-годинний відлік уже почався.
• Відповідайте на кожен CONSUMPTION_REQUEST, на який маєте право відповісти. RefundHalt надсилає Apple точні дані про споживання в межах 12-годинного вікна і відповідає на перевірку чарджбеків Google Play протягом 24 годин, бо це єдині два моменти, коли будь-який із магазинів запитує вашу позицію.

Чи варто просити в Apple доступ?

Якщо ви продаєте автопоновлювані підписки і вже обробляєте App Store Server Notifications V2, імовірно, так. Екран скасування це останнє місце, де можна звернутися до підписника перед його відходом, а зміна плану коштує вам менше, ніж повна втрата клієнта. Лише закладіть у бюджет ендпоінт, який відповідає на кожен перегляд сторінки підписки, і тримайте захист від повернень там, де повернення справді відбуваються.