Twoja aplikacja może pokazać arkusz wniosku o zwrot środków wewnątrz aplikacji, a oto co robi Apple, gdy klient dotknie przycisku wyślij

Apple pozwala klientowi poprosić o zwrot, nigdy nie opuszczając Twojej aplikacji. Jedno wywołanie StoreKit, beginRefundRequest, wyświetla własny arkusz zwrotu Apple bezpośrednio w Twoim interfejsie, klient wybiera powód, a wniosek trafia do Apple do sprawdzenia. Nie budujesz formularza, nie dotykasz pieniędzy i nie decydujesz o wyniku. To, co dostajesz, to sposób na umieszczenie ścieżki zwrotu tam, gdzie sfrustrowany klient już jest, zamiast tracić go na rzecz jego banku. To jest wewnątrzaplikacyjny wniosek o zwrot i warto go zrozumieć, zanim zdecydujesz, czy wdrożyć ten przycisk.

Oto część, która ma znaczenie dla Twoich przychodów. Przycisk sam z siebie niczego nie zwraca. Otwiera wniosek, Apple potrzebuje do 48 godzin na zatwierdzenie lub odmowę, a w przypadku zakupów konsumowalnych najpierw wysyła CONSUMPTION_REQUEST na Twój serwer. Arkusz nie jest więc rozdawnictwem. To lejek prowadzący dokładnie do tej weryfikacji zwrotu, na którą już masz wpływ, i może odciągnąć spór od sieci kartowej, zanim stanie się obciążeniem zwrotnym, którego nie możesz zakwestionować.

Czym naprawdę jest arkusz wniosku o zwrot środków wewnątrz aplikacji

beginRefundRequest to metoda StoreKit 2, która wyświetla arkusz wniosku o zwrot dla transakcji w scenie okna. Sygnatura jest krótka: func beginRefundRequest(in scene: UIWindowScene) async throws -> Transaction.RefundRequestStatus. Gdy ją wywołasz, system pokazuje arkusz ze szczegółami zakupu klienta i listą kodów powodów do wyboru. Apple buduje i kontroluje ten interfejs. Ty dostarczasz scenę i transakcję, nic więcej.

Wskazówka Apple co do miejsca umieszczenia jest jednoznaczna. Wywołuj tę funkcję z ustawień konta lub menu pomocy, tak aby klient chcący zwrotu znalazł ją tam, gdzie szukałby wsparcia. Pojawiła się w iOS 15 i iPadOS 15, Mac Catalyst 15 oraz visionOS 1, więc każda aplikacja celująca w te wersje może ją dziś wyświetlić.

Dwa sposoby otwarcia arkusza

Są dwa punkty wejścia. Możesz wywołać beginRefundRequest(in:) na konkretnej transakcji, którą już posiadasz, co ogranicza arkusz do tego jednego zakupu. Możesz też otworzyć arkusz według identyfikatora produktu, gdy chcesz, aby klient zwrócił zakup danego produktu. Tak czy inaczej arkusz, lista powodów i decyzja należą do Apple. Twoje zadanie kończy się na wyświetleniu go i odczytaniu wyniku.

Co zwraca wywołanie i co może pójść nie tak

Metoda jest async throws, więc albo zwraca status, albo rzuca błąd. Oba to krótkie listy i oba warto obsłużyć, aby Twój interfejs mówił coś prawdziwego po zamknięciu arkusza.

Co dzieje się na Twoim serwerze po tym, jak klient dotknie przycisku wyślij

Zamknięcie arkusza to początek procesu, nie koniec. Apple sprawdza wniosek i potrzebuje do 48 godzin na zatwierdzenie lub odmowę. W przypadku konsumowalnego zakupu w aplikacji, zanim zdecyduje, App Store wysyła na Twój serwer powiadomienie CONSUMPTION_REQUEST z prośbą o dane o użyciu. Jeśli klient wyraził zgodę na udostępnienie tych danych, odpowiadasz przez endpoint Send Consumption Information. Jeśli nie wyraził zgody, własna instrukcja Apple mówi, aby w ogóle nie odpowiadać na powiadomienie.

Gdy Apple zdecyduje, wynik ląduje na Twoim serwerze jako App Store Server Notification. To ten sam kanał, który już otrzymujesz, a wniosek wewnątrz aplikacji trafia do niego dokładnie tak samo jak zwrot, który klient rozpoczyna na stronie reportaproblem Apple. Nic w obsłudze się nie zmienia tylko dlatego, że wniosek zaczął się w Twojej aplikacji.

Ile kosztuje Cię ten przycisk i co może zaoszczędzić

