Programista WooCommerce we Wrocławiu

Sklep WooCommerce we Wrocławiu nie konkuruje w próżni. Konkuruje z Allegro, na którym kupuje ponad 20 milionów aktywnych klientów Polsce, i robi to w rynku, gdzie kupujący ma utrwalone nawyki: płaci BLIK-iem, odbiera z Paczkomatu i oczekuje faktury zgodnej z polskim prawem. Buduję sklepy Woo pod te konkretne oczekiwania, a nie pod ogólny, “globalny” wzorzec checkoutu, który w polskich warunkach gubi konwersję.

#Tworzenie sklepów WooCommerce we Wrocławiu

Wrocław to jeden z największych ośrodków IT i logistyki w kraju, więc trafiają tu dwa typy zleceń: sklep producenta albo dystrybutora z Dolnego Śląska, który chce sprzedawać online bez chaosu w magazynie, oraz cyfrowy biznes z dzielnicy biurowej przy Wrocławskim Parku Technologicznym, który potrzebuje Woo jako jednego z kanałów obok własnej aplikacji. Oba przypadki wymagają tego samego: checkoutu dopasowanego do polskiego kupującego, integracji z systemem magazynowo-księgowym i kodu, który przeżyje aktualizacje Woo. To jest zakres tej usługi.

#Płatności pod polskiego kupującego: BLIK, Przelewy24, PayU

W polskim e-commerce BLIK to dominująca metoda płatności, według badań Gemius/Przelewy24 z 2025 roku korzysta z niego około trzech czwartych kupujących online, a sam BLIK odpowiada za ponad połowę transakcji. Drugą warstwą są szybkie przelewy pay-by-link (Przelewy24, PayU, Tpay), karta i pobranie są dalej. Praktyczne konsekwencje dla wdrożenia Woo:

• Bramka musi natywnie obsługiwać BLIK (kod sześciocyfrowy plus potwierdzenie w aplikacji bankowej), a nie tylko kartę. Najczęściej oznacza to Przelewy24 albo PayU jako agregatora, bo to one obsługują większość większych polskich sklepów.
• Kolejność i widoczność metod płatności na checkoucie ustawiam pod realne udziały: BLIK na górze, szybki przelew zaraz pod nim. Domyślny szablon Woo z kartą na pierwszym miejscu działa wbrew nawykom rynku.
• Dla każdej bramki dokumentuję webhooki, matrycę statusów (opłacone, oczekujące, zwrot, częściowy zwrot, 3DS) i historię idempotencji, bo to one decydują o tym, czy zamówienie poprawnie zmienia status po płatności BLIK-iem.

#Dostawa: Paczkomaty InPost i wybór punktu w checkoucie

W Polsce duża część kupujących wybiera dostawę do automatu paczkowego, a wśród nich zdecydowana większość korzysta z Paczkomatów InPost, czyli największej takiej sieci na rynku. Sklep Woo bez wygodnego wyboru paczkomatu na checkoucie traci konwersję, niezależnie od tego, jak dobrze wygląda reszta strony. W praktyce wdrażam:

• Mapę wyboru punktu InPost (geowidget) wbudowaną w checkout, z zapamiętaniem ostatnio wybranego automatu, zamiast wysyłania klienta na zewnętrzną stronę.
• Reguły dostaw oparte na wadze i gabarycie (paczka gabarytowa nie zmieści się do automatu), z automatycznym przełączeniem na kuriera DHL, DPD albo InPost Kurier dla przesyłek przekraczających skrytkę.
• Integrację nadań z systemem przewoźnika, tak żeby etykieta i numer śledzenia wracały do zamówienia Woo i do maila klienta, a nie były klejone ręcznie.

#Faktury i KSeF: zgodność, której nie da się odłożyć

Od 2026 roku Krajowy System e-Faktur (KSeF) staje się obowiązkowy: od lutego dla największych podatników (sprzedaż powyżej 200 mln zł w 2024), a od kwietnia dla pozostałych czynnych podatników VAT. Faktura ustrukturyzowana to plik XML wystawiany przez KSeF z nadanym numerem, równolegle nadal funkcjonuje JPK_VAT (struktury JPK_V7M i JPK_V7K zostały zaktualizowane pod KSeF). Faktury B2C dla osób fizycznych pozostają poza obowiązkiem. Dla sklepu Woo oznacza to konkretne decyzje:

