Każde żądanie zwrotu od Apple ma teraz powód, a consumptionRequestReason to sposób, by go odczytać

Apple zmieniło sposób, w jaki żądania zwrotu trafiają na twój serwer, a wielu deweloperów tego nie zauważyło. Od aktualizacji App Store Server Notifications 2.11, ogłoszonej na WWDC24, każde powiadomienie CONSUMPTION_REQUEST niesie pole o nazwie consumptionRequestReason. To podany przez samego klienta powód, dla którego chce odzyskać pieniądze. Jeden prosty ciąg znaków, pięć możliwych wartości, dostarczony w tym samym ładunku, na który i tak masz dwanaście godzin, by odpowiedzieć.

Powód żądania zwrotu od Apple sam w sobie o niczym nie decyduje. To, co robi, to mówi ci, w której z pięciu bardzo różnych sytuacji się znajdujesz, abyś przestał wysyłać te same ogólne dane o zużyciu do zwrotu, który powinieneś przyznać, i do zwrotu, który powinieneś zakwestionować. Oto czym jest to pole, jakie dokładnie wartości może wysłać Apple, co każda z nich sygnalizuje i jak powinna zmienić preferencję oraz dowody, które odsyłasz.

Czym właściwie jest consumptionRequestReason

consumptionRequestReason to pole typu ciąg znaków w obiekcie data powiadomienia CONSUMPTION_REQUEST. Apple dodało je w App Store Server Notifications w wersji 2.11, wraz ze zmianami z WWDC24 w procesie zwrotów. Wcześniej żądanie przychodziło z podpisaną transakcją i niczym więcej na temat motywu. Odpowiadałeś na ślepo. Teraz podany przez klienta powód podróżuje razem z żądaniem.

Przeczytaj uważnie słowo podany. To powód, który klient wybrał, składając wniosek u Apple, a nie fakt zweryfikowany przez Apple. UNINTENDED_PURCHASE nie dowodzi, że zakup pozostał nieużyty, a UNSATISFIED_WITH_PURCHASE nie dowodzi, że produkt był wadliwy. Wartość to soczewka, nie wyrok. Nadal łączysz ją z własnymi zapisami dostawy i użycia.

Podróżuje w powiadomieniu, które już obsługujesz

CONSUMPTION_REQUEST to jedyny proces Apple, który w ogóle prosi dewelopera o dowody. Jego odpowiednikiem w Google Play jest przegląd obciążenia zwrotnego przez orders.reviewrefund. Gdy takie żądanie przychodzi, masz 12 godzin, by odpowiedzieć, wywołując Send Consumption Information, czyli PUT do punktu końcowego zużycia transakcji. consumptionRequestReason jest teraz częścią tego samego powiadomienia, więc nie ma nic nowego do subskrybowania. Jeśli już parsujesz CONSUMPTION_REQUEST, powód to jedno pole, które prawdopodobnie ignorowałeś.

Pięć powodów i co każdy z nich ci mówi

Apple dokumentuje dokładnie pięć wartości. Jedna przychodzi na żądanie. Oto pełny zestaw i jak odczytać każdą w praktyce.

UNINTENDED_PURCHASE to koszyk na przypadkowe dotknięcia

To powód, który wybiera rodzic po tym, jak dziecko kupiło 10,000 monet, albo dorosły, który przypadkiem dotknął potwierdzenia. Koreluje z zakupami, które nigdy nie zostały otwarte ani użyte. Właśnie dlatego twoje własne dane mają znaczenie. Jeśli twoje zapisy pokazują, że dobro konsumpcyjne zostało w pełni dostarczone i intensywnie zużyte, roszczenie o niezamierzonym zakupie i całkowicie wydane saldo nie zgadzają się ze sobą, a ta rozbieżność jest warta zgłoszenia poprzez consumptionPercentage.

FULFILLMENT_ISSUE wskazuje z powrotem na ciebie

FULFILLMENT_ISSUE to jedyny powód, który częściowo dotyczy twojej aplikacji, a nie klienta. Oznacza, że klient mówi, iż nie mógł otrzymać ani użyć tego, za co zapłacił. Zanim odruchowo zakwestionujesz, wyciągnij swoje logi dostawy. Jeśli twój własny serwer pokazuje, że uprawnienie nigdy się nie aktywowało albo środki nigdy nie zostały zaksięgowane, klient ma rację, a DECLINE to zła preferencja. Walka z prawdziwą awarią dostawy marnuje okno i może popchnąć klienta do jego banku, gdzie obciążenie zwrotne kosztuje więcej, niż kosztowałby zwrot.

UNSATISFIED_WITH_PURCHASE to miejsce, gdzie decydują dowody

To zwykły żal kupującego i powód, przy którym twoje dane o zużyciu wykonują najwięcej pracy. Produkt działał. Klient użył części lub całości i teraz chce zwrotu pieniędzy. Wysoka consumptionPercentage, uczciwy deliveryStatus o wartości DELIVERED oraz refundPreference równe DECLINE lub GRANT_PRORATED to sprawa, o której zbudowanie prosi cię Apple. Wyślij liczby, nie argument.

