Płatność Przelewy24 w formularzu na stronie: jak ją wdrożyć

Formularz z płatnością ma sens, gdy klient podaje dane do usługi i od razu opłaca określony etap, ale nie potrzebuje wybierać produktów ani dostawy. Sprawdza się przy zaliczce, konsultacji, rezerwacji terminu lub płatnej wycenie. Jeśli natomiast szukasz formularza kontaktowego do obsługi Przelewy24 w sprawie swojej płatności, skorzystaj z centrum pomocy operatora, a nie z integracji formularza na stronie sprzedawcy.

Przy sprzedaży produktów, magazynie i wysyłce rozważ WooCommerce. Przy jednej usłudze i krótkim formularzu wystarczy integracja, która zapisuje rekord zgłoszenia, tworzy płatność i aktualizuje status. Link płatniczy ogranicza prace techniczne, ale nie rozwiązuje samodzielnie powiązania wpłaty z formularzem.

Dobór modelu płatności jest częścią projektu checkoutu. Różnice między sposobami przyjmowania wpłat opisujemy w poradniku o płatnościach online w sklepie.

Płatność zaczyna się od zapisanego zgłoszenia, a nie od przekierowania do operatora. W REST API Przelewy24 sprzedawca rejestruje transakcję, otrzymuje token i przekierowuje klienta do panelu płatności. Po zakończeniu procesu operator wysyła powiadomienie na skonfigurowany adres, a serwer sklepu wykonuje weryfikację transakcji.

Przepływ dla formularza wygląda tak:

1. Klient wybiera usługę, termin lub wariant i wysyła formularz.
2. Serwer waliduje dane, oblicza kwotę według własnych reguł i zapisuje zgłoszenie ze statusem Oczekuje na płatność.
3. Serwer rejestruje transakcję Przelewy24, zapisując identyfikator zgłoszenia w swoim rekordzie i identyfikatorze sesji transakcji.
4. Klient przechodzi do operatora, wybiera metodę i autoryzuje płatność.
5. Po zakończeniu klient wraca na adres powrotu. Strona pokazuje stan zapisany w bazie, ale nie rozstrzyga sama, czy wpłata została potwierdzona.
6. Endpoint serwera odbiera powiadomienie, sprawdza jego autentyczność, a następnie wywołuje metodę weryfikacji transakcji.
7. Po zgodnej odpowiedzi serwer zmienia status zgłoszenia i uruchamia dalszą obsługę.

Dokumentacja Przelewy24 REST API opisuje rejestrację transakcji, powiadomienie i metodę `transaction/verify`. Operator zaznacza, że transakcja jest potwierdzona dopiero po weryfikacji. Powrót klienta służy nawigacji, natomiast serwerowe powiadomienie i weryfikacja ustalają stan płatności.

Każde zgłoszenie powinno mieć trwały identyfikator wygenerowany na serwerze, który pozwala odnaleźć je po identyfikatorze sesji transakcji. Dzięki temu obsługa dopasuje wpłatę nawet wtedy, gdy klient ponowi płatność lub zamknie przeglądarkę przed powrotem.

Ukryte pole formularza nie jest zaufanym źródłem kwoty ani statusu, bo klient może zmienić jego wartość w przeglądarce. Serwer powinien pobrać identyfikator zgłoszenia z własnej bazy, odczytać z niego usługę i ponownie obliczyć cenę. W ten sposób do Przelewy24 trafia kwota wynikająca z reguł sprzedawcy, a nie z edytowalnego formularza.

W WordPressie wybierz sposób integracji przed instalacją dodatków, bo formularz i bramka muszą współdzielić identyfikator zgłoszenia oraz status płatności. Przelewy24 udostępnia gotowe wtyczki dla platform sklepowych, w tym WooCommerce, ale formularz kontaktowy wymaga dodatku, który jawnie obsługuje płatności i zapis zgłoszeń, albo pracy dedykowanej.

