Adam Grudziński

Algebra i Spółka ·

Cennik w pliku, Premium i pierwsza bramka płatności

Chciałem sprzedawać godziny lekcji, a musiałem zająć się cennikiem, dostępami i potwierdzeniami wpłat. Najwięcej nauczyła mnie płatność, którą operator uznał za zakończoną, podczas gdy Algebra nadal czekała na pieniądze.

Przejdź do tekstu

Kiedy zaczynałem Algebrę, sprzedawać chciałem tylko jedno: godzinę lekcji. Strona miała pokazać cenę i pozwolić wybrać termin w kalendarzu, a reszta miała się odbyć tak jak zawsze, między mną a uczniem. Z czasem okazało się, że za każdą lekcją stoi cały mały system: cennik, pakiety, rabaty, raty, płatności, dostęp do materiałów i ktoś, kto tym wszystkim zarządza. Ten wpis jest o tej mniej widocznej części platformy.

Cennik w zwykłym pliku

Pierwszy cennik Algebry nie leżał w bazie danych, tylko w pliku z ustawieniami. Zapisałem w nim długości lekcji i ich ceny, pakiety po kilka spotkań z rabatem, ceny zajęć grupowych od osoby i liczbę rat. Strona odczytywała ten plik przy uruchomieniu i na jego podstawie układała ofertę.

Na początku było to wygodne, bo cały cennik miałem w jednym miejscu, czytelny jak lista zakupów. Z czasem zaczęło jednak uwierać, bo każda zmiana ceny oznaczała poprawkę w pliku i wypuszczenie nowej wersji strony, a jeden źle postawiony przecinek potrafił sprawić, że strona nie odczytała żadnego z ustawień. Na wiosnę cennik trafił do bazy razem z resztą ustawień i od tej pory zmiana ceny nie wymaga już nowej wersji strony.

Ten sam pomysł, czyli treść i ceny, które właściciel zmienia sam, bez programisty, wracał potem w kolejnych projektach. Na stronie Duostrings edytowało się już całą treść, a w końcu zrobił się z tego Panel Biznesu, w którym właściciel firmy poprawia swoją stronę prosto na podglądzie.

Panel administratora

Panel administratora, w którym widzę rezerwacje i odpowiadam na wiadomości, był w Algebrze od pierwszego dnia. Jego adres nie jest publiczny i nie ma go w kodzie strony, tylko w ustawieniach serwera. Z czasem dochodziły kolejne zakładki: kalendarz z blokadami i urlopami, lista uczniów, płatności, a latem osobna sekcja finansów.

Po drodze zdarzyło mi się też zbudować za dużo. W lutym powstał rozbudowany system ról i uprawnień, z tabelą, kto co może, dziennikiem zdarzeń i nadawaniem ról w osobnym okienku, jak w dużej firmowej aplikacji. W lipcu wyciąłem go niemal w całości i zostały dwie proste role: administrator i uczeń. Przy jednej osobie, która zarządza platformą, taki system był na wyrost, a przy każdej zmianie trzeba było o nim pamiętać.

Premium, o którym na początku nie myślałem

Na początku Algebra miała tylko umawiać lekcje, a zadania i gry były dodatkiem dla moich uczniów. Kiedy jednak zbiór zadań urósł do kilku tysięcy pozycji z rozwiązaniami krok po kroku, zrobiła się z niego rzecz, z której ktoś może korzystać bez lekcji ze mną.

W lipcu doszedł więc abonament Premium za 29,99 zł miesięcznie. Za darmo zostaje dzienny limit zadań, a Premium ten limit znosi. W panelu administratora mogę nadać Premium ręcznie, z datą od i do, co przydaje się przy uczniach z pakietem lekcji albo przy testach. Pierwsze tygodnie Premium to było zresztą głównie łatanie dziur: poprawiałem błąd przy odbieraniu dostępu i darmowy limit, który dało się obejść.

Strona Premium na Algebrze i Spółce: cena 29,99 zł miesięcznie i porównanie z wersją darmową
Strona Premium: cena, co odblokowuje i porównanie z wersją darmową.

Konto korepetytora

