Płatności zagraniczne w Hummerce to zbiór modułów lokalnych operatorów płatności - PayU Classic, TrustPay, Paysera, mobilPay, Payline i Ingenico (Barclaycard ePDQ) - dzięki którym sklep przyjmuje płatności popularne poza Polską, na przykład w Czechach, na Słowacji, Litwie, w Rumunii, Francji, Belgii i Holandii. Każdy moduł przekierowuje klienta na stronę operatora, a po płatności odbiera wynik i ustawia status płatności zamówienia.
Stan na: aktualizacja 2026-10-16.
- Lokalne metody płatności na rynku docelowym - klient płaci tak, jak przyzwyczaił się płacić w swoim kraju: przelewem przez własny bank, kartą albo przelewem natychmiastowym.
- Jedna logika płatności dla wszystkich rynków - moduły działają w tym samym mechanizmie co pozostałe płatności Hummerce: z przypisaniem do widoków, własnymi komunikatami, powtarzaniem i zmianą płatności. Opis mechanizmu jest na stronie Płatności - przegląd.
- Osobne warunki na każdym rynku - każdy rynek może mieć własną umowę z operatorem, własną płatność i własne widoki sklepu.
- Automatyczne statusy - po zakończeniu płatności moduł ustawia status płatności zamówienia (zapłacone, niezapłacone, częściowo zapłacone, anulowane), więc obsługa sklepu nie rozlicza wpłat ręcznie.
- Tryb testowy - każdy z modułów można uruchomić najpierw na środowisku testowym operatora (u operatorów, którzy je udostępniają).
| Operator |
Rynek |
Metody płatności |
Co robi integracja |
| PayU Classic |
Czechy, Słowacja, Litwa |
karta, przelewy bankowe (każdy bank jako osobna płatność), inne metody udostępniane przez PayU |
przekierowanie na stronę PayU, odbiór statusu, statusy płatności, tryb testowy |
| TrustPay |
Słowacja |
przelew bankowy, przelew wewnętrzny TrustPay, Paysafecard, karta |
przekierowanie, odbiór powiadomienia, statusy, kontrola kwoty |
| Paysera |
Litwa |
przelewy bankowe wybierane na stronie Paysera |
przekierowanie, odbiór powiadomienia, statusy, kontrola kwoty |
| mobilPay |
Rumunia |
karta |
przekierowanie na stronę operatora, odbiór potwierdzenia, statusy |
| Payline |
Francja |
płatność na stronie Payline |
przekierowanie, odbiór wyniku, statusy |
| Ingenico (Barclaycard ePDQ) |
Belgia, Holandia |
metody udostępnione przez konto operatora |
przekierowanie, podpisane żądanie i odpowiedź, statusy |
W każdym z modułów zwrot środków do klienta wykonuje się w panelu operatora - moduł nie zleca zwrotu z poziomu sklepu.
Każda integracja ma jeden zestaw danych dostępowych do operatora (konto, projekt lub punkt sprzedaży). Jeśli sklep sprzedaje na kilku rynkach albo w kilku walutach i chce rozliczać je osobno, zakładamy osobny punkt płatności u operatora i osobną płatność w sklepie, przypisaną do właściwych widoków. Waluta płatności wynika z waluty zamówienia.
- Starsza integracja PayU - klasyczne API, w którym klient wraca do sklepu po zakończeniu płatności na stronie PayU. Aktualna integracja REST jest opisana na stronie PayU.
- Każdy bank lub metoda płatności to osobna płatność w sklepie, przypisana w konfiguracji do metody PayU.
- Statusy płatności: przygotowana, zweryfikowana, zakończona, anulowana, odrzucona, w oczekiwaniu, błąd - z osobnym zestawem dla trybu testowego.
- W jednym sklepie działa jedno konto PayU; kolejny rynek wymaga osobnego punktu płatności i osobnej konfiguracji.
- Każda metoda TrustPay (przelew bankowy, przelew wewnętrzny, Paysafecard, karta) to osobna płatność w sklepie z ustawionym typem płatności TrustPay.
- Statusy z TrustPay są mapowane na statusy sklepu (zapłacone, niezapłacone); gdy kwota z potwierdzenia różni się od kwoty zamówienia, płatność dostaje status Częściowo zapłacone.
- Konfiguracja obejmuje kraje, języki i waluty, w których płatność jest dostępna, oraz opis płatności przekazywany do operatora.
- W sklepie jest jedna płatność Paysera; bank klient wybiera już po przekierowaniu, na stronie operatora.
- Statusy z Paysera są mapowane na statusy sklepu; gdy kwota z powiadomienia różni się od kwoty zamówienia, płatność dostaje status Częściowo zapłacone.
- Konfiguracja obejmuje domyślny język i kraj, listę dozwolonych krajów, komunikat płatności i tryb testowy.
- Operator weryfikuje projekt przed uruchomieniem płatności produkcyjnych.
- Obsługuje wyłącznie płatność kartą - sklep wysyła do operatora podpisane żądanie i odbiera potwierdzenie.
- Statusy z potwierdzenia dzielą się na zapłacone, anulowane i oczekujące; przypisanie wartości do grup jest ustawieniem modułu.
- Dane płatnika (imię, nazwisko, adres, e-mail, telefon) są przekazywane z zamówienia.
- Klient jest przekierowywany na stronę płatności Payline, a po zakończeniu sklep sprawdza wynik transakcji.
- Za płatność zakończoną sukcesem uznawane są kody wyniku wpisane w ustawieniu Statusy zapłacone.
- Konfiguracja obejmuje identyfikator sprzedawcy i klucz dostępu oraz tryb testowy.
- Klient jest przekierowywany na stronę płatności Ingenico, gdzie wybiera metodę i wprowadza dane płatności; żądanie i odpowiedź są podpisywane.
- Statusy płatności odzwierciedlają status operatora: autoryzowana, zapłacona, odrzucona, w trakcie przetwarzania, anulowana przez klienta, nieznana.
- Przy zamówieniu sklep zapisuje m.in. identyfikator transakcji, markę karty i kod błędu zwrócone przez operatora.
Moduły pochodzą ze starszych wersji platformy i działają od dawna - nie mają nowszych zmian odnotowanych w komunikatach o wersjach. Aktualne integracje PayU, Przelewy24 i PayPal na nowszym API są opisane na osobnych stronach.
- Umowa i dane dostępowe u każdego operatora - zakłada je sklep bezpośrednio z operatorem, osobno dla każdego rynku.
- Płatność założona na liście płatności sklepu i przypisana do właściwych widoków oraz sposobów dostawy (Sposoby dostawy - przegląd).
- Adresy powrotu i powiadomień operatora - podajemy je przy wdrożeniu.
- Wymaga wdrożenia - żaden moduł nie włącza się sam. Zakres: wpisanie danych dostępowych i wybór trybu testowego lub produkcyjnego (część ustawień w panelu, część w plikach konfiguracji sklepu), założenie płatności na liście płatności i przypisanie do widoków, ustawienie komunikatów, dopasowanie stron płatności w szablonie, testy na środowisku testowym operatora.
- Szablony Bootstrap 4 i Bootstrap 5 mają gotowe strony płatności dla PayU Classic, TrustPay, Paysera i Ingenico.
- Minimalny szacowany czas: od 20 h na jednego operatora, bez czasu oczekiwania na umowę i weryfikację po stronie operatora.
- Od czego zależy czas:
- liczba operatorów, rynków i walut (każdy rynek rozliczany osobno to osobny punkt płatności i osobna konfiguracja),
- liczba metod płatności u jednego operatora (np. każdy bank jako osobna płatność),
- dopasowanie wyglądu stron płatności i komunikatów w szablonie oraz liczba języków,
- czas uruchomienia konta lub projektu po stronie operatora,
- wersja sklepu - starsza wersja wymaga najpierw aktualizacji (wycena osobno).
- Każdy operator wymaga osobnej umowy i danych dostępowych, a część operatorów weryfikuje projekt przed uruchomieniem płatności produkcyjnych.
- Jeden zestaw danych dostępowych na moduł - kolejny rynek lub walutę rozliczaną osobno obsługuje osobny punkt płatności i osobna płatność w sklepie.
- Moduł nie wykonuje zwrotu środków - zwroty wykonuje się w panelu operatora.
- mobilPay obsługuje tylko płatność kartą.
- Moduły pochodzą ze starszych wersji platformy - przed uruchomieniem weryfikujemy z operatorem aktualność interfejsu i certyfikatów.
- Nie weryfikujemy zadania pod kątem zgodności z prawem (np. regulamin sklepu, informacje o płatnościach i ochrona danych na danym rynku).
- Zwrot środków do klienta z poziomu zamówienia w sklepie, bez przechodzenia do panelu operatora.
- Przeniesienie wybranych rynków na nowsze integracje operatorów, jeśli operator je udostępnia.
Czy Hummerce obsługuje płatności lokalne poza Polską?
Tak. Platforma ma moduły dla PayU Classic (Czechy, Słowacja, Litwa), TrustPay (Słowacja), Paysera (Litwa), mobilPay (Rumunia), Payline (Francja) i Ingenico (Belgia, Holandia).
Czy jedna płatność może obsłużyć kilka rynków albo walut?
Nie. Każdy moduł ma jeden zestaw danych dostępowych, więc każdy rynek rozliczany osobno ma własny punkt płatności u operatora i własną płatność w sklepie, przypisaną do swoich widoków.
Czy sklep zwraca pieniądze klientowi z poziomu zamówienia?
Nie. Zwrot środków wykonuje się w panelu operatora, a sklep otrzymuje tylko informację o statusie płatności.
Czy każdy operator ma tryb testowy?
Moduły mają przełącznik trybu testowego i produkcyjnego. Dostępność środowiska testowego zależy od operatora - weryfikujemy ją przy wdrożeniu.
Ile trwa uruchomienie płatności zagranicznej?
Od 20 h na jednego operatora, bez czasu oczekiwania na umowę i weryfikację po stronie operatora. Dokładny czas zależy od liczby rynków, metod i dopasowania szablonu.
Jakie ograniczenie klienci najczęściej przeoczają?
Każdy rynek rozliczany osobno wymaga własnej umowy i własnych danych dostępowych u operatora - nie wystarczy dodać kraj do istniejącej płatności.
Chcesz zobaczyć, jak płatności zagraniczne mogą działać w Waszym sklepie? Umów bezpłatną prezentację.
- Konfiguracja -> Płatności - założenie płatności dla danego operatora, przypisanie do widoków, powiązane dostawy, komunikaty płatności.
- Ustawienia modułów w panelu, w grupach: PayU, Paysera, Płatność MobilPay, Payline, Trust Pay. Ingenico konfiguruje wdrożeniowiec w plikach konfiguracji sklepu.
Moduły zapisują przy zamówieniu informacje o płatności, widoczne w szczegółach zamówienia:
| Operator |
Zapisywane dane |
| TrustPay |
status płatności, typ płatności, typ transakcji, identyfikator transakcji |
| Paysera |
typ płatności, status płatności, kod błędu |
| mobilPay |
kod i komunikat błędu |
| Ingenico |
akceptacja, identyfikator transakcji, marka karty, data transakcji, kod błędu, status płatności |