Dla własnego formularza WordPress konkretna architektura może wyglądać następująco: formularz zapisuje zgłoszenie jako własny rekord, serwer tworzy transakcję przez REST API Przelewy24 v1, a webhook aktualizuje ten rekord po walidacji i weryfikacji. Jeśli korzystasz z dodatku do formularza, przed wyborem sprawdź, czy dokumentuje on zapis rekordu przed przekierowaniem, powiązanie z `sessionId`, odbiór powiadomienia i obsługę anulowania. Sama opcja dodania przycisku płatności nie potwierdza tych funkcji.

Kolejność wdrożenia:

1. Zdefiniuj formularz i regułę ceny. Określ wymagane dane, usługę, wysokość zaliczki oraz moment rozpoczęcia realizacji.
2. Wybierz integrację. Wymagaj od dostawcy dodatku wskazania obsługiwanych wersji WordPressa i formularza, sposobu zapisu zgłoszenia oraz mechanizmu weryfikacji transakcji. Jeśli tych informacji nie ma, zaplanuj integrację dedykowaną.
3. Skonfiguruj dane P24. W panelu przejdź do Moje konto > Moje dane > Ustawienia > Dane API i konfiguracja. Przelewy24 opisuje numer ID, CRC i klucz API; klucze przechowuj po stronie serwera, nie w kodzie przeglądarki.
4. Rozdziel powrót i powiadomienie. Adres powrotu pokazuje klientowi wynik sprawdzony w bazie. Adres statusu przyjmuje komunikat serwer-serwer.
5. Zapisuj każdy etap. Zgłoszenie, identyfikator sesji, transakcję, wynik weryfikacji i zwrot zapisuj jako historię jednego rekordu.
6. Uruchom testy. Sprawdź udaną płatność, anulowanie, powtórne powiadomienie i błąd weryfikacji przed publikacją formularza.

Jeśli formularz prowadzi do pełnego zamówienia z produktami i dostawą, prostszy w utrzymaniu może być Przelewy24 w WooCommerce. Koszty operatora i porównanie z alternatywami omawiają materiały o kosztach Przelewy24 oraz PayU i Przelewy24.

Serwer musi sprawdzić autentyczność powiadomienia oraz wykonać weryfikację transakcji przed oznaczeniem zgłoszenia jako opłaconego. Dokumentacja REST Przelewy24 przewiduje dodatkowe żądanie `transaction/verify` po otrzymaniu powiadomienia. Opisuje też podpis `sign` wyliczany z danych transakcji i klucza CRC.

Walidacja autentyczności i weryfikacja transakcji pełnią różne funkcje. Podpis pozwala sprawdzić, czy parametry komunikatu odpowiadają oczekiwanej wartości kontrolnej. Weryfikacja w API potwierdza transakcję po stronie Przelewy24. Zastosuj obie kontrole zgodnie z aktualną specyfikacją oraz zabezpiecz endpoint przed podejrzanymi wywołaniami; dokumentacja zaleca filtrowanie adresów IP dla połączeń przychodzących.

Przy weryfikacji porównuj identyfikator sesji, kwotę, walutę i identyfikator transakcji z zapisanym zgłoszeniem. Powiadomienia mogą być ponawiane, dlatego operacja musi być idempotentna: kolejne przetworzenie tej samej transakcji nie może drugi raz uruchomić usługi ani wysłać zduplikowanego zlecenia. Zapisuj czas, identyfikator zgłoszenia i wynik, ale nigdy klucze API.

Testuj cały obieg od zapisu zgłoszenia do statusu w bazie, a nie tylko przekierowanie na stronę Przelewy24. Dokumentacja operatora rozdziela sandbox od produkcji i opisuje osobne adresy API oraz panele. Środowisko testowe nie służy do realizowania prawdziwych płatności.

Przed publikacją wykonaj checklistę:

