Що таке зловживання поверненнями в застосунку?

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

Як прив'язати внутрішню покупку до конкретного користувача?

На Apple згенеруйте UUID і передайте його як appAccountToken, коли починається покупка, а StoreKit прив'язує його до транзакції та повертає в даних транзакції і споживання. У Google Play викличте setObfuscatedAccountId з хешованим значенням, прив'язаним до облікового запису. Обидва зіставляють транзакцію магазину з вашим власним записом користувача без розкриття персональних даних.

Чи можуть Apple або Google сказати мені, що обліковий запис є повторним повертальником?

Не безпосередньо. Google використовує obfuscated account ID для виявлення нетипової активності та блокування частини шахрайства до покупки, а Apple дозволяє подати історію облікового запису під час запиту на споживання, але жоден магазин не вручає вам список повторних повертальників. Ви будуєте його самі зі свого власного реєстру, ключованого на полях ідентичності.

Чому Google блокує мою покупку, коли я встановлюю ідентифікатор облікового запису?

Тому що obfuscated account ID не має містити персональних даних у відкритому вигляді. Зберігання в ньому чогось на кшталт сирої адреси електронної пошти призводить до того, що Google Play блокує покупку. Використовуйте зашифроване значення або односторонній хеш і тримайтеся в межах обмеження 64 characters.

Чи зупиняє оскарження повернень через запит на споживання зловживання?

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

Усі статті

Playbook19 липня 2026 р.8 хв читання

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

Клієнт, який знову і знову вимагає повернення, це не випадковість. Зловживання поверненнями коштує вам повернутих грошей плюс обчислень, які ви вже витратили, і обидва магазини дають вам сигнал ідентичності, appAccountToken від Apple і obfuscated account ID від Google, щоб зв'язати цей патерн докупи.

Турнікет у тьмяному вокзальному холі, крізь який одна постать проходить знову і знову, ілюструючи серійне зловживання поверненнями

Головне

Лише два процеси повернення взагалі дозволяють розробнику подати докази проти зловживання поверненнями: CONSUMPTION_REQUEST від Apple, з вікном 12 hours, і розгляд зворотного платежу в Google Play через Review Refund API, з вікном 24 hours.
appAccountToken від Apple, це UUID, який ви генеруєте та прикріплюєте до покупки, а StoreKit прив'язує його до отриманої транзакції, тож ваш сервер може пов'язати кожне повернення саме з тим обліковим записом, який його зробив.
obfuscated account ID від Google Play, це хешований рядок, обмежений 64 characters, який саме Google використовує для виявлення нетипової активності, як-от багато пристроїв, що купують з одного облікового запису за короткий час.
Зберігання персональних даних у відкритому вигляді в obfuscated account ID від Google призводить до блокування ваших покупок, тож поле має бути зашифрованим значенням або одностороннім хешем, ніколи не сирою адресою електронної пошти.
Поле voidedReason у Google Play позначає friendly_fraud і fraud як причини, відмінні від звичайного повернення типу remorse, що дозволяє спрямовувати повторних зловмисників у чергу на розгляд замість автоматичного шляху повернути-і-забути.
Google повідомляє, що у 2022 заблокувало понад $2 billion шахрайських і зловживальних транзакцій, а поля ідентичності, які живлять цю систему, працюють лише тоді, коли ви заповнюєте їх при кожній покупці.
Кожна повернута покупка, яка зберігає доступ, це обчислення, сховище та витрати на API, за які ви й далі платите з грошей, що вже віддали, а серійний повертальник множить цей рахунок навмисно.

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

Чому зловживання поверненнями, це проблема ідентичності, а не проблема повернень

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

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

Два вікна, де докази змінюють результат

Існує рівно два процеси, у яких будь-що надіслане вами може зрушити рішення. CONSUMPTION_REQUEST від Apple спрацьовує, коли клієнт просить повернення за витратний товар або автопоновлювану підписку, і ви маєте 12 hours на відповідь. Розгляд зворотного платежу в Google Play спрацьовує, коли користувач оскаржує списання у своєму банку, і ви маєте 24 hours, щоб відреагувати через Review Refund API. Кожне інше повернення, 48-hour самообслуговуване повернення в Play, повернення, надане підтримкою, автоматичне повернення за непідтверджену покупку, вирішується без вас.

