Proces płatności cyklicznych w aplikacji SaaS

W aplikacjach typu SaaS, płatności zwykle odbywają się cyklicznie co okres. Okresem zazwyczaj jest miesiąc lub rok. Choć czasem można spotkać kwartał, pół roku, itp… Opiszę Ci tutaj proces płatności, rozliczania i tworzenia abonamentów w mojej aplikacji typu SaaS – beTimes.pl

Z pewnością nie jest to proces idealny, niemniej działa sprawnie i być może okaże się dla Ciebie inspiracją.

Początki

Na początku płatności nie było. Wolałem skupić się rdzeniu funkcjonalności. Abonamenty jednak naliczały się od początku. A okres można było przedłużyć klikając przycisk „zapłać”. Nie prowadził on do płatności a tylko technicznie wydłużał dostęp.

Okres testowy na samym początku trwał aż 60 dni. Pierwszym zarejestrowanym użytkownikom i tak ręcznie przedłużałem dostęp z tygodnia na tydzień. A było to związane z opóźnieniem wdrożenia procesu płatności.

Ostatecznie, większości osób termin wydłużył się do 19 maja. I to tydzień wcześniej poszły pierwsze maile z informacją, że (w końcu) za tydzień kończy ci się okres testowy.

Wpadła pierwsza, druga, trzecia płatność… I to od osób, od których bym się tego nie spodziewał…

Założenia

Na beTimes.pl przyjąłem model free trial. Czyli najpierw daję czas na testy aplikacji a dopiero potem oczekuję płatności. Aktualnie okres testowy wynosi równe 30 dni.

W tym czasie dostępne są wszelkie funkcje, a i limity dość wysokie. Po upływie okresu, niestety konto przestaje działać. Panel użytkownika jest ograniczony – następuję przekierowanie do procesu płatności. A wygenerowane liczniki przestają działać.

Proces płatności cyklicznych w aplikacji SaaS

Wg różnych źródeł, w ok 95% przypadków serwisów SaaS, podobno wystarczy 14 dni na testy. A zależy to głównie od czasu wdrożenia rozwiązania. Innymi słowy, okres testowy powinien trwać tyle, by testujący użytkownik mógł zauważyć korzyści z używania narzędzia.

W przypadku beTimes.pl, docelowo, wydaje mnie się, że 14 dni, może być wystarczające. Zatem nie wykluczone, że ten okres zostanie zmniejszony.

Aktualnie nie ma możliwości podpięcia karty, ani np. subskrybcji PayPal. Zatem co okres (miesiąc, rok), użytkownik musi ręcznie dokonać płatności. Ale jest to możliwie bardzo uproszczone… 🙂

Co, jeśli skończy się okres próbny?

7 dni przed końcem okresu próbnego zaczynam wysyłać maile. Tzn. zaczynają się wysyłać automatycznie. Każdy email ma inny tytuł i nieco inną treść, w której m.in. podana jest ilość dni pozostałych do końca darmowego okresu.

Wysyłanych jest ok 3-4 maili zawierających bezpośredni link do ekranu z procesem płatności.

Kiedy okres minie, następnego dnia wysyłany jest email z informacją, że konto zablokowane, liczniki przestały działać… Potem jeszcze kilka takich maili przypominających…

Wszelkie maile przypominające o płatności wysyłane są do użytkowników, którzy potwierdzili swoje konto – link aktywacyjny na email. Jeśli by tego nie zrobili, to po ok 3 dniach, konto i tak nie byłoby użyteczne – wymuszałoby aktywację.

Proces płatności

W każdym wysyłanym mailu jest przycisk-link prowadzący do procesu płatności.

Pierwszy ekran, to wybór pakietu.

Pakiety różnią się limitem ilości liczników oraz zarejestrowanych leadów. I oczywiście ceną.

Domyślnie wyświetlone są pakiety z cenami w rozliczeniu miesięcznym. Jest też możliwość zmiany rozliczenia na roczne.

