Oznacz każdy zakup w Google Play zaciemnionym identyfikatorem konta, albo obciążenie zwrotne przyjdzie bez możliwości powiązania go z nikim

Przegląd obciążenia zwrotnego w Google Play pojawia się, nazywając zamówienie i token zakupu. Nie mówi ci, kim jest klient. Jeśli nigdy nie odcisnąłeś na tym zakupie własnego identyfikatora, dopasowujesz teraz goły numer zamówienia do swojej tabeli użytkowników pod zegarem 24 godzin i musisz odpowiedzieć dowodami zużycia, których być może nie zdołasz znaleźć. Zaciemniony identyfikator konta jest rozwiązaniem. To krótki ciąg znaków, który dołączasz przy kasie, a Google Play przechowuje go razem z zakupem i zwraca ci później, dzięki czemu każde zamówienie można prześledzić do dokładnie tego użytkownika, który je złożył. Oto czym jest to pole, dlaczego decyduje w ogóle o tym, czy zdołasz odpowiedzieć na spór, i ile kosztuje jego pominięcie teraz, gdy przegrane obciążenie zwrotne to rachunek.

Czym właściwie jest zaciemniony identyfikator konta

Zaciemniony identyfikator konta to jeden opcjonalny ciąg znaków, który przekazujesz do przepływu rozliczeniowego Google Play, gdy klient coś kupuje. Ustawiasz go za pomocą setObfuscatedAccountId na budowniczym BillingFlowParams, a Google przechowuje go obok zakupu. To nie jest imię klienta, nie jego e-mail i nie jego konto Google. To twój własny identyfikator twojego własnego użytkownika, zapisany w formie, którą Google może przechować, nie dowiadując się, kim jest ta osoba.

To ciąg znaków, który ustawiasz przy kasie, a nie imię

Słowami Google, setObfuscatedAccountId określa opcjonalny zaciemniony ciąg znaków, który jest jednoznacznie powiązany z kontem użytkownika kupującego w twojej aplikacji. Słowo zaciemniony wykonuje realną pracę. Google nie chce twojego surowego identyfikatora użytkownika ani niczego, co identyfikuje osobę. Chce stabilnego tokena, który odwzorowuje jeden do jednego na użytkownika po twojej stronie, i nic więcej. Pole jest ograniczone do 64 znaków, co wygodnie mieści hash i niewiele więcej.

Google odczytuje je najpierw do własnego wykrywania oszustw

Zanim w ogóle przyda się tobie, pole wykonuje zadanie dla Google. Dokumentacja rozliczeń mówi, że Google Play może użyć tej wartości, aby wykryć nietypową aktywność, na przykład wiele urządzeń dokonujących zakupów na tym samym koncie w krótkim odstępie czasu, i że Google używa tych danych, aby wykryć podejrzane zachowanie i zablokować niektóre rodzaje oszukańczych transakcji, zanim zostaną sfinalizowane. Pierwszy zysk z ustawienia leży więc w górze strumienia, w czystszych zakupach i mniejszej liczbie tych oszukańczych, które później zmieniają się w anulowania i spory. Google wymienia zaciemniony identyfikator konta i Voided Purchases API razem jako dwa swoje podstawowe narzędzia przeciw nadużyciom nie bez powodu.

Dlaczego to się liczy, gdy przychodzi przegląd obciążenia zwrotnego

Zwrot, który widzisz nadchodzący, jest łatwy. Trudnym przypadkiem jest obciążenie zwrotne banku, ponieważ nie zaczyna się od rozmowy twojego klienta z tobą. Zaczyna się w banku, a Google Play przekazuje ci je jako przegląd z dołączonym zegarem.

Spór nazywa zamówienie, a nie osobę

Gdy klient kwestionuje obciążenie w swoim banku, a Google potrzebuje twojego wkładu, Google Play wysyła PendingRefundReviewNotification. Ta wiadomość identyfikuje zamówienie. Nie niesie twojego identyfikatora użytkownika, ponieważ Google nigdy nie miało twojego identyfikatora użytkownika. Miało tylko to, co odcisnąłeś na zakupie. Jeśli to było nic, przeszukujesz teraz wstecz goły numer zamówienia i token zakupu w swoich rekordach, mając nadzieję, że zalogowałeś token w chwili zakupu, i mając nadzieję, że dopasowanie jest jednoznaczne. Jeśli ustawiłeś zaciemniony identyfikator konta, zakup niesie twój własny hash, wyszukujesz użytkownika jednym zapytaniem i przechodzisz do budowania dowodów, zamiast polować na tożsamość.

O co właściwie prosi cię orders.reviewrefund

Odpowiedź na spór oznacza wywołanie metody orders.reviewrefund w ciągu 24 godzin. Google rejestruje twoje pierwsze wywołanie i ignoruje resztę, więc pierwsza odpowiedź jest jedyną odpowiedzią. Oto pola, których żąda, i każde z pól dowodowych zakłada, że już wiesz, do którego użytkownika należy zamówienie.

Ile właściwie kosztuje jego pominięcie

Przez większość historii Google Play obciążenie zwrotne, którego nie mogłeś obronić, było utraconą sprzedażą i wzruszeniem ramion. To się zmieniło. W przypadku zamówień złożonych 3 sierpnia 2026 lub później przegrane obciążenie zwrotne obciąża dewelopera ceną zakupu pomniejszoną o opłatę serwisową Google, plus opłatą banku za obciążenie zwrotne. Spór, na który nie możesz odpowiedzieć, jest teraz pozycją na rachunku.

