Decyzja
Projektowanie opłat zaczyna się od tego, z czego klienci mają prawo korzystać i kiedy to uprawnienie się zmienia. Płatności, faktura i subskrypcja są powiązane, ale różne pojęcia; dokumentacja dostawcy, taka jak przewodnik cyklu życia Stripe sprawia, że rozróżnienie widoczne. Twoja aplikacja nadal potrzebuje wyraźnej polityki dostępu.
Przykład roboczy
Rozważ przykładowy miesięczny plan zespołu. Klient uaktualnia w połowie okresu, płatności wymaga dalszych działań, a administrator odświeża stronę. Zdecyduj, czy dostęp do starego planu pozostaje nierozwiązany. Pokaż oczekiwaną zmianę zamiast prezentowania niepotwierdzonej aktualizacji jako kompletnej.
Narysuj zmiany dostępu poza stanami płatności
Stwórz małą mapę stanu, która zawiera stan subskrypcji, dostęp do dotacji na produkt i wiadomość, którą klient widzi. Te kolumny nie muszą poruszać się jednocześnie. Anulowanie przewidziane do odnowienia może pozostawić dostęp aktywny do uzgodnionej granicy; nieudana początkowa płatność może pozostawać niekompletna. Zdefiniuj każde przejście z autorytatywnym zdarzeniem lub sprawdzaniem serwera, który go obsługuje. Wpisz, kto może poprosić o zmianę i co powinno się stać z pracy już zapisane. To sprawia, że obietnica klienta jest możliwa do przejrzenia, zanim konkretne zdarzenia provider- są podłączone do aplikacji.
Próba przerwania aktualizacji
Użyj urządzeń testowych dostawcy, aby rozpocząć aktualizację, przerwać przeglądarkę, powtórzyć powiadomienie i opóźnić jego przetwarzanie. Potwierdź, że produkt nie tworzy dwóch subskrypcji ani nie udziela planu tylko dlatego, że strona sukcesu została otwarta. Pokaż użytkownikowi status do odzyskania i udziel wsparcia dla dochodzenia bez ujawniania uwierzytelniania płatności. Jeśli stare zgłoszenie pojawi się po zmianie obecnego stanu, porównaj go z autorytatywnym stanem, a nie ślepo odwracając dostęp. Zapis, który komponent jest właścicielem uzgodnienia, jeżeli dostawca płatności i wniosek tymczasowo się nie zgadzają.
Uczyń anulowanie zrozumiałym dla klienta
Oddzielne zakończenie przyszłych rozliczeń, utrata dostępu do funkcji, praca eksportowa i usuwanie przechowywanych danych. Klienci nie powinni zgadywać, czy naciśnięcie anulować niszczy rekordy natychmiast lub zatrzymuje odnowienie. Zdecyduj, co się stanie z zaproszonymi kolegami i pracą w tle na granicy dostępu. Przedstaw nieodwracalny krok wyraźnie z odpowiednim potwierdzeniem i użyj rzeczywistej skonfigurowanej polityki zamiast uniwersalnej obietnicy. Przed uruchomieniem, mieć kogoś spoza zespołu implementacyjnego po wygaśnięciu próby, upgrade, nieudane płatności, anulowanie i reaktywacja w środowisku testowym. Ich pytania często ujawniają brakujące decyzje produktowe, których nie można ujawnić w wyniku udanych opłat.
Alternatywy warte ważenia
Można zastosować zmiany natychmiast, po odnowieniu lub po potwierdzeniu, w zależności od obietnicy i wspieranego zachowania dostawcy. Określ próbę wygaśnięcia, nieudanej zbiórki, anulowania i reaktywacji oddzielnie. Hosted ekrany rozliczeniowe mogą zmniejszyć niestandardową pracę interfejsu bez zastępowania reguł uprawnienia produktu.
Gdzie plan się psuje
Nie przyznawaj dostępu tylko dlatego, że przeglądarka powraca z konta. Sprawdź stan autorytatywny na serwerze i spraw, by powtarzające się powiadomienia były bezpieczne w przetwarzaniu. Zachowaj rekordy rozliczeń różne od członkostwa użytkownika w zespole, więc jedna zmiana konta nie nieoczekiwanie wymazuje innego związku.
Przed zleceniem pracy
Co się dzieje z zapisaną pracą po anulowaniu? Kto może zmienić plan? Jak wsparcie wyjaśnia wymaganą płatność? Odpowiedz na te pytania swoim partnerem rozwoju SaaS przed narysowaniem strony z kasą.
Źródła i dalsza lektura
Tworzenie SaaS
Produkt, z którego ludzie mogą korzystać, który mogą subskrybować i na którym mogą polegać.
Porozmawiaj o tej usłudze