Skip to main content
Widget to jeden plik sdk.js, który dokłada do sklepu dwie rzeczy:
  • element <paymove-checkout> — przycisk płatności albo pasek informacyjny z sygnetem Paymove i logotypami metod, gotowy do wstawienia w koszyku lub na liście metod płatności,
  • modal z checkoutem — ten sam adres, który dziś otwierasz przekierowaniem, wyświetlony w iframie na stronie sklepu.
Widget nie tworzy płatności. Płatność powstaje po stronie serwera — przez SDK Node.js albo REST API — a widget dostaje gotowy redirectUrl z odpowiedzi.
Klucz API zostaje na serwerze. Widget przyjmuje wyłącznie redirectUrl, nigdy apiKey. Wywołanie API z przeglądarki i tak odrzuci CORS.

1. Podłączenie skryptu

Skrypt rejestruje element <paymove-checkout> i wystawia obiekt window.Paymove. Cały interfejs siedzi w Shadow DOM, więc style sklepu nie mieszają się ze stylami widgetu i odwrotnie. Przy async skrypt może dojechać po Twoim kodzie — poczekaj na ready():
Ścieżka /v1/ to alias wersjonujący - ten sam plik serwowany jest też pod /sdk.js. Używaj /v1/, dzięki czemu ewentualna przyszła wersja /v2/ nie zepsuje istniejących integracji.
Adres skryptu odpowiada środowisku checkoutu. Build sdk.js osadza w modalu wyłącznie własną domenę, więc skrypt z produkcji nie otworzy checkoutu sandboxowego i odwrotnie — pobieraj go z tej samej domeny, z której przychodzi redirectUrl.

2. Element <paymove-checkout>

Najkrótsza wersja to sam znacznik w HTML:
Element renderuje przycisk z sygnetem Paymove, a pod nim kartę z logotypami metod płatności. Konfigurujesz go atrybutami: Tekst po znaku · renderuje się pogrubiony, więc label="Zapłać · 149,00 zł" da „Zapłać · 149,00 zł”. Widoczne są trzy pierwsze logotypy, reszta zwija się do znacznika +N.
Sygnetu Paymove nie da się ukryć ani przemalować — do wyboru są dwie wersje: czarna i biała. Resztę wyglądu dostosujesz — patrz sekcja Wygląd.

3. Tryb readonly

mode="readonly" renderuje sam pasek: sygnet, Twój tekst i logotypy metod. Domyślnie jest nieinteraktywny — to element informacyjny, taki jak pozycja „Płatności online” na liście metod dostawy i płatności w koszyku.
Gdy pasek ma sam otwierać płatność, dodaj interactive i podepnij kontroler (sekcja niżej). Element emituje wtedy zdarzenie paymove:click, obsługuje Enter i spację, i wystawia poprawne role dla czytników ekranu.

Kafelki pojedynczych metod

Atrybut method zamienia pasek w kafelek jednej metody: logo, nazwa i opis z wbudowanego katalogu SDK — sklep nie utrzymuje własnych logotypów ani tekstów. Poniższe przykłady są żywe, renderuje je sdk.js załadowany na tej stronie:
Logo jest zawsze. Nazwę i opis możesz schować (hide-label, hide-description) albo nadpisać (label, description):
Kafelek domyślnie nie ma tła, ramki ani paddingu — wtapia się w wiersz Twojej listy metod, a wiersze, ramki i radiobuttony zostają po stronie sklepu. Zmiennymi CSS z sekcji Wygląd (--paymove-bg, --paymove-border-color, --paymove-padding, --paymove-radius) zrobisz z niego samodzielną kartę. Z atrybutem interactive kafelek jest klikalny i emituje paymove:click — przy schowanych tekstach nazwa metody zostaje w aria-label, więc czytniki ekranu widzą go poprawnie.

4. Otwarcie checkoutu w modalu

Modalem steruje kontroler z window.Paymove:
mount() przejmuje kliknięcia w element i sam przełącza przycisk w stan ładowania na czas pobierania adresu. Jeśli redirectUrl masz już w momencie renderowania strony, podaj go zamiast fetchCheckoutUrl:
fetchCheckoutUrl jest wygodniejsze: płatność powstaje dopiero w chwili kliknięcia, więc nie zostawiasz porzuconych płatności po klientach, którzy tylko oglądali koszyk.

Konfiguracja createCheckout