Обидва ці канали доказів значно сильніші, коли транзакція вже несе ваш ідентифікатор. Інформація про споживання від Apple може містити appAccountToken поряд з історією та витратами облікового запису, а розгляд від Google може спиратися на obfuscated account ID, який він спостерігає від часу покупки. Обліковий запис без ідентифікатора, це обліковий запис без історії, яку можна подати.

Два поля ідентичності, поруч

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

Apple: appAccountToken

appAccountToken, це UUID, який ви генеруєте та передаєте, коли починається покупка. StoreKit пов'язує його з отриманою транзакцією, і він з'являється в даних транзакції, які перевіряє ваш сервер, та в інформації про споживання, яку ви надсилаєте назад під час CONSUMPTION_REQUEST. Оскільки це ваше значення, воно зіставляє транзакцію магазину безпосередньо з обліковим записом у вашій базі даних, без жодної електронної пошти чи імені. Це має бути справжній UUID, а все інше відхиляється. Пізніше Apple додало кінцеву точку Set App Account Token, яка може прикріпити або оновити токен на минулих транзакціях, зокрема на покупках, зроблених поза вашим застосунком, як-от погашення промокодів.

Google Play: obfuscated account ID

Відповідник у Google, це setObfuscatedAccountId, необов'язковий рядок, прив'язаний до облікового запису, що купує. Власна документація Google прямолінійна щодо його призначення: Google Play використовує його для виявлення нетипової активності, як-от багато пристроїв, що роблять покупки з того самого облікового запису за короткий проміжок, і для блокування деяких шахрайських транзакцій, перш ніж вони завершаться. Він обмежений 64 characters і не має нести персональних даних у відкритому вигляді. Збережіть там сиру адресу електронної пошти, і Google одразу заблокує покупку, бо поле очікує зашифроване значення або односторонній хеш. Споріднене поле, setObfuscatedProfileId, існує для застосунків, де один обліковий запис містить кілька профілів.

Поле	Магазин	Тип і обмеження	Хто встановлює	За замовчуванням	Що магазин з ним робить
appAccountToken	Apple	UUID	Ви, при покупці	Не встановлено	Прив'язує транзакцію до вашого користувача, повертається в даних транзакції та споживання
obfuscatedAccountId	Google Play	Хешований рядок, макс. 64 символи	Ви, при покупці	Не встановлено	Виявляє нетипову активність і блокує частину шахрайства до завершення

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

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

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

Далі йде власне зміщення витрат магазином. Від August 3 2026 Google Play переносить ціну покупки та банківські комісії за зворотний платіж на розробника, для замовлень, розміщених після цієї дати. Зворотний платіж, який раніше був здебільшого проблемою Google, стає вашим доходом плюс комісією, а повторний оскаржувач щоразу підвищує це число. Поля ідентичності, це саме те, що дозволяє вам подати в Review Refund API докази для оскарження неправомірної суперечки в межах вікна 24 hours.

Google формулює масштаб прямо: воно повідомляє, що у 2022 заблокувало понад $2 billion шахрайських і зловживальних транзакцій. Це число існує, бо сигнали, серед них obfuscated account ID, були заповнені. Застосунок, який відправляє покупки з порожніми полями ідентичності, відмовляється від цього захисту.

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

Як спіймати повторних повертальників, перш ніж магазин вирішить

Позначайте кожну покупку ідентичністю, яка належить вам

Встановлюйте appAccountToken на кожній покупці StoreKit і setObfuscatedAccountId на кожній покупці Play Billing, обидва згенеровані з вашого власного запису користувача. На Apple використовуйте справжній UUID, зіставлений з обліковим записом. На Google хешуйте ключ облікового запису, щоб жодні персональні дані не подорожували у відкритому вигляді. Робіть це в мить покупки, бо на Google це той єдиний крок, який ви не відновите пізніше.

Ведіть реєстр, ключований на цій ідентичності

Зберігайте кожну покупку, доставку, подію споживання та повернення проти ідентифікатора. Коли надходить CONSUMPTION_REQUEST або розгляд зворотного платежу, повна історія облікового запису, разом з попередніми поверненнями, за один запит від вас. Інформація про споживання від Apple має саме для цього явні поля: consumptionStatus, deliveryStatus, playTime, accountTenure, lifetimeDollarsPurchased та ваш refundPreference.

Читайте voidedReason і спрямовуйте зловмисників інакше

Коли покупку в Google анульовано, поле voidedReason каже вам чому, а friendly_fraud і fraud, це окремі значення від звичайного повернення типу remorse. Спрямовуйте їх у чергу на розгляд і жорсткішу політику, не на той самий автоматичний шлях, що й перше повернення. Власні настанови Google, це модель багаторазових порушень: попередьте першого порушника, вживіть рішучіших заходів щодо повторних і вимкніть покупки для облікового запису, який не припиняє.