Pod koniec lipca doszła trzecia rola. Tablica, na której prowadzę lekcje, zainteresowała innych korepetytorów, więc Algebra dostała panel nauczyciela, w którym każdy ma własnych uczniów i własne tablice, a nic nie miesza się z moimi. To pierwszy moment, w którym platforma przestała być wyłącznie moja, więc każdą funkcję trzeba było przemyśleć jeszcze raz pod kątem tego, kto co widzi.

HotPay, Stripe i płatności, które nie dochodziły

Pierwszym operatorem płatności, na którym uczyłem się, jak to wszystko działa, był Stripe, podpięty jeszcze w pierwszej wersji Algebry. Po kilku dniach przeszedłem na HotPay i przy nim zostałem. Płatność w sieci ma dwie połowy, a o drugiej łatwo zapomnieć. Pierwsza to przejście klienta na stronę operatora, gdzie płaci, i jego powrót do Algebry. Druga to osobne powiadomienie, które operator wysyła prosto do serwera Algebry, i dopiero ono mówi aplikacji, że pieniądze naprawdę wpłynęły.

Pod koniec lipca okazało się, że działała u mnie tylko pierwsza połowa. W bazie leżało kilkanaście płatności rozpoczętych i ani jednej zakończonej. Zrobiłem sobie narzędzie, które tworzy testową płatność na złotówkę, i od razu trafiłem na pierwszą niespodziankę: operator doliczał do koszyka 6,99 zł, więcej niż wynosiła sama płatność. Był to dobrowolny program ochrony kupujących innej firmy, zaznaczany na stronie płatności. Nie jest to opłata sklepu i nie trafia z niej do mnie ani złotówka, ale klient widzi wyższą kwotę niż w ofercie, dlatego przed przyciskiem płatności pojawiło się ostrzeżenie, że to pole można zostawić puste.

Druga niespodzianka to komunikat, że brakuje tajnego klucza, który łączy sklep z operatorem płatności. Szukając przyczyny, znalazłem prawdziwy błąd, bo klucz na serwerze różnił się od tego w moich ustawieniach, i go poprawiłem. Komunikat jednak wracał, aż sprawdziłem, że pojawia się po prostu wtedy, gdy link do płatności jest za stary. Wniosek był prosty: link trzeba tworzyć tuż przed płatnością, a nie godzinę wcześniej.

Wreszcie zapłaciłem pięć złotych BLIKiem. Operator pokazał, że płatność się udała, a moja aplikacja dalej widziała ją jako oczekującą. Świeżo włączony Sentry, czyli narzędzie, które zbiera błędy z serwera, nie odnotował żadnego powiadomienia od operatora. Winny okazał się adres powiadomień ustawiony w panelu HotPaya: wskazywał na stronę Algebry zamiast na serwer, który przechowuje dane, więc powiadomienie trafiało do części oglądanej w przeglądarce, a ta nie miała pojęcia, co z nim zrobić. Po poprawce adresu powiadomienia zaczęły dochodzić, a jedną płatność, która utknęła po drodze, domknąłem ręcznie.

Co z tego wyniosłem

Z tej historii zostały mi trzy wnioski. Test prawdziwymi pieniędzmi, choćby pięcioma złotymi, mówi więcej niż tydzień czytania kodu. Adres powiadomień jest tak samo ważny jak sam kod, choć ustawia się go w zupełnie innym miejscu, w panelu operatora płatności. Wreszcie, zanim poprawię błąd, warto sprawdzić, czy to na pewno on wywołuje kłopot, bo w tej historii prawdziwy, ale niewinny błąd prawie zasłonił właściwą przyczynę.

Cała seria

To czwarta część serii o tym, jak powstawała Algebra i Spółka:

  1. Pierwsza Algebra: Flask, szablony i PHP, z którego szybko zrezygnowałem
  2. Rezerwacje, które znikały po każdym wdrożeniu
  3. Algebra od nowa: z szablonów Flaska na Reacta i TypeScript
  4. Cennik w pliku, Premium i pierwsza bramka płatności
  5. Zadania, karta wzorów i rysunki, które nie chciały się zgadzać

Jak całość wygląda dzisiaj, opisuję we wpisie Algebra i Spółka od środka.