PrestaShop jest zbudowany wokół jednorazowego aktu: jeden koszyk, jedno zamówienie, jedna płatność. Subskrypcja zakłada coś odwrotnego, zobowiązanie generujące płatności w czasie bez powrotu klienta. Te dwa modele nie spotykają się same z siebie.
Oto architektura, która działa, i miejsca, w których wdrożenia się łamią.
Kto trzyma prawdę
Pierwsza decyzja, i to ona warunkuje całą resztę.
Platforma płatności taka jak Stripe ma kompletny silnik rozliczeń cyklicznych: subskrypcje, terminy, ponowne próby, obsługę wygasłych kart. Odbudowywanie tego w PrestaShop byłoby błędem.
Podział, który się broni: Stripe trzyma subskrypcję, czyli cykl, terminy i pobranie środków. PrestaShop trzyma katalog, klienta i zamówienia generowane przy każdym terminie.
W praktyce każde udane obciążenie tworzy zamówienie w PrestaShop, które przechodzi potem wasz zwykły proces kompletacji i wysyłki. To właśnie pozwala zachować spójne statystyki, faktury i logistykę.
Webhooki, których trzeba słuchać
To serce integracji i miejsce, w którym naprawdę leży praca.
Pięć zdarzeń trzeba obsłużyć, każde z określonym zachowaniem.
- Udana płatność okresowa. Tworzy zamówienie w PrestaShop, zmniejsza stan magazynowy, wysyła maila potwierdzającego.
- Nieudana płatność. Nie tworzy zamówienia, wstrzymuje subskrypcję, uruchamia sekwencję ponagleń.
- Zaktualizowana subskrypcja. Zmiana planu, ilości albo daty. Musi odbić się po stronie sklepu.
- Anulowana subskrypcja. Odcina dostęp, jeśli sprzedajecie treści, zatrzymuje wysyłki, jeśli sprzedajecie towar.
- Wygasający środek płatności. Uruchamia przypomnienie przed niepowodzeniem, co pozwala uniknąć przerwy.
Trzy zasady techniczne dotyczące webhooków. Sprawdzajcie podpis każdego powiadomienia, inaczej każdy może tworzyć u was zamówienia. Obsługujcie je idempotentnie: to samo zdarzenie może zostać dostarczone kilka razy, a wy nie możecie utworzyć dwóch zamówień. I odpowiadajcie szybko potwierdzeniem odbioru, a przetwarzajcie w tle, bo inaczej platforma uzna wywołanie za nieudane i je powtórzy.
DataFirefly Subscriptions: subskrypcje i płatności cykliczne Stripe dla PrestaShop 8 i 9Moduł subskrypcji dla PrestaShop 8 i 9: karta zapisana w Stripe, dunning, samoobsługowy panel klienta.€169,00
Wygasłe karty, pierwsza pozycja strat
Przy subskrypcji większość wymuszonych rezygnacji bierze się ze środka płatności, który przestał być ważny, a nie z decyzji klienta.
Trzy mechanizmy sumują się, żeby ograniczyć straty. Automatyczna aktualizacja kart, oferowana przez organizacje kartowe i przekazywana przez platformy płatności, która pobiera nowy numer bez ingerencji. Przypomnienie przed wygaśnięciem, uruchamiane miesiąc przed końcem ważności. Oraz sekwencja ponownych prób po niepowodzeniu, rozłożona na jeden do dwóch tygodni, a nie powtarzana nazajutrz.
Przewidzcie okres karencji, w którym usługa pozostaje aktywna mimo niepowodzenia. Odcięcie natychmiast zamienia incydent bankowy w ostateczną rezygnację.
Proces zamówienia: nie mieszać
Kwestia projektowa rozstrzygana często za późno. Koszyk zawierający subskrypcję i produkty kupowane jednorazowo tworzy problem: pierwsza rodzi zobowiązanie cykliczne, drugie nie.
Dwa akceptowalne podejścia. Dedykowany proces, w którym subskrypcję wykupuje się osobno, bez możliwości dodania czegokolwiek. Prostszy, czytelniejszy dla klienta, i to jest zalecany wybór domyślny.
Albo koszyk mieszany, gdzie pierwsze zamówienie zawiera jedno i drugie, z jedną płatnością pokrywającą produkty i uruchamiającą subskrypcję. Technicznie cięższe i trzeba być bardzo jasnym co do tego, co zostanie pobrane później.
Czego nie robić: zostawiać dwóch różnych subskrypcji w jednym koszyku. Cykle rozliczeniowe rozjeżdżają się natychmiast, a zarządzanie staje się nie do rozplątania.
Silne uwierzytelnianie
Europejskie przepisy o płatnościach wymagają uwierzytelnienia posiadacza karty przy wielu transakcjach. Przy subskrypcji pierwszą płatność uwierzytelnia klient, kolejne podlegają innym ramom, ponieważ inicjuje je sprzedawca.
Dwie praktyczne konsekwencje. Zgoda musi zostać poprawnie zapisana przy pierwszej płatności, co platformy obsługują pod warunkiem, że zamiar płatności został utworzony z właściwymi parametrami. A niektóre terminy mogą mimo to wymagać uwierzytelnienia, co zakłada przewidzianą ścieżkę sprowadzającą klienta na stronę uwierzytelnienia, zamiast cichego niepowodzenia.
Ramy prawne
Trzy obowiązki, kontrolowane przez UOKiK i regularnie pomijane.
Informacja przed zawarciem umowy: czas trwania, kwota, częstotliwość i zasady rezygnacji muszą być widoczne na stronie zakupu, a nie tylko w regulaminie.
Rezygnacja online, tak samo prosta jak zawarcie umowy, dostępna z panelu klienta bez konieczności pisania czy dzwonienia.
Informacja przed przedłużeniem dla subskrypcji odnawianych automatycznie, w terminie zostawiającym klientowi czas na odmowę.
Trzy liczby tego modelu
Miesięczny przychód powtarzalny, który daje podstawę ekonomiczną. Miesięczny wskaźnik rezygnacji, z rozróżnieniem rezygnacji dobrowolnych i niepowodzeń płatności, bo lekarstwa są inne. Oraz średni czas życia subskrybenta, który wynika z drugiego i wyznacza, ile możecie wydać na jego pozyskanie.
Moduł DataFirefly Subscriptions dla PrestaShop wdraża tę architekturę na PrestaShop 8 i 9: subskrypcje oparte na Stripe, automatyczne tworzenie zamówień przy każdym terminie, obsługa webhooków z weryfikacją podpisu, zarządzanie niepowodzeniami płatności i panel klienta do zmiany lub rezygnacji.