Apple może cofnąć zwrot, który już przyznał, a cofnięty zwrot, który Twój serwer ignoruje, blokuje dostęp klientowi, który zapłacił

Zwrot nie zawsze jest ostatnim słowem. App Store może cofnąć zwrot, który już przyznał, po tym jak klient go zakwestionuje, a gdy ten cofnięty zwrot trafia na Twój serwer, niesie jedną instrukcję: oddaj dostęp. Większość zespołów podłącza jedynie zwykłe powiadomienie REFUND, odcina klienta i na tym poprzestaje. Nigdy nie budują drugiej połowy. Więc gdy przychodzi cofnięcie, nic się nie uruchamia, a klient, który znów płaci, siedzi zablokowany bez dostępu do tego, co kupił. Oto jak działa pełen zestaw powiadomień o zwrotach w App Store i Google Play oraz ile kosztuje każde z nich, gdy je zignorujesz.

App Store wysyła trzy powiadomienia o zwrotach, nie jedno

Większość obsługi zwrotów jest zbudowana pod jedno zdarzenie: pieniądze wróciły, odetnij klienta. Strumień App Store Server Notifications V2 w rzeczywistości niesie trzy odrębne wyniki zwrotu i wymagają one trzech różnych rzeczy. Dwa z nich zmieniają to, do czego klient ma dostęp. Jedno z nich cofa pierwsze. Oto pełen zestaw, słowami samego Apple.

REFUND, to które obsługuje każdy zespół

Gdy App Store przetwarza zwrot, wysyła powiadomienie REFUND na skonfigurowany przez Ciebie URL, a definicja Apple jest jasna: 'wskazuje, że App Store pomyślnie zwrócił środki za transakcję dotyczącą konsumowalnego In-App Purchase, niekonsumowalnego In-App Purchase, subskrypcji z automatycznym odnawianiem lub subskrypcji nieodnawialnej.' Zapisujesz zwróconą transakcję, odbierasz to, co zostało za nią kupione, a Apple prosi, abyś poinformował klienta o zmianie za pomocą kontekstowego komunikatu w aplikacji. To powiadomienie, które wszyscy podłączają jako pierwsze, i często jedyne.

REFUND_DECLINED, to które niczego od Ciebie nie wymaga

REFUND_DECLINED oznacza dokładnie to, co mówi: 'App Store odrzucił wniosek o zwrot.' Klient poprosił, Apple odmówiło, a transakcja pozostaje w mocy. Nic w dostępie klienta się nie zmienia, więc Twoja logika uprawnień nic tu nie robi. Wartość tego powiadomienia to ewidencja. Zamyka pętlę wniosku o zwrot, na który mogłeś odpowiedzieć powiadomieniem CONSUMPTION_REQUEST, i potwierdza, że klient nadal ma to, za co zapłacił. Traktuj je jako zapis, nie jako działanie.

REFUND_REVERSED, to które zaskakuje zespoły

To powiadomienie, którego większość potoków zwrotów nigdy nie obsługuje. Definicja Apple jest jednoznaczna: REFUND_REVERSED 'wskazuje, że App Store cofnął wcześniej przyznany zwrot z powodu sporu zgłoszonego przez klienta. Jeśli Twoja aplikacja odebrała treści lub usługi w wyniku powiązanego zwrotu, musi je przywrócić.' Przeczytaj to dwa razy. Apple przyznało klientowi zwrot, Ty odebrałeś dostęp, potem Apple zdecydowało, że zwrot nie powinien obowiązywać, i go wycofało. Obciążenie znów jest aktywne. Klient zapłacił, a jeśli Twój serwer umie tylko odbierać, wciąż jest zablokowany. Cofnięty zwrot to jedyne zdarzenie zwrotu, które dodaje dostęp z powrotem, i jest to zdarzenie, pod które prawie nikt nie buduje.

Ile naprawdę kosztuje Cię cofnięty zwrot

Przeoczone cofnięcie to nie błąd zaokrąglenia. Prześledź pieniądze w obu kierunkach, bo pomyłka w którejkolwiek z połówek ma swoją cenę.

Przegap cofnięcie, a utrzymasz płacącego klienta w blokadzie. Apple przywróciło obciążenie, więc klient znów jest stratny, a Twoja aplikacja odmawia mu tego, co kupił. Bezpośrednim kosztem jest czas pomocy technicznej i zwrot z dobrej woli, który teraz możesz wystawić sam, tym razem bez prowizji sklepu wracającej, by go złagodzić. Wolniejszym kosztem jest recenzja i odejście klienta, a w Google Play ta sama frustracja z blokady to dokładnie to, co przeradza się w chargeback.

Przegap pierwotny zwrot, a nadal obsługujesz klienta, który nic nie zapłacił. Lustrzanym błędem jest w ogóle nieodbieranie dostępu. Klient po zwrocie, który wciąż generuje obrazy, wywołuje Twoje API i zapełnia Twoją pamięć, generuje realny koszt wobec sprzedaży, która została cofnięta. Obliczenia, wywołania zewnętrzne i pamięć to pieniądze, które już wydałeś, i żadne z nich nie wraca wraz ze zwrotem.

• Koszt wsparcia: człowiek odpowiadający na zgłoszenie o dostęp, który Twój własny kod usunął i nigdy nie przywrócił.
• Zwroty z dobrej woli: ponowne wystawienie pieniędzy klientowi, którego błędnie zablokowałeś, bez prowizji sklepu zwracanej przy ręcznym geście.
• Zmarnowane wydatki: obliczenia, wywołania API i pamięć zużyte przez konto po zwrocie, którego nigdy nie odciąłeś.
• Ryzyko chargebacku: w Google Play klient, który czuje się obciążony podwójnie, może zakwestionować obciążenie, a przegrany spór teraz spada na Ciebie.