LEGAL i OTHER

LEGAL oznacza, że klient powołał się na prawo lub uprawnienie regulacyjne. Rozsądni ludzie się różnią, ale z zasady to nie jest okno na spory. Przyznaj i idź dalej. OTHER to kategoria zbiorcza, której Apple używa, gdy podany powód nie pasuje do żadnego z czterech powyższych. Sam w sobie nie niesie sygnału, więc potraktuj OTHER dokładnie tak, jak potraktowałbyś żądanie bez żadnego powodu: zacznij od statusu dostawy i dowodów użycia.

Jak powód zmienia twoją odpowiedź, pole po polu

Odpowiadasz na CONSUMPTION_REQUEST, wywołując Send Consumption Information z treścią ConsumptionRequest. Powód powinien ukształtować trzy pola w tej treści.

customerConsented musi być true

Apple przyjmuje zgłoszenie tylko wtedy, gdy customerConsented jest true, co oznacza, że klient zgodził się udostępnić dane o zużyciu. Jeśli nie masz tej zgody, w ogóle nie możesz wysłać danych, niezależnie od powodu. Brak zgody, brak dowodów, a żądanie jest rozstrzygane bez twoich liczb.

deliveryStatus i consumptionPercentage niosą fakty

deliveryStatus mówi, czy dostarczyłeś działający zakup. Jeśli jest cokolwiek innego niż DELIVERED, Apple wymaga, by consumptionPercentage wynosiło 0. Gdy dostarczyłeś, consumptionPercentage to liczba całkowita w milliunits od 0 do 100,000, gdzie 100,000 oznacza, że klient użył całego zakupu. Ta para to twój rdzeń faktyczny i to ona powinna nieść sprawę FULFILLMENT_ISSUE lub UNSATISFIED_WITH_PURCHASE, a nie sam powód.

refundPreference to twoja jedyna dźwignia

refundPreference to miejsce, w którym określasz, czego chcesz. Apple dokumentuje trzy wartości: GRANT_FULL, GRANT_PRORATED i DECLINE. Przeczytaj powód, zważ go wobec swoich danych, a potem wybierz. FULFILLMENT_ISSUE z nieudaną dostawą w twoich logach skłania się ku GRANT_FULL. UNSATISFIED_WITH_PURCHASE przy w pełni zużytym produkcie skłania się ku DECLINE lub GRANT_PRORATED. LEGAL skłania się ku GRANT_FULL.

Ile naprawdę kosztuje cię zwrot

Pole powodu ma znaczenie, ponieważ zwrot rzadko jest tylko sprzedażą znikającą z twojej księgi. Za dobro konsumpcyjne, które już się wyczerpało, zapłaciłeś, by je zrealizować. Pakiet środków, który wywołał płatne API inferencji, partia wygenerowanych obrazów, która spaliła czas GPU, zapisany eksport, który zalega na twoim rachunku za pamięć, wypłata dla twórcy, którą już wysłałeś: te koszty pozostają wydane, gdy zakup zostaje cofnięty. Sklep zwraca klientowi pieniądze. Nie zwraca ci mocy obliczeniowej.

Dlatego warto odczytać powód. Powiedzmy, że klient kupił 5,000 środków, z których każdy uruchamia płatne wywołanie API, wydał 4,000 z nich, a potem złożył wniosek pod UNSATISFIED_WITH_PURCHASE. Twój deliveryStatus to DELIVERED, twoja consumptionPercentage to 80,000 milliunits, a preferencja DECLINE lub GRANT_PRORATED to różnica między połknięciem rachunku za API a odzyskaniem jego większości. Teraz odwróć powód na FULFILLMENT_ISSUE z logami pokazującymi, że środki nigdy nie zostały zaksięgowane, a uczciwym, tańszym ruchem jest GRANT_FULL, zanim klient eskaluje do swojego banku.

Odczytywanie powodu bez przesadnej reakcji

Pułapką jest traktowanie powodu jako dowodu. UNINTENDED_PURCHASE to nie wyznanie, że produkt pozostał nieużyty, a LEGAL nie zawsze jest prawdziwym roszczeniem prawnym. Powód zawęża sytuację. Twoje logi dostawy i zapisy zużycia ją rozstrzygają. Gdy zgadzają się z klientem, przyznaj wcześnie i tanio. Gdy zaprzeczają klientowi, ta sprzeczność, wyrażona jako deliveryStatus i consumptionPercentage, to najsilniejsza rzecz, jaką możesz wysłać. RefundHalt odczytuje consumptionRequestReason przy każdym CONSUMPTION_REQUEST i automatycznie łączy go z twoimi rzeczywistymi danymi o użyciu, więc każdy powód otrzymuje odpowiedź, na jaką zasługuje, w oknie 12 godzin.

Zmiana jest niewielka i łatwa do przeoczenia, ale przesunęła rozmowę o zwrotach na twoją korzyść. Apple mówi ci teraz dlaczego, zanim odpowiesz. Wykorzystaj to.