Karty podarunkowe WooCommerce: konfiguracja i rozliczanie

Przed wyborem modułu opisz, co kupuje klient. Czy karta ma ustalony nominał, kto może ją wykorzystać, na jakie produkty i w którym sklepie? Określ też, czy niewykorzystana część pozostaje do kolejnych zakupów. Te zasady powinny być spójne na stronie produktu, w wiadomości dla odbiorcy oraz w obsłudze zamówienia.

Karta z opłaconą wartością nie jest po prostu kodem rabatowym. Kupon zmienia cenę zgodnie z regułą promocji, a karta pozwala wykorzystać przypisane środki na warunkach oferty. Konfigurację obniżek opisuje osobny poradnik rabatów w sklepie. Nie zastępuj rejestru salda serią ręcznie tworzonych kuponów, jeśli klient ma płacić tą samą kartą kilka razy.

Przygotuj krótką specyfikację: nominały, waluta, odbiorca, termin dostarczenia, zasady łączenia środków z inną płatnością oraz obsługa reklamacji. Wskaż również, czy karta działa tylko online. Nie obiecuj realizacji w sklepie stacjonarnym, dopóki nie ma wspólnego, sprawdzonego rejestru wartości. Dwie niezależne kopie salda mogą umożliwić wykorzystanie tych samych środków więcej niż raz.

Nie przenoś funkcji między wtyczkami tylko dlatego, że wszystkie mają Gift Cards w nazwie. W tym poradniku przykładem jest rozszerzenie opisane w instrukcji właściciela sklepu WooCommerce. Obsługuje cyfrowe karty prepaid. Dokumentacja nie deklaruje obsługi kart fizycznych ani promocyjnych i nie zapewnia wbudowanego bonu PDF do pobrania lub wydruku.

Zestaw wymagania ze sposobem działania modułu. Jeśli potrzebujesz kwoty wpisywanej przez kupującego, sprawdź dodatkową integrację; dokumentacja tego rozszerzenia wskazuje Name Your Price. Nominały wariantowe i dowolna kwota to różne funkcje. Przy sprzedaży fizycznej karty uwzględnij osobno wydruk, opakowanie, dostawę oraz powiązanie nośnika z kodem.

Przed zakupem licencji sprawdź zgodność z wersją WooCommerce, typem checkout, operatorem płatności i integracją dokumentów. Poproś wykonawcę o wskazanie ograniczeń, a nie tylko prezentację udanego zakupu. Szczególnie ważne są dopłata, anulowanie i częściowy zwrot. Jeżeli katalog jest wielowalutowy, ustal, w jakiej walucie przechowywane jest saldo i jak moduł obsługuje pozostałe waluty.

Nie oceniaj rozwiązania wyłącznie po wyglądzie wiadomości. Rejestr zmian, uprawnienia pracowników i możliwość odtworzenia historii konkretnej karty będą potrzebne przy pierwszym zgłoszeniu o brakujących środkach.

W omawianym Gift Cards karta może bazować na produkcie prostym lub wariantowym z włączoną opcją Gift Card. Nie trzeba szukać osobnego typu produktu o tej nazwie. Dla jednego nominału prosty produkt ogranicza liczbę ustawień; kilka określonych wartości można przedstawić jako warianty. Nazwy i opis powinny wyraźnie mówić, że klient kupuje kartę cyfrową.

Sprawdź powiązanie wybranego nominału z ceną produktu i wartością wydanego kodu. Jeżeli planujesz promocję na zakup karty albo dodatkową wartość, potraktuj ją jako odrębny projekt wymagający potwierdzenia obsługi i rozliczenia. Nie zakładaj, że zwykły rabat na produkt realizuje wszystkie skutki takiej oferty.

Formularz powinien odróżniać dane nabywcy od odbiorcy prezentu. Pokaż, dokąd trafi kod, kiedy ma zostać dostarczony i jak odbiorca może go wykorzystać. Przy wiadomości osobistej odbierz polskie znaki, dłuższy tekst i wygląd na telefonie. Nie twórz obietnicy natychmiastowego dostarczenia tylko dlatego, że nie ma fizycznej paczki.

Podstawy wariantów i pól produktu rozwija konfiguracja produktów w sklepie. Gotową kartę odbierz jak produkt: zdjęcie, opis, wariant, cena, koszyk i zgodność informacji po przejściu do płatności.

Wdrożenie musi rozpoznawać potwierdzoną płatność, a nie sam powrót kupującego ze strony operatora. Ustal, kiedy moduł tworzy kod, kiedy staje się on aktywny i co uruchamia wiadomość dla odbiorcy. W omawianym rozszerzeniu dostarczenie kodów korzysta z zadań w tle. Zatrzymany harmonogram może więc pozostawić opłacony zakup bez oczekiwanego powiadomienia.

Przy braku wiadomości sprawdzaj kolejne etapy: status zamówienia, istnienie karty, termin dostarczenia, wynik zadania oraz wynik przekazania wiadomości do transportu poczty. Status wysłano w aplikacji nie potwierdza, że odbiorca przeczytał wiadomość ani że trafiła do głównego folderu skrzynki. Nie wydawaj kolejnej karty tylko dlatego, że pierwszego powiadomienia nie znaleziono.

Dla terminu przyszłego sprawdź strefę czasową i zachowanie po opóźnieniu zadania. Ustal, kto reaguje na zaległe powiadomienia i jak obsługa weryfikuje prośbę o zmianę adresu odbiorcy. Kod reprezentuje wartość, dlatego samo podanie numeru zamówienia przez nieznaną osobę nie powinno wystarczać do jego przekazania.

Próby dostarczenia wykonuj wyłącznie transportem przechwytującym wiadomości do lokalnego podglądu. Odłącz prawdziwy serwer pocztowy oraz produkcyjne dane dostępowe. Można wtedy obejrzeć format i treść bez wysłania karty do rzeczywistej osoby.

