Przenosisz aplikację na inne konto dewelopera, a zamówienia sprzed sprzedaży zostają u sprzedającego, oto co to oznacza dla zwrotów

Strona pomocy Google ujmuje to w jednym zdaniu: zamówienia utworzone przed transferem aplikacji zostają na koncie pierwotnym. Gdy więc przenosisz aplikację na inne konto dewelopera, subskrybenci przechodzą do kupującego, ale historia zakupów już nie. Zwroty, spory i zgłoszenia do supportu związane z tą historią same się nie rozwiążą. Trafiają do tego, na kogo wskazują zasady sklepu, a to nie zawsze strona, która dostała pieniądze. Apple i Google podchodzą do tego inaczej, a Apple mówi mniej niż Google. Poniżej opisujemy, co dokumentuje każdy sklep, które elementy Twojej konfiguracji zwrotów po cichu przestają działać po transferze i co spisać, zanim którakolwiek strona podpisze umowę.

Co przechodzi, a co zostaje, gdy przenosisz aplikację

Oba sklepy traktują transfer jako zmianę właściciela na przyszłość. Aplikacja, jej użytkownicy i oceny przechodzą dalej. Finansowa historia przeszłości w większości zostaje.

W App Store

Zasada Apple dotyczy danych. Przekazujący deweloper zachowuje dostęp do danych o płatnościach i sprzedaży sprzed transferu i traci dostęp do wszystkiego, co było potem. Odbiorca dostaje dane o płatnościach i sprzedaży tylko dla transakcji, które nastąpiły po transferze. Przewodnik Apple o transferze nie porusza tematu zwrotów za zakupy sprzed transferu. Nie mówi nic o tym, z czyich wpływów pokrywany jest późny zwrot.

W Google Play

Google mówi to wprost. Użytkownicy, statystyki, dane, komentarze, oceny i subskrypcje przechodzą. Zamówienia utworzone przed transferem zostają na koncie pierwotnym, a jeśli któreś z nich wymaga zwrotu, Google każe wrócić do konta pierwotnego albo użyć Google Play Developer API. Konto sprzedającego nie przestaje więc mieć znaczenia w dniu sprzedaży. Pozostaje jedynym miejscem, z którego można wykonać niektóre zwroty.

Kto wykonuje zwrot po transferze aplikacji

Większość zwrotów w obu sklepach zapada bez udziału dewelopera. Apple sam obsługuje wnioski o zwrot. W Google Play kupujący mogą sami zwrócić wiele zakupów w ciągu 48 godzin, a inne przyznaje support Google. Transfer niczego tu nie zmienia. Zmienia to, kto widzi zwrot i kto może działać w rzadkich procesach, które wymagają dewelopera.

Zwrot, który chcesz przyznać w Google Play

Załóżmy, że wieloletni subskrybent pisze do nowego właściciela i prosi o zwrot pieniędzy za płatność pobraną dwa miesiące przed sprzedażą. Nowy właściciel nie może zwrócić jej ze swojej Play Console, bo tego zamówienia tam nie ma. Sprzedający musi się zalogować i to zrobić, albo ktoś z dostępem API do konta sprzedającego musi wywołać Google Play Developer API. Jeśli sprzedający zamknął konto albo przestał odpowiadać, zwrot utknie. Google proponuje nawet zwrot opłaty rejestracyjnej 25 $ sprzedającemu, jeśli po transferze zamknie konto pierwotne, i właśnie dlatego kupujący powinien zadbać o rozliczenie zwrotów sprzed transferu, zanim do tego dojdzie.

Zwrot, który Apple przyznaje samodzielnie

W App Store to nie Ty wykonujesz zwroty, tylko Apple. Gdy Apple zwraca zakup sprzed transferu, zapis o płatności i sprzedaży znajduje się u pierwotnego dewelopera. Dokumentacja Apple o transferze nie mówi, z czyich wpływów pokrywany jest ten zwrot, więc żadna ze stron nie powinna niczego zakładać. Wpiszcie to do umowy.

Dwa procesy zwrotów, które wymagają dowodów

Tylko dwa procesy zwrotów w ogóle czegoś wymagają od dewelopera. Apple wysyła CONSUMPTION_REQUEST i daje Ci 12 godzin na odpowiedź z danymi o wykorzystaniu przez Send Consumption Information. Google Play wysyła przegląd chargebacku, a Ty masz 24 godziny na odpowiedź przez orders.reviewrefund. Obie odpowiedzi są podpisywane danymi uwierzytelniającymi należącymi do konta, a nie do aplikacji. Właśnie tu transfery się psują.

Infrastruktura zwrotów, która psuje się podczas transferu

Przeniesiona aplikacja może sprzedawać przez tygodnie, a nikt nie zauważy, że strona zwrotów zamilkła.

Adres URL powiadomień i klucz In-App Purchase w Apple

Adres URL App Store Server Notifications ustawia się dla każdej aplikacji osobno, w sekcji App information w App Store Connect. Przewodnik Apple o transferze o nim nie wspomina, więc nowy właściciel powinien otworzyć ten ekran pierwszego dnia i skierować środowisko produkcyjne i sandbox na własny serwer. Jeśli nadal widnieje tam endpoint sprzedającego, każdy CONSUMPTION_REQUEST dla aplikacji trafia na serwer, którego kupujący nie prowadzi, a 12 godzin mija bez odpowiedzi.