Wybierając rozliczenie roczne, aktualnie można liczyć na 10% zniżki. Ceny w pakietach rocznych pokazują się w skali miesiąca – wyróżnione, a pod spodem w skali roku, czyli tyle, ile użytkownik faktycznie musi zapłacić.

Proces płatności cyklicznych w aplikacji SaaS

Jeśli user założył konto z linku partnerskiego, to ma przyznaną zniżkę partnerską. Jest ona od razu uwzględniana w obliczeniach, a informacja ta też widnieje na samej górze ekranu.

Ceny po uwzględnieniu wszelkich zniżek, zaokrąglane są w dół do pełnych złotówek – aby uprościć i poprawić estetykę. Wyświetlane ceny są netto, na dole znajduje się odpowiednia adnotacja.

Po wybraniu pakietu, technicznie tworzony jest płatny abonament ze statusem – oczekujący.

Dodam jeszcze, że kroki procesu płatności, znajdują się na minimalistycznym szablonie aplikacji. Nie ma górnego menu – zostało tylko logo. Z boku jest też widoczna ikonka pomocy. Poza tym, tylko przyciski akcji, typu wybierz pakiet, dalej, zapłać…

Dane fakturowe

Drugi, obowiązkowy krok. Najpierw możliwość wyboru, czy faktura na firmę, czy osobę nieprowadzącą działalności. Ten wybór wpływa na ilość pól i ich walidację (nazwa firmy, NIP, VAT).

Poza standardowymi polami niezbędnymi do wystawienia faktury, dałem możliwość wyboru naliczanego podatku VAT. Od początku miałem klientów z UE (spoza Polski), którym należało wystawić fakturę z odwrotnym obciążeniem. Zatem user ma możliwość wyboru, VAT 23% lub o. o.

Na samym dole konieczna była adnotacja o przetwarzaniu danych 🙂

Proces płatności cyklicznych w aplikacji SaaS

Podsumowanie zamówienia

Ostatni krok to podsumowanie.

Znajduje się tam informacja o wybranym pakiecie, jego parametrach i okresie rozliczeniowym. Również dane fakturowe oraz konkretne kwoty brutto i netto. I najważniejsze – przycisk, przejdź do płatności.

Proces płatności cyklicznych w aplikacji SaaS

Poza tymi informacjami, są tekstowe linki do zmiany pakietu, aktualizacji danych fakturowych i pobrania proformy.

Na dole tego ekranu jest też szary banner od Tpay z logami banków i metod płatności.

Integracja z systemem płatności

W tym momencie następuje przekierowanie do systemu obsługującego płatności. Jest to tpay.com.

Głównymi argumentami przy wyborze pośrednika płatności, były dobre opinie oraz integracja z PayPalem. Dzięki tej decyzji, obsługę płatności poprzez PayPal włączyłem w ciągu 2.5 minuty.

Jak w większości systemów, można dokonać przelewu z chyba każdego banku, zapłacić BLIKiem, albo wypełnić druczek przekazu pocztowego.

Proces płatności cyklicznych w aplikacji SaaS

Po zrobieniu przelewu, następuje oczywiście przekierowanie z powrotem do aplikacji.

Ja tam wyświetlam entuzjastyczne podziękowanie, informację o tym co się stało i że faktura dojdzie w ciągu godziny. Niżej przycisk przekierowania do do serwisu, do listy liczników.

Przedłużenie dostępu

Technicznie, w ciągu kilku sekund (na razie nie było opóźnień) otrzymuję od Tpay potwierdzenie płatności. Wtedy abonament aktywuje się. Użytkownik ma przedłużony okres dostępu, albo odblokowany.

Oczywistym jest, że jeśli klient opłaca przed końcem obecnego okresu, to nowy naliczamy od momentu końca obecnego 🙂

