Виявлення повернень у StoreKit 2 зводиться до однієї властивості транзакції, і це revocationDate

Більшість застосунків дізнаються про повернення Apple від свого сервера, через App Store Server Notification, і не помічають, що те саме повернення вже перебуває всередині застосунку. Воно в транзакції, у властивості під назвою revocationDate, і читання його дозволяє вашому застосунку відключити доступ клієнту з поверненням при наступному відкритті, замість очікування серверного завдання. Виявлення повернень StoreKit 2, це клієнтський сигнал, який більшість команд пропускає. Ось де саме повернення проявляється на пристрої, що воно вам каже, чого не каже, і чому воно має бути поруч із серверними сповіщеннями, а не замість них.

Де повернення з'являється всередині StoreKit 2

StoreKit 2 передає вам транзакції як підписані значення, і повернення не видаляє транзакцію. Воно позначає її. Дві властивості в Transaction несуть цю позначку, і обидві залишаються nil протягом усього життя здорової покупки. Коли одна з них стає непорожньою, App Store забрав покупку назад.

revocationDate, це поле, яке змінюється

revocationDate, це опціональна Date. Власний опис Apple точний: це дата, коли App Store повернув гроші за транзакцію або відкликав її з Family Sharing. Для покупки, яка все ще в порядку, це nil. У момент обробки повернення воно зберігає позначку часу цього повернення. Ця єдина перевірка, чи непорожній revocationDate, і є все клієнтське виявлення повернень. Усе інше, це нюанси поверх неї.

revocationReason повідомляє, чому Apple відкликав покупку

revocationReason розташований поруч із датою і пояснює причину. StoreKit дає йому два значення, важливі для повернень. developerIssue означає, що клієнт повідомив Apple, що повернення було спричинене реальною або уявною проблемою у вашому застосунку. other охоплює всі інші причини. Третє значення, upgradedToBundle, зовсім не повернення; воно позначає транзакцію, яку App Store відкликав, тому що клієнт перейшов на пакет підписки. Читайте причину, перш ніж діяти, тому що developerIssue, це та, яку варто рахувати: їх скупчення, це ваш власний продукт, що каже вам, де він зламався.

currentEntitlements уже виключає повернену покупку

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

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

Виявлення повернень StoreKit 2 на практиці, під час запуску і поки застосунок працює

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

Почніть слухати під час запуску, інакше ви пропустите повернення, що сталися при закритому застосунку

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

Покупка на тому самому пристрої не приходить через updates

Одна пастка ловить тих, хто тестує повернення вручну. Звичайна покупка, зроблена на тому самому пристрої, не приходить через updates; StoreKit повертає її прямо з результату виклику покупки. updates потрібен для позасмугових змін: повернень, схвалень Ask to Buy, погашень промокодів і покупок, зроблених в іншому місці. Тож будуйте обробку повернень навколо updates і currentEntitlements, а не навколо процесу покупки, тому що повернення ніколи не повернеться тим шляхом, яким пройшов продаж.

Чого клієнтське виявлення не може зробити за вас

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

revocationDate не завжди повернення

Те саме поле змінюється через Family Sharing. Коли клієнт втрачає доступ до спільної покупки, тому що організатор видалив його або обмін закінчився, ця транзакція теж отримує revocationDate. Тож непорожня дата означає, що клієнт більше не має цієї покупки, що якраз те, що вам потрібно для контролю доступу, але це не завжди означає, що гроші повернулися. Якщо ви рахуєте повернення для доходу, відокремте відкликання Family Sharing від справжніх, перш ніж довіряти цифрі.

Повернення можна скасувати

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

У що насправді обходиться пізнє відкликання

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

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

Використовуйте клієнт для швидкості, а сервер для істини

Чиста архітектура використовує обидва сигнали для того, у чому кожен добрий. На пристрої Transaction.updates і currentEntitlements дають вам миттєву локальну реакцію в момент, коли клієнт з поверненням відкриває застосунок, що добре для інтерфейсу і для завершення змін прав без звернення до сервера. На сервері App Store Server Notifications V2 надсилають повідомлення REFUND, яке приходить незалежно від того, чи відкриють застосунок знову, і це єдиний сигнал, який надійно зупиняє витрати вашого бекенду на акаунт з поверненням.

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