Sprawdź trzy scenariusze: wartość zakupów niższa od salda, równa saldu i wyższa od dostępnych środków. Każdy wymaga czytelnej informacji o wykorzystanej kwocie i dalszej płatności. Przy dopłacie klient powinien wiedzieć, ile pokrywa karta, a ile operator płatności. Nie ukrywaj tej informacji pod ogólnym rabatem zamówienia.

Po częściowym użyciu sprawdź pozostałą wartość w rejestrze i sposób jej pokazania użytkownikowi. Jeśli rozwiązanie pozwala przypisać kartę do konta, odbierz dostęp po zalogowaniu oraz ochronę przed użyciem przez inną osobę. Zasady modułu dotyczące kodu i salda konta wyjaśnij w instrukcji dla klienta, bez zmuszania go do zgadywania różnicy.

Przerwana dopłata wymaga osobnej próby. Sprawdź, czy środki są zarezerwowane, wykorzystane czy zwolnione, a potem porównaj stan z zamówieniem. Nie poprawiaj salda ręcznie, dopóki nie ustalisz, co stanie się z oczekującą transakcją. Późniejsze potwierdzenie operatora może zmienić jej stan.

Kod nie powinien trafiać do publicznego adresu URL, parametrów analityki, zrzutów dla supportu ani ogólnodostępnych logów. Przy materiałach testowych używaj kodów syntetycznych. Odbierz także dwie próby wykorzystania tej samej wartości, aby potwierdzić kontrolę salda przy równoczesnych działaniach.

Rozróżnij zwrot zakupu samej karty od zwrotu towaru opłaconego kartą. To dwa różne zdarzenia. Przy pierwszym trzeba znać dotychczasowe wykorzystanie wartości; przy drugim sposób przywrócenia środków i ewentualnej dopłaty. Warunki prawne postępowania uzgodnij dla konkretnej oferty, zamiast opierać je wyłącznie na dostępnych przyciskach.

FAQ rozszerzenia Gift Cards potwierdza możliwość zwrotu środków wykorzystanych z kart w opłaconym zamówieniu, ale nie tworzenie nowej karty podczas zwrotu. Nie przedstawiaj więc dowolnego zwrotu jako automatycznej emisji bonu. Przy płatności mieszanej sprawdź oddzielnie część kartową i część obsługiwaną przez bramkę.

Dla obsługi przygotuj procedurę: identyfikacja zamówienia, stan karty przed operacją, kwota i powód, zatwierdzenie oraz wynik po operacji. Historia powinna pozwalać odróżnić automatyczny zwrot od ręcznej korekty. Nie dopisuj środków drugi raz dlatego, że panel zamówienia odświeżył się z opóźnieniem.

W próbie odbiorczej uwzględnij częściowy zwrot i ponowne otwarcie tego samego zgłoszenia. Sprawdź, czy pracownik widzi już wykonaną czynność. To ogranicza ryzyko pomyłki także wtedy, gdy sprawę przejmuje inna osoba.

UOKiK w poradach o kartach podarunkowych zwraca uwagę na jasne warunki, w tym ważność i zakres wykorzystania. Nie ma podstaw, aby przedstawiać jeden termin jako uniwersalną regułę wszystkich kart w Polsce. Uzgodnij warunki konkretnej oferty, a następnie sprawdź ich zgodność z ustawieniami i komunikacją dla klienta. Domyślna bezterminowość modułu nie jest samodzielnym rozstrzygnięciem prawnym.

Dla VAT istotne jest rozróżnienie bonu jednego i różnego przeznaczenia. Ustawa o VAT, art. 2 pkt 43-44 oraz art. 8a-8b, wiąże kwalifikację między innymi z wiedzą o miejscu świadczenia i należnym podatku w chwili emisji. Nie chodzi po prostu o jeden produkt albo wiele produktów do wyboru. Nazwa kategorii w zagranicznej instrukcji wtyczki nie zastępuje oceny polskiego modelu podatkowego.

Przekaż księgowości zasady karty i przykłady jej zakupu, częściowej realizacji oraz zwrotu. Oddziel moment otrzymania pieniędzy, VAT i ujęcie księgowe. Niewykorzystane saldo nie jest automatycznie czystym zyskiem do swobodnego rozpoznania. Wykonawca powinien wdrożyć uzgodniony sposób dokumentowania, a nie wybierać go na podstawie najłatwiejszego ustawienia modułu.

Obieg dokumentów sprawdź z konfiguracją faktur WooCommerce, a problemy wysyłki z diagnostyką KSeF. Karta podarunkowa sama w sobie nie określa wszystkich obowiązków dokumentacyjnych sklepu.

Odbiór przeprowadź na odizolowanej kopii z syntetycznymi klientami i kartami. Zablokuj produkcyjne płatności, emisję rzeczywistych kart, pocztę, faktury, KSeF oraz konwersje. Symulacja ma potwierdzić przepływ danych i wartości bez tworzenia zobowiązań wobec prawdziwych odbiorców.

Zachowaj wynik każdej próby oraz instrukcję reagowania na wyjątek. Po aktualizacji modułu powtórz najważniejsze scenariusze, szczególnie dopłatę i zwrot. Przy migracji sklepu zabezpiecz również rejestr kart i historię zmian, a nie tylko produkty oraz grafiki.

W ramach wdrożenia sklepu internetowego można przygotować produkt, przepływ salda i odbiór integracji. Przez kontakt przekaż planowane zasady karty oraz używane narzędzia. Do określenia zakresu potrzebna jest specyfikacja procesu, bez rzeczywistych kodów, danych odbiorców i sekretów dostępowych.