Відповідайте у вікні щоразу

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

Сигнал, який ви хочете спіймати	Де він живе	Поле чи процес, що його виявляє
Той самий обліковий запис, багато пристроїв, коротке вікно	Google Play	Виявлення нетипової активності через obfuscated account ID
Цей обліковий запис уже повертав раніше	Ваш реєстр	Історія, ключована на appAccountToken або obfuscated account ID
Контент був доставлений і спожитий	Apple	deliveryStatus і consumptionStatus в інформації про споживання
Суперечка насправді є шахрайством першої сторони	Google Play	значення voidedReason friendly_fraud

Що магазини зроблять і чого не зроблять за вас

Варто бути точним щодо розподілу праці, бо легко припустити, що магазини опікуються зловживанням, а вони здебільшого не кажуть вам, коли не опікуються. Google активно використовує obfuscated account ID, щоб заблокувати частину шахрайства до того, як покупка завершиться, і його системи вловлюють велику частку на рівні платформи. Apple вирішує кожне повернення само і трактує вашу інформацію про споживання як вхідні дані, ніколи як голос. Жоден магазин не веде за вас ваш список зловмисників, не віднімає повернутий витратний товар з вашого балансу і не каже повторному повертальнику ні від вашого імені. Ідентичність, це те, з чим магазин діє на краях, а ви скрізь інде.

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

Поширені запитання

Що таке зловживання поверненнями в застосунку?: Зловживання поверненнями, це коли клієнт неодноразово вимагає повернень після отримання та використання того, що купив, тож він зберігає контент чи вигоду і водночас повертає гроші. У магазинах застосунків це зазвичай виглядає як той самий обліковий запис, що повертає витратні товари чи підписки знову і знову, або як friendly fraud, коли законне списання оскаржується в банку.
Як прив'язати внутрішню покупку до конкретного користувача?: На Apple згенеруйте UUID і передайте його як appAccountToken, коли починається покупка, а StoreKit прив'язує його до транзакції та повертає в даних транзакції і споживання. У Google Play викличте setObfuscatedAccountId з хешованим значенням, прив'язаним до облікового запису. Обидва зіставляють транзакцію магазину з вашим власним записом користувача без розкриття персональних даних.
Чи можуть Apple або Google сказати мені, що обліковий запис є повторним повертальником?: Не безпосередньо. Google використовує obfuscated account ID для виявлення нетипової активності та блокування частини шахрайства до покупки, а Apple дозволяє подати історію облікового запису під час запиту на споживання, але жоден магазин не вручає вам список повторних повертальників. Ви будуєте його самі зі свого власного реєстру, ключованого на полях ідентичності.
Чому Google блокує мою покупку, коли я встановлюю ідентифікатор облікового запису?: Тому що obfuscated account ID не має містити персональних даних у відкритому вигляді. Зберігання в ньому чогось на кшталт сирої адреси електронної пошти призводить до того, що Google Play блокує покупку. Використовуйте зашифроване значення або односторонній хеш і тримайтеся в межах обмеження 64 characters.
Чи зупиняє оскарження повернень через запит на споживання зловживання?: Воно може його зменшити. CONSUMPTION_REQUEST, це один із лише двох процесів, у яких ваші докази досягають магазину, перш ніж він вирішить, а історія облікового запису плюс дані про доставку і споживання допомагають Apple розпізнати зловживання поверненнями та friendly fraud. Це, однак, не блокування. Apple все одно вирішує, а зловживання, що надходить через неоскаржувані процеси, залишається незачепленим.

Джерела та додаткове читання

RefundHalt

Автопілот повернень для App Store і Google Play

Читайте далі

Deep dive7 хв читання

The refunds you cannot contest: what Apple and Google decide without asking you

Only two refund flows ever ask for your evidence: Apple's consumption request and Google Play's chargeback review. Everything else, the 48-hour Play refund, support refunds, voided purchases, unacknowledged trials, is decided without you. Here is the full map, what you can prevent, and what you can only record.

Deep dive8 хв читання

Apple's CONSUMPTION_REQUEST, explained: the 12 hours that decide your refund

When a customer asks Apple for a refund, Apple asks you first. Here's exactly what the CONSUMPTION_REQUEST notification contains, what Apple expects back, how to answer one end to end, and why most developers silently forfeit.