Jak skonfigurować bramki płatności w sklepie internetowym

Przygotuj krótką listę potrzeb: platforma, waluty, kraje sprzedaży, metody płatności i ewentualne odnowienia abonamentów. Nie musisz od razu włączać wszystkich dostępnych opcji. Każda dodatkowa metoda zwiększa zakres testów i późniejszej obsługi.

Właściciel firmy powinien kontrolować konto sprzedawcy i rachunek rozliczeniowy. Wykonawca otrzymuje dostęp potrzebny do swojej pracy, ale jego prywatne konto nie powinno zastępować konta sklepu.

Ustal też, kto kontaktuje się z operatorem, odbiera testy oraz wyjaśnia późniejsze rozbieżności. Jeżeli dopiero porównujesz możliwości, skorzystaj z porównania bramek dla sklepów. Wybór partnera i konfiguracja wybranego rozwiązania to dwa kolejne zadania.

Rejestrację oraz wymagane dokumenty obsługuj przez oficjalne kanały operatora. Zakres weryfikacji zależy od firmy, branży i usług. Nie zakładaj, że identyczna lista załączników albo jeden termin aktywacji obowiązuje wszystkich sprzedawców.

Przed pracą techniczną potwierdź, czy konto obejmuje właściwy sklep, walutę i metody. Dostęp do panelu nie musi oznaczać, że każda usługa jest już aktywna. Przykładowo płatności w sklepie, zapisane sposoby płacenia lub odnowienia mogą wymagać dodatkowych warunków.

Zapisz, kto ma uprawnienia do konta, jak odzyskać dostęp i kto zatwierdza zmiany rozliczeń. Dane uwierzytelniające przekazuj bezpiecznym kanałem do właściwego miejsca konfiguracji. Nie umieszczaj kluczy API w zwykłym briefie, publicznym zgłoszeniu ani zrzucie ekranu wysyłanym do wielu osób.

Jeżeli weryfikacja konta nadal trwa, oddziel zadania możliwe w sandboxie od uruchomienia produkcyjnego. Nie zapewniaj klientom dostępności metody wyłącznie dlatego, że jej nazwa pojawiła się już w panelu sklepu. Potwierdzenie operatora i test integracji pełnią inne role.

Dwie wtyczki łączące z tą samą bramką mogą mieć różnych producentów, ekrany i funkcje. W WooCommerce zapisz pełną nazwę modułu, wersję oraz rodzaj kasy. Zgodność zwykłego checkoutu nie dowodzi automatycznie obsługi Blocks lub niestandardowego szablonu.

Przykładowo P24 opisuje aktualną gałąź oficjalnego modułu dla WooCommerce 9.x-11.x. To informacja o konkretnym rozwiązaniu, a nie deklaracja dotycząca dowolnej wtyczki P24. Źródło: strona pobrania modułu Przelewy24. Szczegółowe kroki znajdziesz w instrukcji P24 i instrukcji PayU.

Przygotuj kopię plików, bazy i konfiguracji oraz plan wycofania zmiany. Sandbox oddziel od prawdziwych płatności, odnowień, wysyłek i wiadomości do klientów. Sama kopia sklepu może nadal zawierać produkcyjne klucze oraz aktywne automatyzacje.

Nie aktualizuj wszystkich składników jednocześnie tylko po to, aby spełnić ogólne zalecenie. Ustal wymagania konkretnego modułu i sprawdź zmiany w kontrolowanych warunkach. Gdy brakuje bezpiecznego środowiska lub dostępu do dokumentacji, najpierw usuń tę przeszkodę.

Dane połączenia i adresy ustalaj z instrukcji wybranej integracji. Nie kopiuj callbacku z poradnika innego modułu. Część rozwiązań generuje powrót automatycznie, a powiadomienia mają osobną konfigurację. Przykładowo oficjalna instrukcja paynow rozróżnia automatyczny adres powrotu i adres powiadomień ustawiany w panelu.

Powrót klienta, komunikat operatora i aktualizacja zamówienia to osobne etapy. PayU ujmuje to w dokumentacji: "Every notification is sent asynchronously." Oznacza to, że obsługa wpłaty musi działać również niezależnie od tego, czy kupujący wróci do sklepu. Źródło: cykl płatności PayU.