Dla uproszczenia obliczeń, ale na korzyść klienta, przyjąłem, że miesiąc ma 31 dni. Przez co przy płatności rocznej klient zyskuje dodatkowo tydzień 🙂

Faktury

Co godzinę uruchamia się skrypt, który wystawia fakturę i wysyła klientowi na email. Jest integracja z fakturownia.pl. Nie korzystam z opcji wysyłania, którą oferuje system. Sam wysyłam maila, w którym załączam PDF.

Również proformę, którą można pobrać w ostatnim kroku podsumowującym, generowana jest w fakturowni.

W panelu klienta, na liście płatności również jest możliwość pobrania faktury – jeśli abonament opłacony i proformy jeśli nie opłacony.

Faktury wystawiane klientom beTimes.pl, mają inny szablon graficzny niż pozostałe.

Kolejne okresy

Przed końcem płatnego okresu rozliczeniowego, historia powtarza się. Wysyłam maile przypominające. Różnica jest taka, że kieruję od razu do 3 kroku – podsumowania. Tam już tylko jeden przycisk dzieli klienta od przejścia do Tpay.

Proces płatności aplikacja SaaS

Wcześniej, przed wysyłką maili, tworzą się nowe, jeszcze nieaktywne abonamenty i to na tej podstawie dokonywana jest płatność.

Z jednej strony jest to uproszczenie dla klienta, z drugiej jednak, być może ograniczam możliwość zmiany pakietu i okresu rozliczeniowego…

Pełna (prawie) automatyzacja

Założenie było takie, bym ja, poza supportem, nie musiał mieć absolutnie żadnego udziału w tym procesie. Prawie się udało 🙂 Abonamenty tworzą się same, wysyłają się maile, płatności są zintegrowane, okresy przedłużają się a faktury wystawiają.

Nie wyeliminowałem możliwości zapłaty tradycyjnym przelewem. Stąd też pojawiły się proformy. Dopuszczam taką możliwość, bo skoro klient tego potrzebuje, to nie chcę utrudniać mu życia.

I robię to ręcznie. Kiedy dostrzegę nowy przelew na koncie, to ręcznie aktywuję abonament użytkownikowi. Na szczęście uprościłem to maksymalnie – wystarczy kliknąć jeden przycisk, a reszta dzieje się sama.

Co do poprawy i jakie dalsze plany?

Z jednej strony, skoro coś działa, to po co to zmieniać 🙂 Ale z drugiej, mamy teraz podstawę do optymalizacji.

Z pewnością, do rozważenia (nie w najbliższej) przyszłości będą subskrybcje, czyli płatności automatycznie pobierane co okres, z karty kredytowej lub PayPala.

Z bardziej przyziemnych, na pierwszym ekranie, z pakietami, chciałbym wyróżnić roczny okres rozliczeniowy. Nie chcę ustawiać go jako ekran główny, rozważam dodanie jakieś animowanej strzałki…

Po głowie chodzi mi też dodanie kolejnego kroku do procesu – mianowicie One Time Offer – jednorazowa oferta, gdzie damy użytkownikowi możliwość zakupu pakietu rocznego w jeszcze niższej cenie, ale na podjęcie decyzji ma X minut… Do rozważenia 🙂

Podsumowując
Mam nadzieję, że droga jaką wybrałem do realizacji płatności, zainspiruje Cię i że wykorzystasz choć kawałek tej wiedzy w praktyce.

Jeśli masz pytania, sugestie, albo chcesz się podzielić swoimi metodami, to pisz śmiało w komentarzu.

Weź się ogarnij

Moje 7, najlepszych, sprawdzonych
sposobów na efektywną pracę zdalną
Do wdrożenia jeszcze dziś!



Ta strona wykorzystuje pliki cookies. Korzystanie ze strony oznacza zgodę na ich zapis lub odczyt wg ustawień przeglądarki. Więcej informacji znajdziesz w polityce prywatności. OK, rozumiem