Cofnięty zwrot i zwykły zwrot to ten sam strumień webhook wskazujący w przeciwnych kierunkach. Obsłuż jeden, a pomiń drugi, a zapłacisz na obu końcach.

Dlaczego Apple cofa zwrot i jak czytać revocationReason

Cofnięcie nie jest przypadkowe. Apple wiąże je z 'sporem zgłoszonym przez klienta', czyli klientem kwestionującym decyzję o zwrocie po fakcie. Gdy zwrot został pierwotnie przyznany, transakcja niosła revocationDate i revocationReason, i warto przeczytać ten powód, zanim cokolwiek dalej w potoku na nim zadziała.

• revocationReason 1: App Store zwrócił środki 'z powodu rzeczywistego lub domniemanego problemu w Twojej aplikacji.' To sygnał o Twoim produkcie, nie tylko o tym kliencie.
• revocationReason 0: App Store zwrócił środki 'z innych powodów, na przykład przypadkowego zakupu.' Brak dołączonego sygnału o jakości aplikacji.

Gdy REFUND_REVERSED przychodzi dla tej transakcji, odebranie jest cofane. Twoja logika przywracania powinna odszukać oryginalny id transakcji, potwierdzić, że go odebrałeś, i przywrócić uprawnienie dokładnie takie, jakie było.

Google Play nie wysyła cofnięcia, więc zamiast tego uzgadniasz

Model Google Play jest inny, a różnica ma znaczenie, jeśli obsługujesz oba sklepy przez jeden handler webhook. Nie ma odpowiednika REFUND_REVERSED w Google. Powiadomienia dla deweloperów w czasie rzeczywistym Google dzielą zdarzenia zwrotów na dwie wiadomości, a cofnięcia są obsługiwane przez uzgadnianie, a nie przez push.

Powiadomienie o unieważnionym zakupie

Gdy zakup w Google Play zostaje unieważniony, Twój serwer otrzymuje VoidedPurchaseNotification. Podaje ono purchaseToken i orderId, productType typu subscription lub one-time oraz refundType, który jest albo pełnym unieważnieniem, albo częściowym zwrotem opartym na ilości przy zakupach wieloilościowych. Google mówi, że te dane wystarczą, aby znaleźć właściwy zakup i skorygować uprawnienie. Po więcej kieruje Cię do Voided Purchases API, modelu pull, który wymienia unieważnione zamówienia w zakresie znaczników czasu, o który pytasz.

Przegląd chargebacku i jego 24-godzinny zegar

Chargebacki przychodzą inną wiadomością, PendingRefundReviewNotification. Gdy klient kwestionuje obciążenie w swoim banku, Google Play wysyła to powiadomienie i uruchamia zegar. Masz 24 hours na wywołanie orders.reviewrefund z preferencją zwrotu i wszelkimi dowodami użytkowania, aby Google mogło zakwestionować w Twoim imieniu nieuprawniony chargeback. Google rejestruje Twoje pierwsze wywołanie i ignoruje resztę. To odpowiednik Google dla CONSUMPTION_REQUEST firmy Apple, jedyne okno, w którym liczy się Twoja strona sporu.

Ponieważ nie ma pusha o cofnięciu, chargeback, który Google zakwestionuje i wygra, nie przychodzi jako schludne zdarzenie przywrócenia. Uzgadniasz go z Voided Purchases API i własnymi zapisami. Wniosek jest taki sam jak w App Store: unieważnione zamówienie nie zawsze jest trwałe, a stan Twoich uprawnień musi umieć poruszać się wstecz, nie tylko naprzód.

Jak obsłużyć każde powiadomienie o zwrocie, nie blokując nikomu dostępu

Nie potrzebujesz osobnych potoków na każdy sklep. Potrzebujesz handlera, który potrafi przesuwać uprawnienie w obu kierunkach i traktuje każdą wiadomość jako możliwie zduplikowaną.

• Zbuduj przywracanie, nie tylko odbieranie. Dla każdej ścieżki, która usuwa dostęp przy REFUND, napisz odwrotność, która go przywraca przy REFUND_REVERSED, powiązaną z tym samym id transakcji.
• Uczyń to idempotentnym. Oba sklepy mogą dostarczyć to samo powiadomienie więcej niż raz, więc powiąż każde odebranie i przywrócenie z id transakcji lub zamówienia i spraw, aby powtórzenie nie miało żadnego efektu.
• Przeczytaj powód, zanim zadziałasz. Użyj revocationReason, aby odróżnić zwrot z powodu jakości aplikacji od przypadkowego, i kieruj te dotyczące jakości aplikacji do osoby odpowiedzialnej za jakość produktu.
• Odpowiadaj na okna dowodowe na czas. Wyślij dane o zużyciu Apple w ciągu 12 hours od CONSUMPTION_REQUEST i wywołaj orders.reviewrefund w ciągu 24 hours od PendingRefundReviewNotification.
• Zapisuj każde zdarzenie. Przechowuj REFUND_DECLINED i surowe powiadomienia, aby cofnięcie, które przyjdzie później, można było dopasować do zwrotu, który odwraca.

Nic z tego nie zmienia tego, czy zwrot się wydarzy. Zmienia to, czy klient po drugiej stronie cofniętego zwrotu w ogóle zauważy, że Twój serwer się pomylił.