Sprawdzaj dane, które łączą te etapy: identyfikator, kwotę, walutę i stan. W API P24 kwoty są podawane w groszach, np. 1,23 PLN to 123. Dlatego odczyt logu wymaga znajomości jednostek; nie wolno porównywać samych liczb bez kontekstu. Źródło: dokumentacja transakcji P24.

Gotowy moduł obsługuje protokół. Ręczne oznaczenie zamówienia jako opłaconego nie jest sposobem na zaliczenie testu, który nie potwierdził poprawnej komunikacji.

Uzgodnij scenariusze przed testami. Dla każdego zapisz oczekiwany wynik w sklepie i u operatora oraz dowód pozwalający odnaleźć konkretną próbę. Korzystaj z dozwolonych mechanizmów sandbox, bez wysyłania zdarzeń do produkcyjnego konta.

Interpretuj stan operatora zgodnie z jego dokumentacją. PayU wyróżnia 4 stany: PENDING, WAITING_FOR_CONFIRMATION, COMPLETED i CANCELED. Nie wszystkie oznaczają zakończoną wpłatę i nie są to uniwersalne nazwy dla innych systemów.

Zwrot również wymaga rzeczywistego potwierdzenia. Zmiana statusu WooCommerce nie uruchamia automatycznie refundacji; opisuje to instrukcja zwrotów. Jeśli stan operacji pozostaje nieznany, odbiór tej części integracji pozostaje otwarty. Nie maskuj rozbieżności ręcznym poprawieniem panelu.

Do przełączenia potrzebne są właściwe konto, dane produkcyjne oraz potwierdzone metody. Sprawdź również adres domeny, wariant checkoutu i ustawienia, które różnią się od testowego środowiska. Ustal, kto podejmuje decyzję o uruchomieniu i jak sklep zostanie skontrolowany po zmianie.

Dokument przekazania powinien zawierać nazwę i wersję integracji, aktywne metody, wyniki testów, właścicieli dostępów oraz procedurę obsługi rozbieżności. Wystarczą odsyłacze do bezpiecznie przechowywanych danych; nie kopiuj do dokumentu sekretów.

Osoba obsługująca sklep musi wiedzieć, gdzie sprawdzić płatność, jak odróżnić oczekiwanie od realizacji oraz jak potwierdzić refundację. Opłacone zamówienie nie zawsze automatycznie staje się zakończone. Kontekst produktów i statusów wyjaśnia dokumentacja zamówień WooCommerce.

Przy zmianie operatora zachowaj możliwość wyjaśnienia wcześniejszych transakcji i zwrotów. Nowa integracja nie przejmuje automatycznie historii starego konta. Ustal też kontrolę po przyszłych aktualizacjach: zgodność wykazana dzisiaj dotyczy sprawdzonego zestawu wersji i konfiguracji, a nie wszystkich kolejnych zmian sklepu.

Wstrzymaj uruchomienie, jeśli nie zgadza się kwota, sklep błędnie rozpoznaje zapłatę, checkout nie obsługuje metody albo wynik zwrotu jest nieznany. Podobnie postąp przy ujawnionych kluczach lub braku izolacji testów. Zbierz konkretny objaw i wynik po obu stronach, zamiast zmieniać kilka ustawień naraz.

Przy działającym sklepie przywrócenie starej kopii musi uwzględniać nowsze zamówienia. Nie wolno utracić informacji o przyjętych płatnościach. Głębsze scenariusze opisuje diagnostyka problemów z bramkami.

Standardowa integracja płatności od 1499 zł netto dotyczy jednego PayU, P24 lub Tpay w istniejącym WooCommerce. Stripe, naprawa awarii, API i połączenia z dodatkowymi systemami wymagają osobnego zakresu. Nowy sklep internetowy to inne zadanie niż podłączenie płatności do już działającej platformy.

Aby rozpocząć rozmowę, napisz do nas i podaj adres lub platformę oraz cel albo problem. Wolumen, średni koszyk i opis dodatkowych integracji możesz dopisać, jeśli je znasz. Nie potrzebujesz kompletnej specyfikacji ani kluczy API w pierwszym zgłoszeniu.

• Przelewy24 na stronie firmowej: jak przyjmować płatności
• Płatność Przelewy24 w formularzu na stronie: jak ją wdrożyć