• Sklep zwykle nie wystawia faktur ustrukturyzowanych sam, robi to system księgowo-magazynowy. Rolą wdrożenia Woo jest poprawnie przekazać dane zamówienia (NIP nabywcy, stawki VAT, pozycje) do tego systemu, a numer KSeF odebrać z powrotem do zamówienia.
• Pole NIP na checkoucie i walidacja po stronie formularza decydują o tym, czy faktura B2B w ogóle da się wystawić. To drobny element interfejsu z dużą wagą zgodności.
• Granicę “co liczy podatek i wystawia fakturę” zapisuję w runbooku: czy robi to wtyczka fakturująca w Woo, czy zewnętrzny ERP. Mieszanie obu źródeł to najczęstsze źródło rozjazdu w numeracji.

#Integracja z magazynem i księgowością: Subiekt, Comarch, BaseLinker

Polski producent albo dystrybutor z okolic Wrocławia rzadko prowadzi sklep w oderwaniu od reszty firmy. Stany, ceny i dokumenty żyją w systemie magazynowo-księgowym, najczęściej w InsERT Subiekt GT lub nexo, w Comarch ERP Optima albo XL, czasem w WAPRO Mag. Sklep Woo musi się z tym zsynchronizować dwukierunkowo: produkty i stany z systemu do sklepu, zamówienia ze sklepu do systemu. W zależności od skali wdrażam:

• Bezpośrednią integrację (na przykład konektor Subiekt GT, SellIntegro, FirmesLink) tam, gdzie sprzedaż idzie głównie przez własny sklep.
• BaseLinker jako warstwę pośrednią tam, gdzie firma sprzedaje wielokanałowo, Woo plus Allegro plus inne marketplace. BaseLinker odejmuje stany ze wspólnej puli niezależnie od kanału, co realnie chroni przed nadsprzedażą, a na Allegro nadsprzedaż to negatywne oceny i ryzyko konta.
• Mapowanie pól (SKU, jednostki, stawki VAT, kategorie) ustalam na etapie architektury, bo to ono, a nie sama wtyczka, decyduje, czy synchronizacja jest spójna po obu stronach.

#Standardy techniczne

Customizacje Woo idą wyłącznie przez udokumentowane hooki action i filter oraz podział na własną wtyczkę i motyw, nigdy przez modyfikację plików rdzenia, bo sklep musi przeżyć aktualizacje WooCommerce i WordPressa. Infrastruktura testowa obejmuje PHPUnit do logiki biznesowej, testy e2e ścieżki checkoutu oraz Lighthouse CI dla budżetów wydajnościowych. Każde wdrożenie uruchamia testową transakcję na bramce (płatność testowa BLIK i kartą) przed promocją na produkcję.

#Jak pracujemy

Każdy projekt prowadzę według ustrukturyzowanego procesu, który ogranicza ryzyko i utrzymuje przejrzystość:

1. Audyt i ustalenie granic. Przegląd checkoutu, bramek, stref dostaw, podatków i integracji, plus baseline Lighthouse na najczęściej odwiedzanych stronach produktu i kategorii. Na tym etapie zapada decyzja, co liczy podatek, co wystawia fakturę i gdzie żyje stan magazynowy.
2. Sprinty deweloperskie. Pracujemy w iteracjach 1-2 tygodniowych z demo na koniec każdego sprintu. Widzisz postęp na bieżąco, dajesz uwagi na czas i możesz zmieniać priorytety bez wykolejania projektu.
3. Zapewnienie jakości. Każdy element przechodzi przez przegląd kodu, testy automatyczne, testy w różnych przeglądarkach, walidację dostępności i pomiar wydajności względem ustalonych budżetów, zanim trafi na środowisko testowe.
4. Przegląd na środowisku testowym. Kompletne rozwiązanie działa na kopii identycznej z produkcją. Testujesz z prawdziwą treścią, weryfikujesz integrację z Subiektem albo Comarchem i zatwierdzasz do uruchomienia.
5. Launch i wsparcie. Obsługujemy zmiany DNS, SSL, rozgrzewanie cache’u, weryfikację przekierowań i monitoring. Po uruchomieniu zostajemy w gotowości przez 72 godziny, a po okresie stabilizacji przechodzimy do bieżącej opieki z miesięcznymi przeglądami.

