Przed uruchomieniem nowego sklepu przejdź testowe zamówienie od koszyka do potwierdzenia i sprawdź, czy płatność, dostawa, faktura, maile oraz status w panelu zgadzają się ze sobą. Sklep jest gotowy do publikacji dopiero wtedy, gdy klient może zapłacić bez zgadywania, a obsługa widzi komplet danych potrzebnych do realizacji zamówienia.
Nie wystarczy informacja, że "płatności są podłączone", a kurier pojawia się w checkoutcie. Trzeba zobaczyć, co dzieje się przy płatności udanej, anulowanej, błędnej i oczekującej, czy koszt dostawy jest policzony poprawnie, czy punkt odbioru zapisuje się w zamówieniu, czy powstaje faktura i czy klient dostaje właściwy mail. Jeśli statusy, etykiety, faktury i wiadomości zależą od przepływu danych między sklepem, operatorem płatności, kurierem i systemem fakturowym, potraktuj integracje sklepu internetowego jako osobny punkt odbioru.
Przy tworzeniu sklepów internetowych najbezpieczniej przygotować 3-5 scenariuszy testowych. Nie trzeba klikać każdej możliwej kombinacji, ale trzeba przejść te ścieżki, których klient i obsługa będą używać od pierwszego dnia. To powinien być zapisany test odbiorowy, a nie ustne zapewnienie, że "wszystko działa".
Jak przetestować płatności i dostawy w 30 sekund
Minimalny test przed startem sklepu obejmuje zamówienie opłacone, płatność anulowaną lub błędną, dostawę kurierską, dostawę do punktu lub automatu, fakturę oraz mail potwierdzający. Każdy test porównuj w trzech miejscach: na ekranie klienta, w panelu sklepu i w wiadomościach wysyłanych po zmianie statusu.
| Scenariusz | Co widzi klient | Co widzi obsługa | Decyzja |
|---|---|---|---|
| Zamówienie opłacone | Potwierdzenie, numer zamówienia i jasny komunikat o płatności | Zamówienie ma status opłacone albo gotowe do obsługi | Można przejść dalej, jeśli dane są spójne |
| Płatność anulowana lub błędna | Informację, że płatność nie została zakończona i co zrobić dalej | Status odróżnia błąd od sukcesu | Wstrzymaj start, jeśli zamówienie wygląda jak opłacone |
| Dostawa kurierska | Koszt, metoda, adres i termin lub warunki dostawy | Dane do wysyłki są kompletne | Wstrzymaj start, jeśli koszt lub adres są błędne |
| Punkt odbioru albo automat | Wybrany punkt jest widoczny w podsumowaniu | Punkt trafia do zamówienia i etykiety | Wstrzymaj start, jeśli punkt znika po zakupie |
| Faktura | Klient może podać dane firmowe i wie, gdzie dostanie dokument | Dane do faktury są widoczne lub przekazane do właściwego systemu | Wstrzymaj start, jeśli obsługa musi odtwarzać dane ręcznie |
| Mail potwierdzający | Wiadomość zawiera numer, produkty, kwotę, płatność i dostawę | Treść maila odpowiada statusowi w panelu | Wstrzymaj start, jeśli mail myli statusy |
Werdykt w 30 sekund: możesz publikować sklep, jeśli pełne zamówienie testowe zapisuje się w panelu, płatność ustawia właściwy status, dostawa ma komplet danych, faktura nie wymaga zgadywania, a maile nie wysyłają sprzecznych informacji. Jeśli którykolwiek z tych elementów nie działa, nie podpisuj odbioru jako zakończonego.
Czerwona flaga: wykonawca pokazuje katalog, koszyk i ekran płatności, ale nie przechodzi z Tobą powrotu z bramki, błędu płatności, punktu odbioru, faktury, maila i widoku zamówienia w panelu. To nie jest test sprzedaży, tylko prezentacja frontu.
Zamówienie testowe od koszyka do potwierdzenia
Zamówienie testowe zacznij od produktu, który ma realny wariant: rozmiar, kolor, pojemność, pakiet, konfigurację albo inny wybór wpływający na realizację. Przy prostym produkcie łatwiej przeoczyć błędy, które później wychodzą w koszyku, mailu, fakturze lub panelu zamówienia.
Najpierw dodaj produkt do koszyka i sprawdź, czy koszyk pokazuje właściwą nazwę, wariant, ilość, cenę, rabat, koszt dostawy i pełną sumę. Jeśli ten etap wymaga osobnego rozpisania, potraktuj koszyk sklepu internetowego jako samodzielny test, bo to tam najczęściej wychodzą problemy z wariantem, rabatem, dostawą i podsumowaniem. Jeśli sklep ma kod rabatowy, użyj jednego poprawnego i jednego błędnego kodu. Poprawny powinien zmienić sumę w przewidywalny sposób. Błędny powinien wyjaśnić problem, a nie cicho zniknąć.
Potem przejdź checkout jak zwykły klient. Wpisz realnie wyglądające dane testowe: imię i nazwisko, e-mail, telefon, adres, kod pocztowy, komentarz do zamówienia, jeśli pole istnieje, oraz dane do faktury, jeśli sklep je obsługuje. Nie używaj samych przypadkowych znaków, bo wtedy nie sprawdzisz, czy formularz dobrze waliduje telefon, e-mail, NIP albo adres.
| Krok | Co sprawdzić | Co oznacza problem |
|---|---|---|
| Koszyk | Produkt, wariant, ilość, rabat, dostawa i suma są zgodne | Klient może kupić coś innego niż wybrał |
| Dane klienta | Formularz zbiera potrzebne dane i nie kasuje ich po błędzie | Błąd jednego pola może zniechęcić do zakupu |
| Dane do faktury | NIP, nazwa firmy, nabywca i adres trafiają do zamówienia | Dokument trzeba będzie poprawiać ręcznie |
| Dostawa | Koszt, metoda i punkt odbioru są widoczne przed finalizacją | Klient poznaje warunki za późno |
| Płatność | Metoda jest jasna, a powrót z bramki działa | Klient nie wie, czy zapłacił |
| Potwierdzenie | Jest numer zamówienia, kwota, dostawa i dalszy krok | Klient nie ma dowodu zakończenia procesu |
Na stronie potwierdzenia sprawdź numer zamówienia, kwotę, walutę, produkty, warianty, dane dostawy, metodę płatności i informację o dalszym kroku. Potem od razu przejdź do panelu sklepu. Zamówienie testowe ma tam wyglądać tak samo jak po stronie klienta.
Decyzja praktyczna: jedno zamówienie testowe jest minimum. Jeśli sklep ma kilka metod płatności, pobranie, przelew tradycyjny, produkty wariantowe, faktury, punkty odbioru albo darmową dostawę, przygotuj osobne scenariusze dla najważniejszych ścieżek.
Płatności: sukces, anulowanie, błąd i oczekiwanie
Płatność testuj w trybie testowym albo sandboxie, jeśli wybrany operator i platforma sklepu to umożliwiają. Po teście sprawdź też, czy przed publikacją sklep ma zostać przełączony na właściwe środowisko produkcyjne. Nie chodzi o kopiowanie instrukcji jednej bramki płatniczej. Chodzi o sprawdzenie, czy sklep poprawnie reaguje na różne wyniki transakcji i czy status zamówienia nie zostaje domysłem obsługi.
Udana płatność to tylko pierwszy scenariusz. Równie ważna jest płatność anulowana, odrzucona, przerwana, oczekująca, przelew tradycyjny, pobranie oraz zwrot, jeśli sklep ma ten proces obsługiwać od startu. Nazwy statusów zależą od platformy, ale logika powinna być czytelna: opłacone nie może wyglądać jak oczekujące, a anulowane nie może wyglądać jak gotowe do wysyłki.
| Wynik płatności | Co powinien pokazać sklep | Co sprawdzić w panelu |
|---|---|---|
| Sukces | Potwierdzenie zamówienia i płatności | Status pozwala rozpocząć realizację |
| Anulowanie | Informację, że płatność nie została zakończona | Zamówienie nie jest oznaczone jako opłacone |
| Błąd lub odrzucenie | Możliwość ponowienia albo wyboru innej metody | Status odróżnia błąd od sukcesu |
| Oczekiwanie | Komunikat, że płatność jest w toku | Obsługa wie, że nie należy wysyłać jak po sukcesie |
| Przelew tradycyjny | Dane lub instrukcję dalszej płatności | Status pasuje do ręcznej obsługi wpłaty |
| Pobranie | Warunki płatności przy odbiorze | Zamówienie może przejść do realizacji bez płatności online |
| Zwrot | Informację zgodną z procesem sklepu | Status i dokumenty nie rozjeżdżają się z płatnością |
Najczęstszy problem techniczny nie jest widoczny na ekranie klienta. Klient wraca z bramki na poprawną stronę, ale sklep nie dostaje powiadomienia zwrotnego albo nie potrafi go przetworzyć. W zależności od operatora i platformy problem może dotyczyć webhooka, IPN, callbacku, adresu powrotu, błędnych kluczy API, SSL, cache checkoutu albo blokady po stronie serwera. Jeśli nie wiesz, który mechanizm stosuje dana bramka, wpisz to jako pytanie do wykonawcy, a nie jako założenie.
Sprawdź więc nie tylko to, czy płatność "przeszła". Sprawdź, czy po powrocie z bramki status zmienił się automatycznie, czy mail pasuje do statusu, czy panel pokazuje identyfikator transakcji, a anulowanie nie tworzy fałszywego zamówienia gotowego do realizacji.
Czerwona flaga: sklep po płatności udanej i anulowanej wysyła taki sam mail albo nadaje taki sam status. To blokuje start, bo obsługa może wysłać zamówienie bez płatności albo zatrzymać zamówienie, które klient opłacił.
Dostawy: koszt, punkt odbioru, etykieta i tracking
Dostawa w teście nie kończy się na tym, że metoda pojawia się w checkoutcie. Trzeba sprawdzić koszt, ograniczenia, zapis danych, etykietę, numer nadania i status wysyłki. Klient musi wiedzieć, ile zapłaci i gdzie trafi paczka. Obsługa musi wiedzieć, jak ją nadać.
Zacznij od koszyka. Jeśli sklep pokazuje próg darmowej dostawy, sprawdź zamówienie poniżej i powyżej progu. Jeśli koszt zależy od gabarytu, wagi, kraju, magazynu albo kategorii produktu, użyj produktu, który uruchamia tę regułę. Jeżeli koszt dostawy pojawia się dopiero po adresie, komunikat powinien to jasno wyjaśniać.
| Obszar dostawy | Co sprawdzić | Decyzja |
|---|---|---|
| Koszt | Czy suma w koszyku i checkoutcie jest spójna | Wstrzymaj start, jeśli koszt zmienia się bez wyjaśnienia |
| Darmowa dostawa | Czy próg działa poniżej i powyżej wartości granicznej | Popraw, jeśli obietnica znika przy finalizacji |
| Kurier | Czy adres trafia do zamówienia i etykiety | Wstrzymaj, jeśli dane trzeba przepisywać ręcznie mimo integracji |
| Punkt odbioru | Czy punkt zapisuje się w panelu, mailu i etykiecie | Wstrzymaj, jeśli po zakupie nie wiadomo, gdzie wysłać paczkę |
| Gabaryt lub kraj | Czy niemożliwe metody są ukryte albo wyjaśnione | Wstrzymaj, jeśli klient może wybrać nierealną dostawę |
| Tracking | Czy numer nadania wraca do zamówienia i komunikacji | Popraw, jeśli klient dostaje pustą informację o wysyłce |
Osobno przetestuj sytuację, w której nie ma dostępnej metody dostawy. Może chodzić o błędny kod pocztowy, kraj poza zasięgiem, produkt o nietypowym gabarycie albo koszyk łączący produkty z różnymi zasadami wysyłki. Komunikat powinien powiedzieć, co blokuje wybór, a nie kończyć się ogólnym "spróbuj ponownie".
Jeśli sklep ma generować etykiety z panelu, sprawdź, czy etykieta powstaje z danych zamówienia, czy zawiera właściwą metodę dostawy, gabaryt, adres nadawcy i odbiorcy oraz wybrany punkt. Jeśli etykiety mają być generowane poza sklepem, wpisz to do protokołu razem z osobą odpowiedzialną za ręczne nadanie. To nie musi blokować startu, ale musi być świadomą decyzją, a nie niedopowiedzianą półautomatyzacją.
Praktyczny wniosek: dostawa blokuje start wtedy, gdy klient może wybrać metodę, której sklep nie potrafi zrealizować, albo gdy obsługa po zakupie nie ma kompletnych danych do nadania paczki.
Faktury, maile i panel zamówienia
Po zakupie sklep musi być obsługiwalny. Publiczna ścieżka może wyglądać poprawnie, ale jeśli panel nie pokazuje danych do faktury, metody płatności, punktu odbioru albo historii statusów, pierwsze zamówienia szybko zamienią się w ręczne wyjaśnianie.
Test faktury zacznij w checkoutcie. Sprawdź, czy klient może zaznaczyć potrzebę faktury, podać NIP, nazwę firmy, adres nabywcy i ewentualnie inny adres odbiorcy. Potem zobacz, gdzie te dane trafiają: do panelu sklepu, systemu fakturowego, ERP, księgowości albo innego narzędzia. Artykuł nie przesądza, gdzie dokument ma powstawać. Ważne, żeby nie powstawał "gdzieś", bez właściciela procesu.
| Element po zakupie | Co powinno być zgodne | Co blokuje odbiór |
|---|---|---|
| Panel zamówienia | Produkty, warianty, kwota, rabat, dostawa, płatność i status | Obsługa musi zgadywać, co klient kupił |
| Dane klienta | E-mail, telefon, adres dostawy i dane firmowe | Nie da się wysłać paczki lub wystawić dokumentu |
| Faktura | NIP, nabywca, odbiorca, adres i powiązanie z zamówieniem | Dane są tylko w mailu albo znikają po zakupie |
| Mail potwierdzający | Numer zamówienia, produkty, kwota, płatność i dostawa | Klient dostaje sprzeczne informacje |
| Mail o błędzie płatności | Jasny status i możliwy kolejny krok | Klient myśli, że zamówienie jest opłacone |
| Mail o wysyłce | Metoda, numer nadania lub informacja o odbiorze | Tracking jest pusty albo dotyczy złej paczki |
Maile transakcyjne sprawdzaj po każdym ważnym scenariuszu. Zamówienie opłacone, płatność nieudana, płatność oczekująca, zmiana statusu, wysyłka i faktura nie powinny wysyłać tej samej treści. Klient ma wiedzieć, co się stało i co ma zrobić dalej.
W panelu zobacz również historię zmian. Przy odbiorze sklepu przydaje się informacja, kiedy zamówienie powstało, kiedy zmienił się status płatności, kto zmienił status realizacji i czy wyszedł mail. Bez historii trudno odtworzyć, czy problem leżał po stronie płatności, dostawy, maila czy ręcznej obsługi.
Jeśli odbiór obejmuje też analitykę, nie poprzestawaj na samym widoku zamówienia w panelu. Osobno sprawdź pomiar sprzedaży w sklepie internetowym od startu, zwłaszcza zdarzenie zakupu, wartość zamówienia, produkty, walutę i zgodność danych z panelem oraz operatorem płatności.
Czerwona flaga: faktura jest obiecana w checkoutcie, ale po zakupie nie wiadomo, gdzie powstaje dokument, kto go wystawia i czy klient dostanie go automatycznie. To nie jest detal administracyjny. To część procesu zamówienia.
Błędy konfiguracji, które blokują start
Błędy konfiguracji są groźne, bo często sklep wygląda poprawnie, dopóki nie przejdziesz całego procesu. Dlatego test odbiorowy powinien celowo wywołać problemy: błędny kod rabatowy, niepoprawny adres, anulowaną płatność, brak metody dostawy i powrót z bramki.
| Błąd konfiguracji | Objaw u klienta | Objaw w panelu | Decyzja |
|---|---|---|---|
| Tryb testowy na produkcji | Klient widzi metodę, ale realna płatność nie działa | Transakcje nie trafiają do rozliczeń produkcyjnych | Blokuje start |
| Błędne klucze API | Płatność nie przechodzi albo znika po przekierowaniu | Brak transakcji lub status nie zmienia się | Blokuje start |
| Brak webhooka, IPN lub callbacku | Klient wraca, ale status jest niejasny | Zamówienie zostaje oczekujące mimo płatności | Blokuje start |
| Zły URL powrotu z bramki | Po płatności klient trafia na błąd lub pustą stronę | Obsługa nie wie, czy proces się zakończył | Blokuje start |
| Cache checkoutu | Suma, dostawa lub formularz zachowują się losowo | Zamówienie ma nieaktualne dane | Blokuje start |
| Niepoprawny SSL | Bramka albo formularz mogą odrzucać proces | Płatności są niestabilne | Blokuje start |
| Brak metody dostawy | Klient nie może dokończyć zakupu | Zamówienie nie powstaje albo wymaga kontaktu | Blokuje start |
| Niedopracowana treść maila | Klient dostaje mniej jasną informację | Status w panelu jest poprawny | Do poprawy przed kampanią |
Nie każdy błąd ma ten sam ciężar. Literówka w mailu nie musi zatrzymać publikacji, jeśli zakup działa, płatność jest poprawnie oznaczona, a dostawa ma komplet danych. Ale brak statusu po płatności, znikający punkt odbioru, błędny koszt dostawy, niedziałająca faktura albo brak maila potwierdzającego to już blokery startu.
Warto też odróżnić błąd od nowego zakresu. Jeśli w ustalonym zakresie miała działać płatność online i nie działa, to jest błąd odbiorowy. Jeśli po testach chcesz dodać nowego operatora, kolejną metodę dostawy, automatyczne zwroty albo głębszą integrację fakturową, to zwykle jest osobny etap rozwoju.
Praktyczny wniosek: do publikacji można dopuścić drobne poprawki treści, ale nie można dopuścić sklepu, który nie potrafi jasno rozróżnić opłaconego, anulowanego i błędnego zamówienia.
Decyzja krok po kroku przed publikacją
Najprostsza decyzja odbiorowa ma cztery kroki. Najpierw przejdź ścieżkę klienta. Potem sprawdź panel. Następnie porównaj maile i dokumenty. Na końcu podziel uwagi na blokery oraz poprawki po starcie.
- Wybierz produkt z wariantem i dodaj go do koszyka.
- Sprawdź sumę, rabat, koszt dostawy i próg darmowej dostawy, jeśli istnieje.
- Przejdź checkout z danymi klienta, adresem, dostawą, płatnością i fakturą.
- Wykonaj płatność udaną, a osobno anulowaną lub błędną.
- Sprawdź stronę potwierdzenia i powrót z bramki.
- Wejdź do panelu i porównaj produkty, warianty, kwotę, płatność, dostawę, fakturę i status.
- Otwórz maile klienta i administratora, jeśli są wysyłane.
- Sprawdź etykietę, punkt odbioru, numer nadania i tracking, jeśli mają działać od startu.
- Wpisz wynik do protokołu: działa, do poprawy, blokuje start.
Jeśli sklep ma kilka głównych metod płatności, nie testuj tylko tej najwygodniejszej. Sprawdź te, które będą realnie używane przez klientów od pierwszego dnia: szybki przelew, karta, BLIK, przelew tradycyjny, pobranie, płatność odroczona albo inne metody włączone w danym sklepie. Nie musisz mieć wszystkich metod na start. Lepiej mieć mniej metod, które działają stabilnie, niż szeroki wybór wymagający ręcznego prostowania zamówień.
Podobnie z dostawą. Jeśli sklep oferuje kuriera, automat paczkowy, punkt odbioru i odbiór osobisty, każdy z tych modeli ma inną logikę danych. Kurier potrzebuje adresu, punkt odbioru musi zapisać identyfikator punktu, odbiór osobisty wymaga jasnej informacji, kiedy zamówienie będzie gotowe, a automat paczkowy zwykle musi trafić do etykiety i maila.
Decyzja praktyczna: uruchamiaj sklep wtedy, gdy najważniejsze 3-5 scenariuszy przechodzi bez ręcznego wyjaśniania. Nie czekaj na idealny system rozwoju, ale nie wypuszczaj podstawowej ścieżki sprzedaży z błędami statusów, dostawy, faktury, maili lub środowiska płatności.
Protokół odbioru: co podpisać, a co wraca do poprawy
Protokół odbioru nie musi być rozbudowanym dokumentem. Wystarczy tabela, która pokazuje scenariusz, wynik, dowód, decyzję i właściciela poprawki. Ważne, żeby wpisy były konkretne. "Płatności do sprawdzenia" nie pomaga. Lepszy zapis to: "po anulowaniu płatności zamówienie w panelu ma status opłacone".
| Test | Wynik, którego szukasz | Decyzja |
|---|---|---|
| Zamówienie opłacone | Zamówienie powstaje, status płatności jest poprawny, mail pasuje do panelu | Odbierz, jeśli dane są spójne |
| Płatność anulowana lub błędna | Sklep nie oznacza jej jako sukcesu i daje klientowi dalszy krok | Wstrzymaj, jeśli status myli obsługę |
| Dostawa kurierska | Koszt, adres i metoda trafiają do zamówienia | Wstrzymaj, jeśli danych nie da się użyć do wysyłki |
| Punkt odbioru | Wybrany punkt zapisuje się w panelu, mailu i etykiecie | Wstrzymaj, jeśli punkt znika |
| Faktura | Dane firmowe trafiają do właściwego miejsca | Wstrzymaj, jeśli dokument wymaga ręcznego odtwarzania danych |
| Maile | Treść odpowiada scenariuszowi i statusowi | Wstrzymaj, jeśli klient dostaje sprzeczne informacje |
| Błędy formularza | Komunikat wskazuje konkretne pole i nie kasuje danych | Popraw przed startem, jeśli klient nie wie, co zrobić |
| Mobile checkout | Zakup da się dokończyć na telefonie | Wstrzymaj, jeśli przycisk, dostawa lub płatność są ukryte |
Blokery odbioru to problemy, które uniemożliwiają zakup, płatność, dostawę, komunikację lub obsługę zamówienia. Do tej grupy należą: brak zamówienia w panelu, niepoprawny status płatności, brak maila potwierdzającego, brak danych dostawy, znikający punkt odbioru, niedziałająca faktura, błędny koszt dostawy, przerwany powrót z bramki i checkout niedziałający na telefonie.
Jeśli chcesz porównać ten test z pełnym odbiorem sklepu, użyj też szerszej checklisty: co sprawdzić przed uruchomieniem sklepu internetowego. Ten artykuł koncentruje się na płatnościach i dostawach, a pełny odbiór obejmuje również RWD, formularze, panel, treści i formalne przekazanie projektu.
Drobne poprawki mogą dotyczyć kolejności metod, mniej ważnego tekstu maila, dopracowania opisu dostawy, dodatkowego raportu albo rozwoju automatyzacji. Warunek jest jeden: zakup, płatność, dostawa, faktura i podstawowa komunikacja muszą działać bez kontaktu z wykonawcą.
Ostateczna decyzja jest prosta: podpisuj odbiór sklepu wtedy, gdy testowe zamówienie przechodzi od koszyka do potwierdzenia, a panel pozwala obsłużyć je bez zgadywania. Jeśli sklep tylko wygląda na gotowy, ale myli statusy płatności, gubi dostawę, nie wysyła maili albo nie przenosi danych do faktury, wróć z listą konkretnych braków przed publikacją.