• Wyślij formularz i potwierdź, że powstał jeden rekord ze statusem oczekującym.
• Spróbuj zmienić kwotę w przeglądarce; serwer powinien wyliczyć ją z własnej konfiguracji.
• Porównaj kwotę, walutę i identyfikator sesji wysłane do P24 z danymi zgłoszenia.
• Wykonaj test udanej płatności i sprawdź podpis, wynik `transaction/verify` oraz status w bazie.
• Wróć ponownie na adres powrotu; samo wejście na tę stronę nie może zmienić statusu.
• Anuluj płatność i sprawdź możliwość ponowienia jej bez ponownego wysyłania formularza.
• Obsłuż ponowione powiadomienie; system nie może utworzyć drugiego zgłoszenia ani drugi raz rozpocząć realizacji.
• Sprawdź e-mail klienta, komunikat na stronie oraz logi bez sekretów API.

Zapisz identyfikator zgłoszenia i transakcji z każdego scenariusza. Po teście porównaj status w bazie z wynikiem w panelu sandbox. Przed uruchomieniem produkcyjnym przełącz razem adresy API i dane dostępowe na zestaw produkcyjny, a pierwsze transakcje sprawdź tym samym sposobem.

Najczęściej proces zawodzi, gdy system ufa powrotowi klienta, nie zapisuje powiązania zgłoszenia z transakcją lub nie waliduje autentyczności powiadomienia. Każdy z tych błędów może doprowadzić do płatności bez przypisanego zgłoszenia albo do przedwczesnego uruchomienia usługi.

• Kwota przyjęta z przeglądarki: klient zmienia ukryte pole. Serwer ma wyliczyć należność z własnych danych.
• Brak identyfikatora sesji w rekordzie: pracownik nie wie, do którego zgłoszenia przypisać transakcję. Zapisuj `sessionId` przed przekierowaniem.
• Powrót uznany za potwierdzenie: klient może wrócić po anulowaniu lub przed odebraniem wyniku. Strona powrotu ma odczytywać status z bazy.
• Brak sprawdzenia podpisu: system przetwarza komunikat bez walidacji jego autentyczności. Weryfikuj podpis według bieżącej specyfikacji P24.
• Brak weryfikacji transakcji: poprawny podpis nie zastępuje wywołania metody `transaction/verify`.
• Duplikat po ponowieniu: formularz lub powiadomienie uruchamia tę samą operację ponownie. Wprowadź idempotencję po identyfikatorze transakcji.
• Pomieszane środowiska: sandbox używa błędnych kluczy lub adresu produkcyjnego. Trzymaj konfiguracje osobno.
• Niedostępny endpoint: zapora, certyfikat HTTPS lub błędna ścieżka blokują powiadomienie. Zachowaj odpowiedź endpointu i odtwórz problem na środowisku testowym.

Prześledź jedną transakcję przez rekord formularza, `sessionId`, panel P24, powiadomienie, walidację podpisu, wynik weryfikacji i końcowy status. Przy rozbieżności zgromadź te dane przed kontaktem z dostawcą formularza lub Przelewy24.

Koszt zależy od tego, czy dodatek obsługuje wymagany formularz i pełny przepływ statusów, czy potrzebna jest logika dedykowana. Sama licencja nie przesądza, czy system zapisze zgłoszenie przed płatnością, zweryfikuje powiadomienie i obsłuży zwrot.

Integracja dedykowana jest zasadna, gdy kwota zależy od wielu warunków, zgłoszenie uruchamia proces w CRM lub systemie rezerwacji albo dodatek nie dokumentuje podpisu i weryfikacji. Gotowy dodatek wystarczy przy prostym formularzu, stałej opłacie i udokumentowanym przepływie serwerowym.

Jeśli potrzebujesz połączyć formularz z Przelewy24, integracja płatności na stronie może objąć zapis zgłoszenia, połączenie go z transakcją i testy scenariuszy. Zakres określamy po sprawdzeniu formularza, reguł kwoty i wymaganych statusów.

• Przelewy24 na stronie firmowej: jak przyjmować płatności
• Przelewy24 i PayPo w sklepie: dostępność, konfiguracja i koszty
• go.przelewy24.pl - co to za strona i jak bezpiecznie sprawdzić płatność
• Bezpieczeństwo płatności online w sklepie: kontrola przed startem