#Typowe wyzwania, które rozwiązujemy

Firmy z Wrocławia i Dolnego Śląska regularnie zgłaszają się do nas z tymi problemami:

• Złożone konfiguracje produktów z setkami wariantów (typowe u producentów mebli, komponentów czy odzieży roboczej z regionu), budujemy niestandardowe typy produktów z logiką warunkową i kalkulacją cen, obsługujące duże macierze SKU bez degradacji wydajności.
• Wolny checkout tracący konwersje, redukujemy czas ładowania koszyka i checkoutu przez cachowanie fragmentów, odroczone ładowanie skryptów, zoptymalizowaną inicjalizację bramki płatniczej i uproszczoną walidację formularza, włącznie z polem NIP i wyborem Paczkomatu.
• Rozjazd stanów między sklepem a magazynem, porządkujemy synchronizację z Subiektem, Comarchem lub BaseLinkerem tak, żeby pula towaru była jednym źródłem prawdy dla Woo i dla Allegro.
• Zgodność podatkowa, automatyczne stawki VAT, obsługa sprzedaży transgranicznej w UE (procedura OSS) i przygotowanie przepływu danych pod fakturę KSeF.

#Rezultaty, jakich możesz oczekiwać

Mierzymy sukces konkretnymi metrykami, nie subiektywnymi ocenami. To, na co realnie pracujemy:

• Krótszy czas ładowania stron produktów, kategorii i checkoutu, mierzony przed i po, z poprawą Core Web Vitals na najczęściej odwiedzanych adresach.
• Mniej porzuconych koszyków dzięki checkoutowi dopasowanemu do polskich nawyków: BLIK na wierzchu, wybór Paczkomatu w jednym kroku, sensowna walidacja danych do faktury.
• Stabilność stanów magazynowych między Woo a pozostałymi kanałami, czyli koniec z nadsprzedażą na Allegro w szczycie (Black Friday, sezon świąteczny).

#Dlaczego firmy we Wrocławiu wybierają WPPoland

Bezpośrednia komunikacja z seniorami, żadnych project managerów przekazujących wiadomości, żadnych juniorów uczących się na Twoim projekcie. Osoba, z którą rozmawiasz, jest osobą piszącą kod.

Po uruchomieniu zapewniamy ciągłą opiekę nad sklepem: testy A/B checkoutu, monitoring lejka konwersji, aktualizację feedów produktowych (także do Allegro i porównywarek) oraz utrzymanie zgodności bramek i fakturowania w miarę zmian regulacji, w tym kolejnych etapów KSeF.

Wycena jest indywidualna i przedstawiana na piśmie przed startem. Zmiany zakresu omawiamy otwarcie, z jasnymi konsekwencjami. Bez faktur-niespodzianek.

#Bezpieczeństwo i zgodność

W projektach WooCommerce bezpieczeństwo traktujemy jako zestaw decyzji architektonicznych, a nie uniwersalną obietnicę zgodności. Typowy zakres obejmuje HTTPS z HSTS tam, gdzie pasuje do infrastruktury, nagłówki Content Security Policy ograniczające XSS, skanowanie podatności zależności w CI, uwierzytelnianie dwuskładnikowe dla kont administracyjnych i regularne testowanie kopii zapasowych. Przy sklepach przetwarzających dane klientów przygotowujemy konfigurację zgód, umowy powierzenia, minimalizację danych i procedury reakcji na incydenty do weryfikacji z właścicielem procesu. Dla klientów na bieżącej opiece prowadzimy cykliczne przeglądy bezpieczeństwa: testy odtworzenia kopii, audyt dostępów, przegląd aktualizacji i listę ryzyk do decyzji biznesowej.