Odpowiedzi idą przez App Store Server API, które wymaga klucza In-App Purchase. Takie klucze generuje Account Holder lub Admin w sekcji Users and Access, a Apple pozwala pobrać każdy z nich tylko raz. Klucz sprzedającego jest na koncie sprzedającego. Kupujący powinien wygenerować własny, a sprzedający powinien unieważnić swój po zakończeniu przekazania.

Współdzielony sekret i webhooki w Apple

Dla aplikacji z automatycznie odnawianymi subskrypcjami Apple każe sprzedającemu wygenerować przed transferem współdzielony sekret aplikacji i przekazać go odbiorcy, który używa go do weryfikacji subskrypcji. Po zakończeniu transferu odbiorca powinien wygenerować nowy, żeby osoby spoza jego organizacji już go nie miały. Webhooki App Store Connect także przechodzą do odbiorcy, a Apple sugeruje, by sprzedający wcześniej je usunął, jeśli nie chce, żeby zdarzenia trafiały potem na jego serwer.

Uprawnienia i projekt Cloud w Google

Google podaje, że uprawnienia i ustawienia powiązań usług zintegrowanych nie przechodzą. Każe sprzedającemu dodać konto docelowe jako Owner do wszystkich projektów w Google Developers Console, z których korzysta aplikacja. W Play to zwykle tam są temat powiadomień dla deweloperów w czasie rzeczywistym i konto usługi stojące za wywołaniami Developer API. Jeśli konto usługi nie dostanie dostępu w Play Console kupującego, sprawdzanie anulowanych zakupów przestaje działać, a odpowiedzi przez orders.reviewrefund nie da się wysłać w ciągu 24 godzin.

Ile transfer kosztuje w zwrotach i chargebackach

Opisane wyżej mechanizmy zamieniają się w pieniądze w trzech miejscach.

Obsługujesz użytkowników, którzy zapłacili sprzedającemu

Weźmy subskrybenta, który miesiąc przed sprzedażą kupił plan roczny za 59,99 $. W Google Play to zamówienie jest na koncie sprzedającego. W App Store zapis płatności zostaje u sprzedającego. Kupujący nie dostaje za nie żadnych pieniędzy, a mimo to przez resztę roku płaci za moc obliczeniową, wywołania zewnętrznych API i przestrzeń dyskową, z których korzysta ten subskrybent. Jeśli subskrybent poprosi później kupującego o zwrot, kupujący nie wykona go w Google Play bez sprzedającego. Policz te przedpłacone subskrypcje przy podpisaniu umowy, bo to koszt, który kupujący przejmuje bez żadnego przychodu.

Chargebacki na zamówieniach, których kupujący nigdy nie sprzedał

W przypadku zamówień w Google Play złożonych po 3 sierpnia 2026 deweloper odpowiada za cenę zakupu objętą chargebackiem, pomniejszoną o opłatę serwisową Play, plus opłatę banku za chargeback. Rozstrzygnięty chargeback jest w banku ostateczny. Strona Google o transferze nie mówi, jak ten koszt jest rozliczany w przypadku zamówienia, które zostało na koncie sprzedającego. Dopóki Google tego nie określi, umowa sprzedaży powinna wskazywać, kto płaci za chargeback na zamówieniu sprzed transferu i kto odpowiada na jego przegląd.

Próg 15% liczy te same zarobki dwa razy

Opłata serwisowa 15% w Google Play dotyczy pierwszego 1 mln $ zarobków dewelopera w każdym roku. Gdy aplikacja przechodzi między kontami deweloperów w osobnych Account Groups, wszystkie jej zarobki z danego roku kalendarzowego wliczają się do sum obu grup. Przykład samego Google to aplikacja, która zarobiła 100 000 $ w Account Group A i przechodzi do Account Group B. Te 100 000 $ liczą się w obu grupach do pierwszego 1 mln $. Kupujący blisko progu może wejść w stawkę standardową wcześniej, niż wynikałoby z jego własnej sprzedaży.

Co ustalić, zanim przeniesiesz aplikację

Dla sprzedającego

• Pobierz raporty, których będziesz potrzebować. Eksport zbiorczy, szacunkowa sprzedaż i raporty zarobków w Google nie przechodzą, a odbiorca w Apple nie zobaczy Twojej historii.
• Utrzymaj konto pierwotne otwarte i dostępne, dopóki zwroty i spory sprzed transferu się nie zakończą.
• Przed transferem w App Store wygeneruj i przekaż współdzielony sekret aplikacji, a potem unieważnij swój klucz In-App Purchase i usuń webhooki, które nie powinny się już uruchamiać.

Dla kupującego

• Pierwszego dnia ustaw własny adres URL App Store Server Notifications i wygeneruj własny klucz In-App Purchase.
• Nadaj swojemu kontu usługi dostęp w swojej Play Console i sprawdź, czy powiadomienia dla deweloperów w czasie rzeczywistym docierają do Twojego endpointu.
• Zdobądź listę przedpłaconych subskrypcji i ostatnich dużych zakupów, żeby wiedzieć, kogo będziesz obsługiwać bez przychodu.
• Wpisz do umowy sprzedaży zwroty, chargebacki i przeglądy chargebacków sprzed transferu, razem ze wskazaną z imienia i nazwiska osobą kontaktową po stronie sprzedającego.

RefundHalt łączy się z każdą aplikacją za pomocą danych uwierzytelniających konta, do którego ona należy. Po transferze połącz aplikację z konta nowego właściciela, a od tego momentu prośby o dane o wykorzystaniu i przeglądy chargebacków będą trafiać do nowego właściciela.