Позначайте кожну покупку в Google Play заплутаним ідентифікатором облікового запису, інакше зворотний платіж прийде без жодного способу його відстежити

Перегляд зворотного платежу в Google Play з'являється, називаючи замовлення і токен покупки. Він не каже вам, хто клієнт. Якщо ви ніколи не відбили на тій покупці власний ідентифікатор, ви тепер зіставляєте голий номер замовлення зі своєю таблицею користувачів під годинником на 24 години і маєте відповісти доказами споживання, які, можливо, не зможете знайти. Заплутаний ідентифікатор облікового запису це вирішення. Це короткий рядок, який ви прикріплюєте на касі і який Google Play зберігає разом із покупкою та повертає вам пізніше, тож кожне замовлення можна відстежити до саме того користувача, який його здійснив. Ось що це за поле, чому воно взагалі вирішує, чи зможете ви відповісти на спір, і скільки коштує його пропустити тепер, коли програний зворотний платіж це рахунок.

Що таке заплутаний ідентифікатор облікового запису насправді

Заплутаний ідентифікатор облікового запису це один необов'язковий рядок, який ви передаєте в потік виставлення рахунків Google Play, коли клієнт щось купує. Ви встановлюєте його за допомогою setObfuscatedAccountId на будівнику BillingFlowParams, і Google зберігає його поруч із покупкою. Це не ім'я клієнта, не його електронна пошта і не його обліковий запис Google. Це ваш власний ідентифікатор вашого власного користувача, записаний у формі, яку Google може зберігати, не дізнаючись, хто ця особа.

Це рядок, який ви встановлюєте на касі, а не ім'я

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

Google зчитує його спершу для власної перевірки на шахрайство

Перш ніж воно взагалі стане корисним для вас, це поле виконує роботу для Google. Документація з виставлення рахунків каже, що Google Play може використати це значення, щоб виявити нетипову активність, як-от багато пристроїв, що здійснюють покупки на одному обліковому записі за короткий проміжок часу, і що Google використовує ці дані, щоб виявити підозрілу поведінку і заблокувати деякі типи шахрайських транзакцій, перш ніж їх буде завершено. Тож перша вигода від встановлення лежить вище за течією, у чистіших покупках і меншій кількості тих шахрайських, які пізніше перетворюються на скасування та спори. Google перелічує заплутаний ідентифікатор облікового запису і Voided Purchases API разом як два своїх основних інструменти проти зловживань не просто так.

Чому це важливо, коли надходить перегляд зворотного платежу

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

Спір називає замовлення, а не особу

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

Про що насправді просить вас orders.reviewrefund

Відповісти на спір означає викликати метод orders.reviewrefund протягом 24 годин. Google записує ваш перший виклик і ігнорує решту, тож перша відповідь це єдина відповідь. Ось поля, які воно хоче, і кожне з полів доказів припускає, що ви вже знаєте, якому користувачеві належить замовлення.

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

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

Пройдімо одне замовлення. Клієнт оскаржує покупку на $9.99 у своєму банку. Google Play надсилає перегляд, і у вас є 24 години. Якщо ви позначили покупку, ви знаходите користувача, бачите, що він спожив більшу частину того, що купив, і відповідаєте на reviewrefund із перевагою DECLINE та доказами споживання, даючи Google справжню справу, щоб оскаржити незаконний спір. Якщо ви не позначили її, ви або не можете ідентифікувати замовлення вчасно, або відповідаєте нічим, спір вирішується без вашого боку, а на замовленні після 3 серпня ви сплачуєте $9.99 за вирахуванням комісії Google назад, плюс фіксовану банківську комісію за зворотний платіж, яка часто сягає близько $20. На малому продажу сама лише ця фіксована комісія може бути більшою за те, що ви заробили чистими.

• Втрачений виторг: ваша чиста частка з продажу, скасована.
• Комісія банку за зворотний платіж: фіксований кошт, який встановлює карткова мережа, нараховуваний зверху на замовленнях, розміщених після 3 серпня 2026 року, якого просте повернення коштів ніколи не несе.
• Змарнована витрата: обчислення, виклики сторонніх API і сховище, які обліковий запис уже використав, втрачені незалежно від того, чи змогли ви відповісти.
• Патерн, якого ви не можете побачити: без стабільного ідентифікатора облікового запису ви також не можете сказати, що той самий користувач оскаржує знову і знову, тож серійне зловживання читається як непов'язані одноразові втрати.

Як його встановити, щоб покупки не заблокували

Два правила покривають майже кожну помилку, яку команди роблять із цим полем. Хешуйте ідентифікатор і встановлюйте його всюди.

Хешуйте свій ідентифікатор користувача, ніколи не надсилайте PII

Не вставляйте у це поле електронну пошту, номер телефону чи будь-яку сиру персональну деталь. Google прямо каже, що зберігання PII, як-от адрес електронної пошти, у відкритому вигляді призводить до блокування покупок, і рекомендує односторонній хеш або шифрування для генерації значення. Чистий патерн це односторонній хеш вашого внутрішнього ідентифікатора користувача, обчислюваний щоразу однаково, щоб той самий користувач завжди давав той самий 64-символьний рядок. Не використовуйте також ідентифікатор облікового запису Google особи чи свій ідентифікатор розробника. Значення має щось означати лише для вашої системи.

Встановлюйте його на кожній покупці і зчитуйте назад на своєму сервері

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

Використовуйте setObfuscatedProfileId, коли один обліковий запис має багато профілів

Якщо ваш застосунок дозволяє одному обліковому запису тримати кілька профілів, стрімінгове домогосподарство чи гру з кількома персонажами, встановлюйте також setObfuscatedProfileId. Це той самий вид хешованого, 64-символьного рядка без PII, прив'язаного до профілю, який здійснив покупку. Google зауважує, що встановлення ідентифікатора профілю також вимагає передачі ідентифікатора облікового запису, тож надсилайте обидва. У результаті спір відображається не лише на обліковий запис, а й на саме той профіль, який витратив гроші.

Паралель iOS, в один рядок

App Store має ту саму ідею під іншою назвою. На iOS ви прикріплюєте до покупки appAccountToken, UUID, і він повертається у транзакції та у CONSUMPTION_REQUEST, яке Apple надсилає, коли клієнт просить повернення коштів. Форма проблеми ідентична в обох магазинах. Потік спору або повернення посилається на транзакцію, а ваш власний ідентифікатор це те, що прив'язує її назад до користувача, чиє споживання ви можете звітувати.

Ніщо з цього не важко побудувати. Це легко пропустити, бо день, коли ви пишете код каси, це не день, коли надходить зворотний платіж, а кошт пропуску невидимий до того дня. RefundHalt встановлює і відстежує ідентифікатор облікового запису в обох магазинах, тримає зв'язок покупки з користувачем, щоб спір завжди розв'язувався до справжнього клієнта, і відповідає на orders.reviewrefund Google Play та CONSUMPTION_REQUEST Apple у їхніх вікнах доказами споживання, записаними в момент продажу. Годинник на 24 години це не момент, щоб виявити, що ви не можете сказати, хто купив річ.