Powrót klienta na stronę „sukces” nie potwierdza płatności. Decyzja o opłaceniu zamówienia musi wynikać z poprawnie zweryfikowanego zdarzenia operatora oraz zgodności danych transakcji.
Przeglądarka klienta nie jest źródłem prawdy
Klient może zamknąć kartę po zapłacie albo wrócić na stronę bez zakończenia transakcji. Adres przekierowania pomaga w obsłudze interfejsu, lecz nie powinien sam aktywować usługi. Proces musi poprawnie obsłużyć powiadomienie serwerowe i jego weryfikację według zasad bramki.
Użyj modułu zgodnego z wersją FOSSBilling i operatorem. Nazwa operatora na liście dodatków nie gwarantuje aktualności konkretnego adaptera. Sprawdź źródło, sposób utrzymania i dokumentację, zanim wpiszesz produkcyjne klucze.
Testuj dane, nie tylko status
Zdarzenie musi dotyczyć właściwego zamówienia, kwoty i waluty. Zweryfikuj podpis lub metodę autoryzacji wskazaną przez operatora. Nie ufaj dowolnej wartości status=paid przesłanej do publicznego endpointu. Klucze testowe i produkcyjne przechowuj oddzielnie.
W logach zachowuj identyfikator transakcji, zamówienia i wynik weryfikacji. Nie zapisuj pełnych danych kart ani sekretów. Przy błędzie powinno dać się prześledzić zdarzenie bez ujawniania danych klienta całemu zespołowi.
Duplikaty są normalnym scenariuszem
Operator może ponowić powiadomienie, gdy nie otrzyma odpowiedzi albo połączenie zostanie przerwane. Jedno zdarzenie przetworzone kilka razy nie powinno utworzyć kilku serwerów ani kilka razy zwiększyć salda. Integracja musi kontrolować powtórzenia i spójnie zapisywać wynik.
Nie twórz samodzielnie prowizorycznej aktywacji na podstawie e-maila z bramki. Jeśli moduł nie daje oczekiwanych gwarancji, popraw go lub zastosuj świadomie ręczny proces zamiast wystawiać automatyczne zamówienia publicznie.
Scenariusze do próby przed startem
| Scenariusz | Oczekiwany rezultat |
|---|---|
| Płatność udana | Jedno rozliczenie i właściwy dalszy proces. |
| Płatność przerwana | Brak bezpodstawnej aktywacji. |
| Powtórzone powiadomienie | Brak drugiej aktywacji lub podwójnego salda. |
| Błędna kwota lub podpis | Odrzucenie i czytelny zapis diagnostyczny. |
| Awaria tworzenia usługi | Stan możliwy do obsługi, nie ukryty „sukces”. |
Testy wykonuj w środowisku operatora przeznaczonym do prób. Zwrot, spór i opóźnione potwierdzenie również mają znaczenie, jeśli oferta ma je obsługiwać. Ustal procedurę ręcznego sprawdzenia bez przypadkowego zmieniania statusów faktur.
Monitoring po uruchomieniu
Obserwuj niepotwierdzone płatności, błędy webhooka i rozbieżność między zapłatą a usługą. Alert na niedostępny endpoint jest użyteczny, ale nie zastępuje kontroli biznesowej. Wykonuj kopie bazy i zapisuj zmiany konfiguracji.
Instalacja FOSSBilling opisuje fundamenty środowiska. Dla aplikacji na Castpol sprawdź HTTPS, dostępność callbacków i zadania w tle. Dokładna implementacja płatności wymaga dokumentacji wybranej bramki; ten materiał jest listą kontroli procesu, nie gotowym adapterem.
Źródła i dokumentacja
Dokumentacja do dalszej weryfikacji ustawień i wymagań swojej wersji.