#Inżynieria wydajności

W e-commerce szybkość przekłada się wprost na przychód, opóźnienia rzędu setek milisekund mierzalnie obniżają konwersję (potwierdzają to publikowane analizy Akamai i Amazon). To szczególnie istotne w szczytach sprzedaży, a polski rynek ma ich kilka jasno wyznaczonych: Black Friday, przedświąteczny grudzień i okno przed długimi weekendami. Nasze podejście do wydajności sklepu Woo obejmuje:

• Optymalizacja zasobów, obrazy przetwarzane w procesie budowania do responsywnych srcset w WebP i AVIF, CSS purgowany i inlinowany dla treści above-the-fold, JavaScript code-split i ładowany dynamicznie.
• Architektura cachowania, wielowarstwowo: przeglądarka, CDN (Cloudflare), cache aplikacji (Redis) i cache zapytań do bazy z inteligentną inwalidacją, z osobnym potraktowaniem dynamicznych fragmentów koszyka.
• Optymalizacja sieci, HTTP/3 z QUIC, kompresja Brotli oraz hinty preconnect i dns-prefetch do bramek płatniczych i geowidgetu InPost, żeby zewnętrzne skrypty nie blokowały renderu.
• Optymalizacja renderowania, inlining krytycznego CSS, asynchroniczne style, lazy loading obrazów i iframów oraz animacje wyzwalane przez Intersection Observer.

Każda decyzja wydajnościowa jest oparta na danych. Mierzymy przed i po, dokumentujemy wpływ i dołączamy baseline wydajności do dokumentacji projektu.

#Pytania, które zadają nam firmy we Wrocławiu

Czy obsługujecie BLIK i Paczkomaty od razu po wdrożeniu? Tak, to dla polskiego sklepu punkt wyjścia, a nie dodatek. Konfigurujemy bramkę z BLIK-iem (zwykle Przelewy24 lub PayU) i wybór punktu InPost wbudowany w checkout, z testową transakcją na każdej metodzie przed startem.

Jak przygotowujecie sklep pod KSeF? Sklep przekazuje poprawne dane zamówienia (NIP, stawki, pozycje) do systemu księgowego, który wystawia fakturę ustrukturyzowaną, a numer KSeF wraca do zamówienia. Ustalamy jedno źródło fakturowania, żeby uniknąć rozjazdu numeracji, i zapisujemy to w runbooku.

Integrujecie się z Subiektem albo Comarchem? Tak. Dla sprzedaży głównie przez własny sklep używamy bezpośredniego konektora (Subiekt GT/nexo, Comarch Optima/XL, WAPRO Mag), dla sprzedaży wielokanałowej z Allegro warstwą pośrednią jest zwykle BaseLinker.

Czy pracujecie z firmami spoza Wrocławia? Tak. Mamy korzenie we Wrocławiu i znamy lokalny ekosystem techniczny, ale współpracujemy z klientami w całej Polsce i poza nią.

Ile trwa typowy projekt sklepu WooCommerce? Zależy od zakresu, gotowości treści i złożoności integracji. Prosty sklep z gotowym katalogiem to kilka tygodni, wdrożenie z integracją ERP, wieloma bramkami i synchronizacją z Allegro zwykle dłużej. Szczegółowy harmonogram przedstawiamy w fazie specyfikacji.

#Lokalne SEO i widoczność cyfrowa we Wrocławiu

Widoczność sklepu Woo we Wrocławiu to nie tylko słowa kluczowe, to architektura techniczna, która pozwala wyszukiwarce zrozumieć ofertę. Budujemy ją od fundamentów:

Indeksowanie i odkrywanie treści, dbamy, żeby wyszukiwarki szybko znajdowały i indeksowały ważne podstrony produktowe i kategorie. Przy dużych katalogach wdrażamy IndexNow, żeby zmiany cen i dostępności szybciej trafiały do indeksu.

Dane strukturalne, każdy produkt dostaje schema Product z ceną, dostępnością i ocenami, a sklep odpowiednie typy Organization i BreadcrumbList. To one decydują o bogatych wynikach w Google.

