Płatność BLIK wpływa nie tylko na checkout, lecz także na status zamówienia, rezerwację towaru i rozliczenie zwrotu. Wybór sposobu integracji warto oprzeć na tym, czy gotowy moduł obsłuży cały proces sprzedaży.
Krótka odpowiedź
Najpierw sprawdź, czy operator udostępnia moduł zgodny z platformą sklepu i potrzebnym wariantem BLIK. Własne API wybierz, gdy moduł nie obsługuje checkoutu, synchronizacji z ERP lub wymaganych reguł statusów.
Zamówienie oznacz jako opłacone po zweryfikowaniu wyniku po stronie serwera, a nie na podstawie samego powrotu klienta do sklepu.
Usługi KC Mobile
Potrzebujesz pomocy w tym temacie?
Czytasz poradnik „BLIK i integracja API: jak uruchomić płatność w sklepie”. Napisz, co chcesz zrobić i na jakim etapie jesteś. Ustalimy, czy możemy pomóc i jaki zakres prac będzie potrzebny.
Jakie są sposoby dodania BLIK do sklepu?
BLIK można dodać przez gotową wtyczkę operatora, moduł platformy albo własną integrację API. Każda opcja różni się zakresem kontroli nad procesem i odpowiedzialnością za późniejsze utrzymanie.
| Sposób integracji | Czas wdrożenia | Kontrola nad procesem | Utrzymanie i zwroty |
|---|---|---|---|
| Wtyczka operatora | Zwykle krótki, jeśli platforma jest obsługiwana | Ograniczona do ustawień modułu | Zależne od dostawcy i wersji wtyczki |
| Moduł platformy | Zależny od konfiguracji sklepu | Ograniczona do funkcji modułu | Wymaga kontroli zgodności z platformą |
| Własne API | Zależny od zakresu implementacji i testów | Można dopasować do procesu sklepu | Zespół utrzymuje komunikację i obsługę błędów |
Jeśli porównujesz płatności w kontekście całego checkoutu, zobacz zestawienie płatności online w sklepie. Sklepy WooCommerce mogą też sprawdzić uruchomienie BLIK w WooCommerce i konfigurację BLIK krok po kroku.
Przed instalacją modułu sprawdź obsługiwaną wersję platformy, wariant BLIK oraz sposób mapowania statusów. Dokumentacja PayU opisuje między innymi przekierowanie na stronę płatności BLIK i wariant z kodem autoryzacyjnym, a dostępność zależy od sposobu integracji. Własne API wymaga odrębnej obsługi uwierzytelniania, utworzenia płatności, powiadomień i zwrotów.
Czytasz poradnik „BLIK i integracja API: jak uruchomić płatność w sklepie”. Napisz, co chcesz zrobić i na jakim etapie jesteś. Ustalimy, czy możemy pomóc i jaki zakres prac będzie potrzebny. Omów temat tego poradnika
Kiedy potrzebna jest własna integracja API?
Własne API jest potrzebne, gdy gotowy moduł nie obsługuje procesu zamówienia albo wymaganej wymiany danych z innym systemem. Przykładem jest niestandardowy checkout, synchronizacja z ERP lub własna reguła rezerwowania stanów magazynowych.
Najpierw ustal źródło ograniczenia. Brak pola w checkoutcie może wynikać z konfiguracji platformy, a nie API płatności; błędny status może wynikać z mapowania zamówień lub niedziałających powiadomień. Własny kod nie rozwiąże problemu, jeśli ograniczenie dotyczy konfiguracji lub umowy z operatorem.
Gotowy moduł może wystarczyć, jeśli tworzy płatność, przekazuje wynik do sklepu i umożliwia obsługę zwrotu. Własne API wymaga dodatkowego zaprojektowania timeoutów, ponowień, odrzuceń i zmian statusów. Sklep nie powinien przechowywać kodu BLIK klienta ani zapisywać go w logach.
Gdy moduł nie obsługuje wymaganego przepływu, integracja płatności w sklepie może objąć dopasowanie procesu do checkoutu i statusów zamówień. Zakres ustalamy po analizie platformy, dokumentacji API oraz synchronizacji zamówień.

