¶ InPost Pay - szybki zakup przez aplikację InPost
InPost Pay w Hummerce to szybki zakup przez aplikację InPost: klient klika przycisk InPost Pay w koszyku albo na karcie produktu, potwierdza zakup w aplikacji na telefonie - bez wypełniania formularza zamówienia - a zamówienie z danymi, dostawą i płatnością trafia do sklepu automatycznie. Integracja działa na aktualnej wersji przycisku InPost (Widget 2.0) i skraca ścieżkę zakupu, zwłaszcza na telefonie.
Stan na wersję Hummerce 2.34 (ostatnie zmiany w module: 2.35.61), aktualizacja 2026-10-07.
¶ Korzyści i zastosowania
- Zakup w kilka sekund, bez formularza - wyższa konwersja, zwłaszcza na telefonie i przy zakupach impulsowych.
- Zakup prosto z karty produktu - klient nie musi przechodzić przez koszyk.
- Dane adresowe i telefon z aplikacji InPost - mniej błędów w adresach i numerach paczkomatów.
- Rabaty, promocje i koszty dostawy liczone przez sklep - te same zasady co w zwykłym zamówieniu, bez osobnego cennika dla InPost.
- Status zamówienia i numer przesyłki widoczne dla klienta w aplikacji InPost - mniej pytań "gdzie jest moja paczka".
- Zamówienia InPost Pay obsługuje się na tej samej liście co pozostałe - z tymi samymi statusami i rezerwacjami magazynowymi.
- Możliwość wyłączenia przycisku dla produktów, których InPost nie dostarczy - klient nie trafia w ślepą uliczkę.
¶ Zasady działania
- Przycisk InPost Pay wyświetla się w dwóch miejscach:
- w koszyku - klient przenosi do aplikacji InPost cały koszyk,
- na karcie produktu - kliknięcie dodaje produkt do koszyka i od razu przenosi koszyk do aplikacji. Przy produkcie z wariantami klient musi najpierw wybrać wariant.
- Przycisk może być ukryty dla wybranych produktów (np. gabarytów, których InPost nie przewozi). W koszyku przycisk pojawia się tylko wtedy, gdy wszystkie produkty spełniają warunki.
- Po kliknięciu klient potwierdza powiązanie koszyka w aplikacji InPost. Od tej chwili koszyk w sklepie i w aplikacji jest synchronizowany:
- zmiana koszyka w sklepie (dodanie produktu, zmiana ilości) aktualizuje koszyk w aplikacji,
- zmiana ilości w aplikacji aktualizuje koszyk w sklepie,
- kod rabatowy wpisany w aplikacji jest sprawdzany i naliczany według zasad kuponów sklepu,
- usunięcie koszyka w aplikacji rozłącza go ze sklepem.
- Ceny, promocje i koszty dostawy liczy sklep - według tych samych zasad co przy zwykłym zamówieniu (cenniki dostaw, progi darmowej dostawy). Ilość w aplikacji jest ograniczona do ilości dostępnej w sklepie.
- Do aplikacji trafiają: nazwa, opis, zdjęcie, kod EAN, cena i ilość produktów oraz zgody sklepu (np. akceptacja regulaminu).
- Klient wybiera w aplikacji dostawę i płatność, akceptuje zgody i składa zamówienie. Sklep tworzy zamówienie od razu, a przeglądarka klienta przechodzi na stronę podziękowania.
- Dostawa - dwie możliwości:
- Paczkomat InPost - oferowany tylko wtedy, gdy wszystkie produkty w koszyku należą do grupy dostaw wskazanej w konfiguracji,
- Kurier InPost - oferowany, gdy sklep wyliczył dla koszyka koszt tej dostawy.
- Przewidywana data dostawy w aplikacji to dzień zamówienia plus liczba dni z ustawienia Opóźnienie w dostawie (domyślnie 3).
- Płatność odbywa się w aplikacji InPost. Dostępne metody zależą od umowy sklepu z InPost - np. BLIK, karta, Google Pay, Apple Pay, szybki przelew, płatność odroczona, za pobraniem. Sklep nie ogranicza tej listy.
¶ Jak zamówienie trafia do sklepu
- Zamówienie powstaje ze statusem Przetwarzanie wstępne, płatność Niezapłacona, dostawa Niewysłane - dalej obsługa jak przy każdym zamówieniu (Statusy zamówień).
- Zamówienie ma dostawę i płatność InPost Pay ustawione w konfiguracji modułu, dane klienta i adres z aplikacji, a przy dostawie do paczkomatu - wybrany paczkomat.
- Gdy w sklepie istnieje konto z tym samym adresem e-mail, zamówienie zostaje przypisane do tego konta. W przeciwnym razie powstaje zamówienie bez konta.
- Produkty są rezerwowane w magazynie tak jak przy zwykłym zamówieniu.
- Po złożeniu zamówienia koszyk klienta w sklepie i wpisane kupony są czyszczone.
- W zamówieniu zapisuje się rodzaj płatności wybranej w aplikacji (np. BLIK, karta), komentarz klienta i zaakceptowane zgody.
- Dane do faktury podane w aplikacji trafiają do zamówienia (od wersji 2.35.61). Przy zakupie na firmę zamówienie jest oznaczone jako firmowe i ma nazwę firmy oraz NIP (polski prefiks PL jest pomijany, zagraniczny zostaje przy numerze). Przy zakupie jako osoba prywatna zamówienie jest oznaczone jako prywatne, bez NIP. Imię, nazwisko i adres do faktury zastępują dane główne zamówienia - adres do faktury tylko wtedy, gdy jest kompletny (ulica, miasto, kod pocztowy); adres dostawy zostaje bez zmian.
- Strona podziękowania przekazuje do Google Analytics zdarzenia zakupu, płatności i dostawy.
¶ Przebieg zakupu
¶ Mapowanie statusów zamówienia i płatności
Statusy zamówienia i płatności są synchronizowane w obie strony.
Z aplikacji InPost do sklepu - płatność
| Stan płatności w InPost Pay | Status płatności w sklepie |
|---|---|
| nieopłacona - zamówienie utworzone, klient jeszcze nie płaci | Niezapłacona |
| rozpoczęta - klient zaczął płacić w aplikacji | Niezapłacona |
| w trakcie - płatność jest przetwarzana | Oczekująca |
| opłacona - płatność zakończona sukcesem | Zapłacona |
| odrzucona przez system płatności | Anulowana |
| anulowana | Anulowana |
| błąd płatności | Błąd |
| za pobraniem - klient zapłaci przy odbiorze | Niezapłacona |
Z aplikacji InPost do sklepu - zamówienie
| Stan zamówienia w InPost Pay | Status zamówienia w sklepie |
|---|---|
| odrzucone - klient zrezygnował w aplikacji przed zapłatą | Anulowane |
| zakończone | Zakończone |
Ze sklepu do aplikacji InPost
- Każda zmiana statusu zamówienia w sklepie jest wysyłana do aplikacji - klient widzi w niej nazwę statusu taką jak w sklepie.
- Wraz ze zmianą statusu sklep przekazuje numer przesyłki z zamówienia, jeśli jest już nadany.
- Anulowane w sklepie oznacza zamówienie w aplikacji jako odrzucone - nie można go już opłacić.
- Zakończone w sklepie oznacza zamówienie w aplikacji jako zakończone tylko wtedy, gdy nie zostało opłacone przez InPost Pay (np. za pobraniem). Przy zamówieniach opłaconych w aplikacji przekazywana jest tylko nazwa statusu.
¶ Wersja
- Od wersji 2.34 - obecna integracja (Widget 2.0) w koszyku i na karcie produktu. Wcześniejsza integracja (od wersji 2.32) opierała się na wygaszonym przycisku InPost i nie działa.
- Od wersji 2.35.61 - dane do faktury (firma, NIP) z aplikacji InPost są zapisywane w zamówieniu.
- Ostatnie zmiany w module: wersja 2.35.61.
¶ Zależności
- Umowa sklepu z InPost na usługę InPost Pay - zawiera ją sklep we własnym zakresie. Z panelu InPost Pay sklep przekazuje dane dostępowe dla środowiska testowego i produkcyjnego: Client ID, Client secret, POS ID i Merchant Client ID (to inna wartość niż Client ID).
- Dane dostępowe przekazuje się bezpiecznym kanałem, nie w treści zgłoszenia.
- Adres integracji sklepu, który przy uruchomieniu zgłaszamy w InPost - InPost łączy się pod ten adres po koszyk i zamówienia.
- Dostawy w sklepie: osobna dostawa dla paczkomatu i osobna dla kuriera InPost, z kosztami. Ta sama dostawa dla obu uniemożliwia rozróżnienie paczkomatu i kuriera w zamówieniu.
- Grupa dostaw dla produktów, które mieszczą się w paczkomacie - bez niej paczkomat nie jest oferowany w aplikacji.
- Płatność InPost Pay na liście płatności sklepu (Płatności).
- Regulamin sklepu i treść zgód pokazywanych w aplikacji - przygotowuje sklep.
- Kody rabatowe w aplikacji - działają z kuponami sklepu (Kupony).
- Zdjęcia i kody EAN produktów - trafiają do aplikacji, jeśli są uzupełnione.
- Raportowanie zakupu do Google Analytics - wymaga skonfigurowanego GA4.
- Wersja sklepu 2.34 lub nowsza.
¶ Wdrożenie
- Wymaga wdrożenia - moduł nie włącza się sam po aktualizacji. Zakres:
- włączenie modułu w konfiguracji sklepu i wpisanie danych dostępowych InPost (testowych i produkcyjnych),
- ustawienie dostaw paczkomat i kurier, płatności InPost Pay oraz grupy dostaw dla paczkomatu,
- konfiguracja zgód pokazywanych w aplikacji (regulamin, opcjonalnie inne zgody),
- ewentualne warunki ukrycia przycisku dla wybranych produktów,
- osadzenie przycisku w koszyku i na karcie produktu oraz dopasowanie jego położenia do wyglądu sklepu (telefon i komputer),
- zgłoszenie adresu integracji w InPost, testy w środowisku testowym InPost (powiązanie koszyka, zmiany ilości, kupon, paczkomat i kurier, płatność, anulowanie, numer przesyłki),
- przełączenie na środowisko produkcyjne, włączenie weryfikacji podpisu żądań InPost i zamówienie kontrolne.
- Minimalny szacowany czas:
- szablon BS5 - od 8 h,
- szablon BS4 - od 12 h.
- Czas konkretnego wdrożenia zależy od jego zakresu - wyceniamy go indywidualnie.
- Od czego zależy czas:
- szablon sklepu - w obu szablonach są gotowe elementy przycisku, ale trzeba je osadzić w koszyku i na karcie produktu; w BS4 wymaga to więcej dopasowań,
- stopień indywidualizacji koszyka i karty produktu (warianty, zestawy, konfiguratory),
- czy sklep od razu przekazuje komplet danych testowych i produkcyjnych - brak danych testowych wydłuża testy,
- czas odpowiedzi i akceptacji po stronie InPost,
- wersja sklepu - sklep na wersji starszej niż 2.34 wymaga najpierw aktualizacji (wycena osobno),
- dodatkowe wymagania, np. własne mapowanie dostaw lub dane do faktury (wycena osobno).
¶ Ograniczenia
- Tylko dwie dostawy: paczkomat InPost i kurier InPost. Nazwy dostaw w aplikacji są stałe ("Paczkomat InPost", "Kurier InPost"), bez opcji dodatkowych dostawy.
- Paczkomat jest oferowany tylko dla koszyka złożonego w całości z produktów jednej, wskazanej grupy dostaw.
- Przewidywana data dostawy to stała liczba dni od zamówienia - nie uwzględnia dostępności produktów, dni wolnych ani godzin wysyłki.
- Tylko złote (PLN). Zamówienie zapisuje się w walucie głównej sklepu, w domyślnym widoku i w domyślnym języku sklepu.
- Przycisk i komunikaty aplikacji są po polsku - bez przełączania języka według wersji językowej sklepu.
- Brak zakładania konta klienta - zamówienie przypisuje się do konta tylko wtedy, gdy konto z tym adresem e-mail już istnieje.
- Produkty powiązane proponowane w aplikacji InPost nie są obsługiwane.
- Powiązanie koszyka z aplikacją trwa tyle, co sesja klienta w sklepie. Po wygaśnięciu sesji (np. długa przerwa) koszyk trzeba powiązać ponownie.
- Na karcie produktu zakup dotyczy produktu dodanego do bieżącego koszyka - do aplikacji trafia cały koszyk, nie tylko oglądany produkt.
- Ilość w aplikacji jest przycinana do ilości dostępnej w sklepie - klient nie zamówi więcej, niż jest na stanie.
- Zwrot pieniędzy za zamówienie opłacone w aplikacji wykonuje się po stronie InPost - sklep go nie zleca.
- Zgody pokazywane w aplikacji ustawia się przy wdrożeniu - zmiana treści regulaminu lub zgód wymaga zmiany konfiguracji modułu.
- Metody płatności w aplikacji zależą od umowy z InPost - sklep nie wyłącza z poziomu panelu poszczególnych metod (np. płatności za pobraniem).
- Nie weryfikujemy konfiguracji pod kątem zgodności z prawem - regulamin, treść zgód i informacje o płatności ustala sklep.
¶ Potencjał rozwoju
- Obsługa produktów powiązanych proponowanych w aplikacji InPost.
- Przewidywana data dostawy według dostępności produktów i kalendarza wysyłek.
- Wersje językowe przycisku zgodne z językiem sklepu.
- Zarządzanie zgodami w panelu, bez zmiany konfiguracji modułu.
- Zakładanie konta klienta przy pierwszym zamówieniu z InPost Pay.
- Dodatkowe opcje dostawy (np. paczkomat w weekend, dostawa ekspresowa).
¶ Najczęstsze pytania
Czy klient musi mieć konto w sklepie, żeby kupić przez InPost Pay?
Nie. Zamówienie powstaje bez konta, chyba że w sklepie istnieje już konto z tym samym adresem e-mail - wtedy zamówienie zostaje do niego przypisane.
Czy InPost Pay obsługuje inne waluty niż złoty?
Nie. Zamówienie InPost Pay zapisuje się zawsze w walucie głównej sklepu (PLN), w domyślnym widoku i domyślnym języku.
Ile trwa wdrożenie InPost Pay?
Szablon BS5 - od 8 h, szablon BS4 - od 12 h. Czas rośnie ze stopniem indywidualizacji koszyka i karty produktu oraz brakiem kompletu danych testowych.
Czy mogę wyłączyć przycisk InPost Pay dla wybranych produktów?
Tak. Kryteria towarów w konfiguracji modułu decydują, dla których produktów przycisk się pokazuje - przydatne np. dla gabarytów, których InPost nie przewozi.
Czy klient wybiera dostawę i płatność w sklepie, czy w aplikacji InPost?
W aplikacji InPost - tam klient wybiera paczkomat albo kuriera oraz metodę płatności; dostępne metody zależą od umowy sklepu z InPost.
Czy zwrot pieniędzy za zamówienie z InPost Pay wykonuje sklep?
Nie. Zwrot dla zamówień opłaconych w aplikacji wykonuje się po stronie InPost.
¶ Powiązane
- Płatności - przegląd
- Sposoby dostawy - przegląd - dostawa paczkomatem i kurierem InPost również poza InPost Pay.
- PayPal - inna płatność online dostępna w standardzie Hummerce.
- Na hummerce.com: Platforma B2C, Integracja InPost Pay, Integracja InPost.
Chcesz zobaczyć, jak InPost Pay może działać w Waszym sklepie? Umów bezpłatną prezentację.
¶ Szczegóły konfiguracji
¶ Dostęp w panelu
- Konfiguracja w panelu: Konfiguracja -> Ustawienia, grupa InPostPay (poza przełącznikiem środowiska - ustawienia techniczne):
- Typ środowiska - TEST albo PROD; domyślnie TEST, przed uruchomieniem trzeba przełączyć,
- Client ID TEST, Client secret TEST, POS ID TEST, Merchant Client ID TEST, URL API TEST, URL Auth TEST - dane środowiska testowego,
- Client ID PROD, Client secret PROD, POS ID PROD, Merchant Client ID PROD, URL API PROD, URL Auth PROD - dane środowiska produkcyjnego,
- Domyślna płatność - płatność zapisywana w zamówieniach (domyślnie
inPostPay), - Domyślna dostawa kurierem, Domyślna dostawa paczkomatem - dostawy zapisywane w zamówieniach,
- Grupa dostaw dla dostawy paczkomatem - tylko koszyk złożony w całości z produktów tej grupy może być wysłany do paczkomatu,
- Opóźnienie w dostawie - liczba dni do przewidywanej daty dostawy (domyślnie 3),
- Kryteria towarów - warunek, które produkty mają przycisk InPost Pay (puste - wszystkie),
- Włącz walidację sygnatury - weryfikacja, że żądania pochodzą od InPost - włączana przy uruchomieniu produkcyjnym,
- Włącz szczegółowe logowanie - pełny zapis komunikacji z InPost do wyjaśniania problemów.
- Zgody pokazywane w aplikacji (treść, link, wersja, czy wymagana) - ustawiane przy wdrożeniu w konfiguracji modułu, nie w panelu.
- Lista zamówień: zamówienia InPost Pay na zwykłej liście zamówień, z kolumną "InPostPay ID zamówienia".
- Zamówienie: parametry "InPostPay ID zamówienia", "InPostPay ID koszyka", "InPostPay typ płatności", "InPostPay zgody" oraz "Numer kierunkowy" telefonu klienta i telefonu do dostawy.
¶ REST API i MCP
- Moduł nie ma własnych operacji REST API ani MCP - zamówienia InPost Pay są dostępne przez standardowe operacje na zamówieniach (REST API).
- Ustawienia modułu można odczytać i zmienić narzędziami
ec2_config_search,ec2_config_get,ec2_config_set(ustawienia techniczne wymagają dodatkowego potwierdzenia).
¶ Komunikaty sklepu
Komunikaty przy przycisku zmienia się w edytorze komunikatów. Wartości domyślne są po polsku i po angielsku.
¶ Przycisk InPost Pay w koszyku i na karcie produktu
| Klucz | Wartość domyślna |
|---|---|
msg.inPostPay.basketConnected |
Koszyk powiązany |
msg.inPostPay.basketFinalized |
Realizacja zamówienia w aplikacji inPostPay przebiegła pomyślnie |
msg.inPostPay.variantRequired |
Wybierz wariant produktu przed dodaniem do koszyka |
¶ Parametry
Parametry zamówienia zmienia się w parametrach i lokacjach.
| Symbol | Obiekt | Etykieta |
|---|---|---|
_inPostPayOrderUUID |
zamówienie | InPostPay ID zamówienia |
_inPostPayBasketUUID |
zamówienie, koszyk zamówienia | InPostPay ID koszyka |
_inPostPayOrderPaymentType |
zamówienie | InPostPay typ płatności |
_inPostPayOrderConsents |
zamówienie | InPostPay zgody |
_phone_country_prefix |
zamówienie | Numer kierunkowy (telefon klienta) |
_delivery_phone_country_prefix |
zamówienie | Numer kierunkowy (telefon do dostawy) |
Moduł korzysta też z parametrów standardowych: grupa dostaw produktu (_deliveryGroup), EAN (_ean), zdjęcia produktu, paczkomat (_inPostBoxMachineName), komentarz (_comment), e-mail do dostawy (_delivery_email) i numer przesyłki (_waybill).