Konfiguracja przyjmuje też wszystkie pola wyglądu przycisku (label, methods, variant…), więc możesz opisać element wyłącznie w JavaScripcie i zamontować go w pustym <div>.
externalId w onSuccess i onComplete to details.orderId, jeśli przekazałeś je przy tworzeniu płatności - a 10-znakowy hash Paymove dopiero wtedy, gdy orderId nie ustawiłeś. Jeśli dopasowujesz zamówienie po tej wartości, ustawiaj details.orderId konsekwentnie, żeby zawsze dostawać ten sam identyfikator.

Kontroler

Gdy chcesz tylko otworzyć modal — bez własnego przycisku — użyj skrótu:

5. Przekierowanie zamiast modala

To ta sama konfiguracja z jednym polem więcej:
Klient trafia na checkout Paymove, a po płatności widzi ekran potwierdzenia z przyciskiem „Wróć do sklepu”, który przenosi go pod returnUrl przekazany przy tworzeniu płatności. Modal i przekierowanie różnią się wyłącznie tym polem, więc możesz przełączać się między nimi bez zmian w reszcie integracji.
W trybie modal returnUrl nie jest używany w ogóle - przycisk powrotu zamyka modal i wywołuje onComplete. Jeśli Twoja integracja opiera się na handlerze returnUrl, w modalu nigdy się on nie wykona. Źródłem prawdy pozostaje webhook.

6. Jak zachowuje się modal

  • Na desktopie to panel o szerokości 398 px, wyśrodkowany, na przyciemnionym tle. Wysokość dopasowuje się do treści checkoutu.
  • Przy szerokości okna do 640 px modal wysuwa się z dołu jak natywny arkusz: maksymalnie 90% wysokości okna, z belką do przeciągania — przeciągnięcie w dół zamyka płatność.
  • W trakcie ładowania widać statyczny sygnet Paymove. Krzyżyka wtedy nie ma — pojawia się dopiero, gdy checkout nie odezwie się przez 10 sekund, jako wyjście awaryjne.
  • Po załadowaniu zamykanie przejmuje nagłówek checkoutu. Zamknąć można też klawiszem Esc i kliknięciem w tło.
  • Strona pod modalem nie przewija się, a po zamknięciu wraca w to samo miejsce.
  • Na czas płatności checkout blokuje przewijanie tła i sam raportuje swoją wysokość, więc modal nie skacze przy zmianie kroku.
  • Modal potrafi zamknąć się sam po udanej płatności, ale sterujesz tym przy tworzeniu subproduktu, polem details.autoclose (w milisekundach), a nie z poziomu SDK. Checkout pokazuje wtedy odliczanie w przycisku „Wróć do sklepu” i po jego upływie zamyka modal, wywołując onComplete. Dowolna interakcja klienta anuluje odliczanie.
Część banków w Pay by Link i PayPo zabrania osadzania swoich stron w iframie. Checkout otwiera je wtedy w nowym oknie i po powrocie wraca do modala — nie wymaga to niczego po stronie sklepu, ale nie blokuj wyskakujących okien we własnym kodzie.

7. Wygląd

Kolory, promień i typografię przycisku ustawisz konfiguracją albo bezpośrednio zmiennymi CSS na elemencie:
Widget dziedziczy krój pisma ze strony sklepu, dopóki nie ustawisz --paymove-font-family.

8. React i Next.js

Po zmianie kwoty wystarczy checkout.current.update({ label: 'Zapłać · 199,00 zł' }) — element przerysuje się bez montowania od nowa.
W Reakcie montuj widget w pustym <div>, a nie w JSX-owym <paymove-checkout>. Element i tak trzyma treść w Shadow DOM, więc React nie ma czym zarządzać, a przy hydratacji unikasz ostrzeżeń o niezgodności drzewa.

9. Ograniczenia

  • sdk.js otwiera w modalu wyłącznie własną domenę checkoutu. Adres z innej domeny kończy się błędem INVALID_CHECKOUT_URL, zanim cokolwiek się pokaże.
  • Płatność zawsze tworzy Twój backend — widget nie zna klucza API i nie odpytuje API Paymove.
  • Zamówienie realizuj dopiero po zweryfikowanym webhooku. onSuccess to sygnał dla interfejsu, nie potwierdzenie księgowania.
  • Modal wymaga, żeby strona sklepu mogła osadzić checkout w iframie — checkout wysyła nagłówek Content-Security-Policy z frame-ancestors https:, więc sklep musi działać po HTTPS (poza localhost w developmencie).