Sygnały E-E-A-T, strukturyzujemy treść pokazując doświadczenie i wiarygodność: dane firmy, polityki dostaw i zwrotów, realne opinie. Dla sklepu zaufanie to bezpośredni czynnik konwersji, nie tylko SEO.

Widoczność w wyszukiwaniu wspieranym przez AI, treść układamy tak, żeby była czytelna również dla Google AI Overviews, ChatGPT i Perplexity: jasne definicje, konkretne fakty o dostawie i płatnościach, uporządkowane dane.

Połączenie solidnej techniki i przemyślanej architektury treści pomaga sklepowi z Wrocławia budować trwały ruch organiczny zarówno w klasycznych wynikach, jak i w odpowiedziach generowanych przez AI, a to ważne na rynku, gdzie część popytu przechwytuje Allegro.

#Checkout i rzetelność zamówień: status ustala serwer, nie powrót klienta

Najczęstsza wada wdrożeń, które trafiają do nas na naprawę, nie leży w wyglądzie checkoutu, tylko w tym, co dzieje się po kliknięciu “zapłać”. Sklep dystrybutora czy hurtowni z Dolnego Śląska, który sprzedaje równolegle przez własne Woo i przez Allegro, płaci za ten błąd dwa razy: raz utraconym zamówieniem, drugi raz nadsprzedażą towaru, który był już komuś obiecany.

Status zamówienia ustala powiadomienie serwer do serwera, nigdy powrót klienta na stronę podziękowania. Powrót na endpoint order-received to zdarzenie przeglądarki, a przeglądarka jest zawodna: klient po autoryzacji BLIK-iem zamyka kartę, traci zasięg w windzie albo wraca do sklepu z cache. Dlatego hook woocommerce_thankyou służy wyłącznie do wyświetlenia treści i nie zmienia statusu. O pieniądzach decyduje callback bramki, w Woo odbierany na własnym adresie zwrotnym z parametrem wc-api, czyli przez akcję z rodziny woocommerce_api_... rejestrowaną przez samą bramkę. Handler po weryfikacji wywołuje metodę payment_complete na obiekcie zamówienia i przenosi je z pending do processing. Sygnaturę webhooka sprawdzamy na surowym ciele żądania odczytanym ze strumienia php://input, zanim cokolwiek zostanie sparsowane. Cięższą pracę po weryfikacji, czyli synchronizację z ERP czy nadanie przesyłki, zdejmujemy do Action Scheduler przez as_enqueue_async_action, żeby odpowiedź 200 wracała szybko i bramka nie zaczęła ponawiać.

Powtórzony sygnał z bramki musi być bezpieczny, bo powtórzenie jest normą, a nie awarią. Bramki ponawiają webhook przy timeoutach i przy każdym błędzie po stronie sklepu, więc ta sama płatność potrafi przyjść kilka razy, czasem równolegle z powrotem klienta. Identyfikator zdarzenia z bramki zapisujemy w metadanych zamówienia i sprawdzamy przed przetworzeniem, a sam blok obsługi obudowujemy blokadą: wp_cache_add na trwałym cache obiektowym (Redis) albo add_option z wyłączonym autoloadem, bo obie operacje są atomowe i pierwsza wygrywa. Do tego dochodzi warunek na aktualnym statusie i na numerze transakcji: zamówienie już opłacone nie zmienia stanu drugi raz, tylko dostaje notatkę o zignorowanym duplikacie.

Stan magazynowy rezerwujemy w momencie rozpoczęcia płatności, nie po jej potwierdzeniu. WooCommerce od wersji 4.3 zapisuje rezerwację w tabeli wp_wc_reserved_stock przez wc_reserve_stock_for_order, zwalnia ją przez wc_release_stock_for_order, a czas trzymania bierze z opcji woocommerce_hold_stock_minutes. Bez tego dwoje kupujących może wejść w płatność na ostatnią sztukę i oboje dostaną potwierdzenie. Faktyczne odjęcie stanu robi wc_maybe_reduce_stock_levels i pilnuje go flaga _order_stock_reduced, dzięki czemu powtórzony webhook nie odejmuje towaru drugi raz. Przy sprzedaży wielokanałowej rezerwacja Woo nie wie nic o Allegro, więc źródłem prawdy zostaje wspólna pula w BaseLinkerze albo w ERP, a Woo trzyma stan przez synchronizację; rezerwacja lokalna chroni wtedy tylko przed kolizją w obrębie sklepu.

