Скасування доступу після повернення коштів: крок, який Apple і Google не роблять за вас

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

Чому повернення коштів не revoke доступ за замовчуванням

І Apple, і Google трактують гроші та доступ як дві різні операції. Грошова частина, це політика магазину: щойно повернення коштів схвалено, воно остаточне, і облік оновлюється. Частина з доступом є опційною, або обов'язком розробника, або і тим, і іншим, залежно від платформи та типу покупки. Жоден магазин не припускає, що ви хочете, щоб доступ зник тієї ж миті, коли пройшло повернення коштів, адже багато законних випадків (часткове повернення коштів, кредит доброї волі, жест підтримки) взагалі не мають забирати продукт.

Google Play: прапорець, якого ніхто не помічає

У Play Console повернення коштів за замовлення, це форма з двох частин: спершу обираєте суму повернення, а потім окремо вирішуєте, чи позначати "Remove entitlement". Залишити прапорець непозначеним, це типовий шлях для більшості агентів підтримки, бо більшість запитів на повернення коштів є жестами доброї волі, коли клієнт залишає собі те, що купив. Проблема в тому, що на екрані підтвердження повернення коштів ніщо не попереджає, що так само клієнт залишає собі підписку чи товар усередині застосунку після повернення коштів, яке мало бути остаточним.

Шлях через API має ту саму пастку

Такий самий вибір існує і в коді. Ендпоінт orders.refund приймає необов'язковий параметр запиту revoke; коли він true, доступ до товару припиняється негайно, а для підписки з повторюваними платежами разом із цим скасовується кожен майбутній платіж. Якщо параметр опустити, він за замовчуванням дорівнює false: повернення коштів проходить, запис про покупку оновлюється, а користувач продовжує користуватися продуктом точно так само, як і раніше.

Саме останній рядок і підловлює інтеграції. Voided Purchases API існує для того, щоб ви могли побудувати конвеєр скасування доступу без ручного опитування Play Console, але він показує лише замовлення, які справді було анульовано зі скасуванням доступу. Повернення коштів, оброблене без прапорця, або без revoke=true, невидиме для цього фіду за задумом, а не через баг.

Читання поля voidedReason Коли покупка справді з'являється як voided, поле voidedReason повідомляє чому, за шкалою з дев'яти значень: other, remorse, not_received, defective, accidental_purchase, fraud, friendly_fraud, chargeback і unacknowledged_purchase. Це не просто облік. Remorse і accidental_purchase, це звичайні повернення коштів. Fraud, friendly_fraud і chargeback варто скеровувати в чергу перевірки на шахрайство, а не просто revoke і забути, бо той самий обліковий запис статистично з більшою ймовірністю повторить це знову.

Одна операційна деталь має значення, якщо ви будуєте систему прямо на основі цього фіду: purchases.voidedpurchases.list обмежено 6000 запитів на день і 30 запитів у будь-якому 30-секундному вікні. Дизайн, який опитує систему в щільному циклі, швидко впирається у цю стелю; передбачений патерн, це планове опитування з токенами пагінації, а не безперервний polling.

Apple: App Store може revoke ліцензію, але не витратний товар

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

Чому витратні товари є винятком

Невитратний товар або підписка мають постійне право доступу, яке системи Apple можуть вимкнути. У витратного товару такого немає: щойно він використаний, він вважається доставленим, і в StoreKit більше нічого не залишається revoke. Якщо клієнт купив 500 монет, витратив їх і отримав повернення коштів, з погляду Apple монети вже зникли. Єдиний облік, де вони ще є, це ваш. Сповіщення REFUND, це ваш єдиний сигнал знайти відповідний original transaction ID і списати цей баланс зі своїх власних записів; на боці Apple ніхто не зробить цього за вас.

Сповіщення, яке майже ніхто не обробляє

REFUND_REVERSED, це те сповіщення, яке більшість інтеграцій пропускають повністю, бо воно описує ситуацію, коли Apple скасовує власне рішення, а це випадок, до якого мало хто з розробників готується із самого початку. Коли воно надходить, revocationDate у транзакції повертається до null: наскільки це стосується Apple, покупка знову дійсна. Якщо ваш сервер видалив право доступу, скасував запис підписки або обнулив баланс витратного товару, коли надійшов початковий REFUND, то REFUND_REVERSED, це сигнал повернути все назад.

Як закрити цю прогалину, крок за кроком

• У Google Play зробіть revoke=true типовим значенням для кожного шляху повернення коштів, чи то через Play Console, чи через API, якщо тільки конкретний випадок підтримки не вимагає, щоб клієнт зберіг доступ.
• Опитуйте purchases.voidedpurchases.list за розкладом із токенами пагінації, а не в щільному циклі, і тримайтеся в межах менше ніж 6000 запитів на день і 30 за 30 секунд.
• Скеровуйте значення voidedReason на кшталт fraud, friendly_fraud і chargeback у чергу перевірки, замість автоматичного revoke із закриттям справи.
• На боці Apple підпишіться на App Store Server Notifications V2 і revoke доступ до non-consumable товару та підписки в момент, коли сповіщення REFUND називає їх.
• Зберігайте original transaction ID для кожної покупки витратного товару, щоб сповіщення REFUND могло знайти точний баланс для списання без ручного пошуку.
• Явно обробляйте REFUND_REVERSED і фіксуйте кожне скасування доступу з прив'язкою до його transaction ID або order ID, щоб скасування могло точно відновити те, що було прибрано.

Скільки насправді коштує ця прогалина

Усе це не про справедливість щодо клієнта; це про те, що продовжує працювати після того, як гроші вже пішли. Повернена підписка, яка продовжує викликати ваш API, зберігати дані та споживати обчислювальні ресурси, це не моральна проблема, це рядок у витратах: ви оплачуєте рахунок за інфраструктуру для покупки, за яку вже повернули дохід. Магазини не відстежують цю вартість за вас, бо з їхнього боку повернення коштів завершене в ту мить, коли рухаються гроші. Частина з доступом повністю на вашому рахунку і під вашим контролем.

Це та сама причина, чому RefundHalt трактує скасування доступу як частину конвеєра повернення коштів, а не як щось другорядне: подія REFUND і зміна доступу фіксуються як одна дія, а подія REFUND_REVERSED автоматично відновлює стан, замість того щоб чекати, поки хтось помітить, що клієнт досі не має доступу до того, що Apple вже повернула.