Przejdźmy przez jedno zamówienie. Klient kwestionuje zakup za $9.99 w swoim banku. Google Play wysyła przegląd, a ty masz 24 godziny. Jeśli oznaczyłeś zakup, znajdujesz użytkownika, widzisz, że zużył większość tego, co kupił, i odpowiadasz na reviewrefund z preferencją DECLINE oraz dowodami zużycia, dając Google prawdziwą sprawę, by zakwestionować nielegalny spór. Jeśli go nie oznaczyłeś, albo nie potrafisz zidentyfikować zamówienia na czas, albo odpowiadasz niczym, spór rozstrzyga się bez twojej strony, a przy zamówieniu po 3 sierpnia płacisz $9.99 pomniejszone o opłatę Google z powrotem, plus stałą opłatę banku za obciążenie zwrotne, która często ląduje w okolicach $20. Przy małej sprzedaży sama ta stała opłata może być większa niż to, co zarobiłeś netto.

• Utracony przychód: twój udział netto ze sprzedaży, cofnięty.
• Opłata banku za obciążenie zwrotne: stały koszt ustalany przez sieć kartową, doliczany na wierzch przy zamówieniach złożonych po 3 sierpnia 2026, którego zwykły zwrot nigdy nie niesie.
• Zmarnowany wydatek: moc obliczeniowa, wywołania zewnętrznych API i pamięć, których konto już użyło, przepadłe niezależnie od tego, czy zdołałeś odpowiedzieć.
• Wzorzec, którego nie widzisz: bez stabilnego identyfikatora konta nie potrafisz też stwierdzić, że ten sam użytkownik kwestionuje raz za razem, więc seryjne nadużycie odczytuje się jako niepowiązane jednorazowe straty.

Jak go ustawić, żeby zakupy nie zostały zablokowane

Dwie zasady pokrywają niemal każdy błąd, jaki zespoły popełniają z tym polem. Zahaszuj identyfikator i ustaw go wszędzie.

Zahaszuj swój identyfikator użytkownika, nigdy nie wysyłaj PII

Nie umieszczaj w tym polu adresu e-mail, numeru telefonu ani żadnego surowego szczegółu osobowego. Google jasno mówi, że przechowywanie PII takich jak adresy e-mail w postaci jawnej skutkuje blokowaniem zakupów, i zaleca jednokierunkowy hash lub szyfrowanie do wygenerowania wartości. Czystym wzorcem jest jednokierunkowy hash twojego wewnętrznego identyfikatora użytkownika, obliczany za każdym razem tak samo, aby ten sam użytkownik zawsze dawał ten sam 64-znakowy ciąg. Nie używaj też identyfikatora konta Google osoby ani swojego identyfikatora dewelopera. Wartość powinna coś znaczyć tylko dla twojego systemu.

Ustawiaj go na każdym zakupie i odczytuj z powrotem na swoim serwerze

Dołączaj identyfikator do każdego przepływu rozliczeniowego, jednorazowych produktów i subskrypcji na równi, aby żaden zakup nigdy nie był nieoznaczony. Po zakupie odczytuj go z powrotem w dwóch miejscach. Na kliencie Purchase.getAccountIdentifiers zwraca obiekt, którego getObfuscatedAccountId daje ci ustawiony ciąg. W twoim backendzie rekord zakupu po stronie serwera niesie go jako pole obfuscatedExternalAccountId, i to kopii serwerowej należy ufać, ponieważ spór przychodzi na twój serwer, a nie na urządzenie.

Użyj setObfuscatedProfileId, gdy jedno konto ma wiele profili

Jeśli twoja aplikacja pozwala, by jedno konto miało kilka profili, gospodarstwo streamingowe lub gra z wieloma postaciami, ustaw także setObfuscatedProfileId. To ten sam rodzaj zahaszowanego, 64-znakowego ciągu bez PII, przypisanego do profilu, który dokonał zakupu. Google zauważa, że ustawienie identyfikatora profilu wymaga także przekazania identyfikatora konta, więc wysyłaj oba. W efekcie spór odwzorowuje się nie tylko na konto, ale na dokładnie ten profil, który wydał pieniądze.

Odpowiednik iOS, w jednej linii

App Store ma ten sam pomysł pod inną nazwą. Na iOS dołączasz do zakupu appAccountToken, UUID, i wraca ono w transakcji oraz w CONSUMPTION_REQUEST, które Apple wysyła, gdy klient prosi o zwrot. Kształt problemu jest identyczny w obu sklepach. Przepływ sporu lub zwrotu odwołuje się do transakcji, a twój własny identyfikator jest tym, co wiąże ją z powrotem z użytkownikiem, którego zużycie możesz zgłosić.

Nic z tego nie jest trudne do zbudowania. Łatwo to pominąć, ponieważ dzień, w którym piszesz kod kasy, nie jest dniem, w którym przychodzi obciążenie zwrotne, a koszt pominięcia jest niewidoczny aż do tego dnia. RefundHalt ustawia i śledzi identyfikator konta w obu sklepach, utrzymuje powiązanie zakupu z użytkownikiem, aby spór zawsze rozwiązywał się do prawdziwego klienta, i odpowiada na orders.reviewrefund Google Play oraz CONSUMPTION_REQUEST Apple w ich oknach z dowodami zużycia zarejestrowanymi w chwili sprzedaży. Zegar 24 godzin nie jest chwilą, by odkryć, że nie potrafisz powiedzieć, kto kupił daną rzecz.