Płatność odrzucona i zwrot częściowy to dwie osobne ścieżki, nie warianty tej samej. Odrzucenie ustawia status failed, a nie cancelled, bo zamówienie ma nadal dać się opłacić: klient dostaje link do ponowienia z metody get_checkout_payment_url, a obsługa nieudanej próby wisi na woocommerce_order_status_failed. Zwrot częściowy realizujemy przez wc_create_refund z listą pozycji i kwot oraz z flagą zwrotu na bramce; zamówienie zostaje wtedy w processing lub completed, a zwróconą kwotę czyta się z get_total_refunded, nie ze statusu. Traktowanie każdego zwrotu jak pełnego to typowe źródło rozjazdu raportów sprzedaży i stanów magazynowych po sezonie zwrotów.

Log ma pozwolić odtworzyć historię zamówienia bez dostępu do panelu bramki. Do dziennika przez wc_get_logger z własnym źródłem trafia identyfikator zdarzenia, status przed i po, kwota, wynik weryfikacji sygnatury i decyzja (przetworzono albo pominięto jako duplikat), nigdy pełny payload z danymi płatniczymi. Pliki lądują w wp-content/uploads/wc-logs/, podgląd jest w WooCommerce > Status > Logi, a okres przechowywania ustawia się w konfiguracji sklepu i uzgadniamy go z retencją wymaganą przez obsługę reklamacji. Równolegle każda istotna zmiana dostaje notatkę przez add_order_note, żeby obsługa klienta widziała tę samą historię co programista. Przy włączonym HPOS zamówienia żyją w tabelach wp_wc_orders i wp_wc_orders_meta, więc zapytania diagnostyczne i raporty idą przez wc_get_orders, a nie przez bezpośrednie odpytywanie wp_posts.

Jeśli sklep już działa i potrzebujesz stałej opieki zamiast nowego developmentu, sensowniejsza jest opieka techniczna WordPress we Wrocławiu.

#Rozpocznij swój projekt we Wrocławiu

Jeśli chcesz omówić budowę albo rozwój sklepu WooCommerce, wyślij krótki opis obecnej sytuacji, celu biznesowego i ograniczeń technicznych: jaki masz system magazynowy, przez jakie kanały sprzedajesz, jakie bramki i dostawy są w grze. Na tej podstawie sprawdzamy konfigurację, wskazujemy ryzyka i proponujemy praktyczny plan działania.

Jeśli planujesz nową budowę, migrację do nowej architektury albo stałe wsparcie techniczne, zacznij od spisania celów, ograniczeń i obecnego stanu projektu.

Zespoły porównujące sklep poza hubami często sprawdzają też programistę WooCommerce w Katowicach.

Zespoły porównujące sklep poza hubami często sprawdzają też programistę WooCommerce w Lublinie.

Zespoły porównujące sklep poza hubami często sprawdzają też programistę WooCommerce w Białymstoku.

Zespoły porównujące sklep poza hubami często sprawdzają też programistę WooCommerce w Szczecinie.

Zespoły porównujące sklep poza hubami często sprawdzają też programistę WooCommerce w Bydgoszczy.

Zespoły porównujące sklep poza hubami często sprawdzają też programistę WooCommerce w Rzeszowie.

Zespoły porównujące sklep poza hubami często sprawdzają też programistę WooCommerce w Częstochowie.

Zespoły porównujące sklep poza hubami często sprawdzają też programistę WooCommerce w Gliwicach.

Zespoły porównujące sklep poza hubami często sprawdzają też programistę WooCommerce w Kielcach.

Zespoły porównujące sklep poza hubami często sprawdzają też programistę WooCommerce w Łodzi.

Zespoły porównujące sklep poza hubami często sprawdzają też programistę WooCommerce w Poznaniu.