Jak przebiega płatność BLIK od koszyka do potwierdzenia?
Płatność BLIK zaczyna się od utworzenia transakcji u operatora, a kończy aktualizacją zamówienia po wiarygodnym wyniku. Sklep przekazuje przez API dane wymagane przez operatora, takie jak identyfikator zamówienia, kwota, waluta i adres powiadomień.
W zależności od integracji klient może przejść na stronę operatora albo użyć innego dostępnego wariantu płatności. Dokumentacja PayU opisuje przekierowanie do strony płatności BLIK oraz wariant z kodem autoryzacyjnym. Nie należy przenosić parametrów ani adresów API jednego operatora do integracji innego dostawcy.
Powrót przeglądarki informuje sklep, że klient wrócił, ale sam nie potwierdza zapłaty. Klient może zamknąć okno lub utracić połączenie po autoryzacji. Sklep powinien odebrać powiadomienie serwerowe albo sprawdzić status przez API, a następnie porównać identyfikator, kwotę i walutę z zamówieniem.
Perspektywa KC Mobile: w integracjach płatniczych rozdzielamy komunikat dla klienta od źródła statusu. Strona powrotu powinna wyjaśniać, co klient może zrobić dalej, a realizację zamówienia powinien uruchamiać zweryfikowany wynik serwerowy.