Zwrot, który możesz zakwestionować, jest lepszy niż obciążenie zwrotne, którego zakwestionować nie możesz

Klient, który nie znajdzie ścieżki zwrotu wewnątrz Twojej aplikacji, nie poddaje się. Idzie do swojego banku. Obciążenie zwrotne karty jest w banku ostateczne, wiąże się z opłatą za spór i odbiera decyzję zarówno z Twoich rąk, jak i Apple. Wewnątrzaplikacyjny wniosek o zwrot utrzymuje tego samego klienta w systemie Apple, gdzie zakup konsumowalny wywołuje CONSUMPTION_REQUEST, na które możesz odpowiedzieć, i decyzję, na którą możesz wpłynąć. Zamiana niezaskarżalnego obciążenia zwrotnego na zaskarżalną weryfikację Apple to cały finansowy argument za tym przyciskiem.

Obniżasz próg dla zwrotu

Uczciwa przeciwwaga jest taka, że widoczna ścieżka zwrotu w jednym dotknięciu generuje więcej wniosków o zwrot niż ukryty e-mail do wsparcia. Niektóre z nich nigdy by się nie zdarzyły. To realny koszt i dlatego Apple mówi Ci, aby umieścić punkt wejścia w ustawieniach konta lub menu pomocy, a nie na ekranie zakupu. Chcesz, aby znalazł go klient, który jest już niezadowolony, a nie ten, który jest jedynie ciekawy.

Koszt, który biegnie przez cały czas, to obsługa konta ze zwrotem

Jakkolwiek zapadnie decyzja, licznik dostawy biegnie dalej, dopóki nie zareagujesz na wynik. Za każdą godzinę, w której uprawnienie ze zwrotem pozostaje aktywne, dalej płacisz realne koszty za nim stojące: moc obliczeniową, wywołania API modelu, przechowywanie oraz każdą wypłatę dla twórcy lub partnera powiązaną z użyciem tego klienta. Wniosek wewnątrz aplikacji tego nie zmienia. Zmienia to szybkie cofnięcie przy powiadomieniu REFUND. Przycisk jest tak tani, jak Twoja obsługa powiadomienia, które ostatecznie generuje.

Czy powinieneś wdrożyć wewnątrzaplikacyjny wniosek o zwrot

Umieść go tam, gdzie mieszka wsparcie, nie tam, gdzie mieszka sprzedaż

Trzymaj się wskazówek Apple co do umieszczenia. Ustawienia konta i menu pomocy to właściwe miejsca. Link do zwrotu obok paywalla uczy ludzi, aby oczekiwali zwrotu pieniędzy, i zaprasza do zwrotu z ciekawości, którego nigdy nie musiałeś oferować.

Przetestuj cały przepływ w piaskownicy, zanim mu zaufasz

Możesz zasymulować całą ścieżkę w piaskownicy i w testach StoreKit w Xcode, przenosząc wniosek z w toku na zatwierdzony lub odrzucony. Zatwierdzenie dostarcza powiadomienie REFUND na Twój serwer, a odmowa dostarcza REFUND_DECLINED, dzięki czemu możesz udowodnić, że Twój handler reaguje poprawnie, zanim prawdziwy klient kiedykolwiek dotknie przycisku wyślij.

Obsłuż każdy wynik i nigdy nie obiecuj za dużo

Przy success pokaż w toku, przy failed zaoferuj ponowną próbę, przy userCancelled powiedz, że nic się nie zmieniło, a duplicateRequest potraktuj jako cichą notatkę, że wcześniejszy wniosek klienta wciąż obowiązuje. Jeden błąd, który boli, to powiedzenie klientowi, że jego zwrot jest gotowy, gdy trzymasz w rękach jedynie złożony wniosek.

Jak RefundHalt obsługuje to, co dzieje się później

Arkusz wewnątrz aplikacji należy do Apple. To, co po nim następuje, należy do Ciebie i to jest część, którą prowadzi RefundHalt. Gdy klient wysyła zwrot z wnętrza Twojej aplikacji, RefundHalt przechwytuje CONSUMPTION_REQUEST dla zakupów konsumowalnych i odpowiada na nie w oknie 12 godzin dowodami użycia, które pomagają Apple zdecydować. Gdy Apple zdecyduje, cofa przy REFUND i pozostawia dostęp nietknięty przy REFUND_DECLINED, każdy powiązany z dokładną transakcją. Możesz zaoferować przyjaźniejszą wewnątrzaplikacyjną ścieżkę zwrotu, nie pozostawiając weryfikacji, dowodów ani cofnięcia ręcznej krzątaninie.