Jak bezpiecznie obsłużyć statusy i powiadomienia?
Powiadomienia operatora należy weryfikować zgodnie z dokumentacją konkretnego API. W PayU asynchroniczne powiadomienia są wysyłane metodą POST, a podpis w nagłówku `OpenPayu-Signature` trzeba zweryfikować przy każdym komunikacie; PayU wymaga odpowiedzi HTTP 200.
Przed zmianą zamówienia sprawdź, czy identyfikator transakcji łączy się z właściwym zamówieniem oraz czy zgadzają się kwota i waluta. Zapisuj obsłużone zdarzenia, aby powtórzone powiadomienie nie uruchomiło drugi raz wysyłki, rezerwacji ani wystawienia dokumentu. Dla PayU po odebraniu statusu `COMPLETED` dokumentacja zaleca ignorowanie dalszych powiadomień.
| Stan płatności | Stan zamówienia | Reakcja sklepu |
|---|---|---|
| Rozpoczęta | Oczekuje na wynik | Nie uruchamiaj realizacji |
| Oczekująca | Oczekuje na wynik | Sprawdź wynik u operatora |
| Opłacona | Gotowe do realizacji | Uruchom realizację jeden raz |
| Odrzucona | Nieopłacone | Udostępnij nową próbę |
| Anulowana | Anulowane lub nieopłacone | Zachowaj próbę w historii |
| Zwrócona | Zwrócone | Zapisz zwrot odrębnie |
Nazwy statusów i oczekiwana odpowiedź różnią się między operatorami, dlatego mapowanie trzeba oprzeć na aktualnej dokumentacji i testach. Logi mogą zawierać identyfikatory, czas, status i wynik walidacji, ale nie kod BLIK ani sekrety API.
Jak obsłużyć anulowanie, błąd i ponowienie płatności?
Ponowienie płatności powinno tworzyć kolejną próbę powiązaną z zamówieniem i zachowywać historię poprzedniej. Jeśli pierwsza transakcja nadal oczekuje na wynik, najpierw sprawdź jej status u operatora, ponieważ równoległa próba może doprowadzić do dwóch skutecznych płatności.
| Zdarzenie | Co sprawdzić | Działanie sklepu |
|---|---|---|
| Przerwana płatność | Aktualny status u operatora | Poczekaj na wynik lub potwierdzone anulowanie |
| Timeout przy tworzeniu | Czy operator utworzył transakcję | Sprawdź status przed ponowieniem żądania |
| Odrzucenie | Końcowy status i kod błędu | Pozostaw zamówienie nieopłacone |
| Brak powrotu klienta | Powiadomienie lub status przez API | Zaktualizuj zamówienie po weryfikacji |
| Powtórzone powiadomienie | Czy zdarzenie zostało już obsłużone | Potwierdź odbiór bez ponownej realizacji |
| Zwrot | Status operacji zwrotu | Zapisz wynik obok pierwotnej transakcji |
Komunikat dla klienta powinien odróżniać płatność oczekującą, nieudaną i zakończoną. Po powrocie klienta sklep powinien wyświetlić status zapisany przy zamówieniu, a nie wnioskować o zapłacie z adresu strony końcowej.
Jak wybrać operatora i oszacować nakład wdrożenia?
Operatora dobieraj do procesu sklepu, dokumentacji API, dostępności testów i sposobu obsługi zwrotów. Sama obecność BLIK w formularzu płatności nie potwierdza, że zamówienia i zwroty będą obsługiwane zgodnie z procesem sklepu.
| Kryterium | Co sprawdzić | Znaczenie dla wdrożenia |
|---|---|---|
| Moduł platformy | Obsługiwane wersje, checkout i wariant BLIK | Określa zakres własnego kodu |
| API | Środowisko testowe, uwierzytelnianie i wersjonowanie | Określa sposób implementacji |
| Powiadomienia | Podpis, statusy, ponowienia i kod odpowiedzi | Wpływa na aktualizację zamówień |
| Zwroty | Obsługa w panelu lub przez API | Określa zakres procesu posprzedażowego |
| Wsparcie | Kanał zgłoszeń i wymagane dane | Ułatwia diagnozę incydentów |
Nakład prac rośnie przy niestandardowym checkoutcie, wielu walutach, wielu źródłach zamówień albo własnych regułach rezerwacji. Przed wyceną ustal, kto monitoruje błędy, wykonuje zwroty i utrzymuje integrację po aktualizacji sklepu. Jeśli płatność ma wymieniać dane z systemem zamówień, wdrożenie integracji płatności pozwala zaplanować także kontrolę statusów i testy całego przepływu.
Jak przetestować BLIK i znaleźć przyczynę rozbieżności?
Testuj równolegle wynik u operatora i status zamówienia w sklepie. PayU udostępnia sandbox BLIK i testowe kody autoryzacyjne do symulowania wybranych scenariuszy, które należy stosować wyłącznie w testowym punkcie płatności.
| Test | Kontrola u operatora | Oczekiwany wynik w sklepie |
|---|---|---|
| Udana autoryzacja | Końcowy status sukcesu | Zamówienie opłacone jeden raz |
| Odrzucenie | Status lub błąd odmowy | Zamówienie pozostaje nieopłacone |
| Timeout po utworzeniu | Czy transakcja istnieje | Sklep sprawdza status przed ponowieniem |
| Przerwany powrót | Status płatności po stronie operatora | Brak powrotu nie zmienia statusu |
| Powtórne powiadomienie | Ponowne dostarczenie tego samego zdarzenia | Realizacja nie uruchamia się ponownie |
| Inna kwota lub waluta | Dane transakcji i zamówienia | Sklep nie oznacza zamówienia jako opłacone |
| Zwrot | Wynik operacji zwrotu | Zwrot jest widoczny odrębnie |
Jeśli operator pokazuje zakończoną płatność, a zamówienie nadal czeka, porównaj identyfikator transakcji, kwotę i walutę. Następnie sprawdź log endpointu powiadomień, walidację podpisu, odpowiedź HTTP i historię zamówienia. Wykonawcy przekaż zanonimizowane identyfikatory, znaczniki czasu, statusy i kody HTTP bez kodu BLIK i sekretów API.
Dodatkowe scenariusze opisuje porównanie rozwiązań BLIK dla sklepów.
Więcej poradników w tym temacie
Wspomniane narzędzia
Najczęściej zadawane pytania
Jak zintegrować BLIK ze sklepem internetowym przez API?
Czy do obsługi BLIK potrzebna jest własna integracja API?
Co zrobić, gdy klient zapłacił BLIK, a zamówienie jest nieopłacone?
Jak przetestować płatność BLIK przed uruchomieniem?
Czy sklep powinien przechowywać kod BLIK?
Potrzebujesz pomocy w tym temacie?
Czytasz poradnik „BLIK i integracja API: jak uruchomić płatność w sklepie”. Napisz, co chcesz zrobić i na jakim etapie jesteś. Ustalimy, czy możemy pomóc i jaki zakres prac będzie potrzebny.
