Programista WooCommerce w Göteborgu

Sklep WooCommerce w Göteborgu stoi obok Volvo Campus, Lindholmen Science Park, największego portu w Skandynawii i ekosystemu maritime tech, który ustawia oczekiwania co do webhooków, rezydencji danych i dokumentacji integracji. Kupujący w aglomeracji göteborskiej oczekuje Swish przy kasie, opcji Klarna Pay Now albo Pay Later, moms na fakturze z organisationsnummer i checkoutu, który nie pada po aktualizacji wtyczki w tygodniu premiery modelu albo przed konferencją maritime tech na Lindholmen. Ta strona opisuje programowanie WooCommerce właśnie w tym układzie: polski delivery, göteborski kontekst automotive, maritime i e-commerce, bez cennika i bez obietnic procentowych.

Szerszy opis produktu programowania WooCommerce, niezależny od miasta, jest na stronie programisty WooCommerce. Tu schodzimy do Göteborgu: Klarna, Swish, moms, IMY, pytanie o hosting w UE oraz dziennik incydentów przy awarii checkoutu. Motyw WordPressa, Gutenberg i wielojęzyczność SV/EN to osobna ścieżka: programista WordPress w Göteborgu. Stałe utrzymanie sklepu po wdrożeniu: opieka techniczna WordPressa w Göteborgu.

#Programowanie WooCommerce w Göteborgu i na rynku szwedzkim

Göteborg to nie Sztokholm fintech ani Malmö e-commerce. To drugie co do wielkości miasto Szwecji, dom Volvo i hub automotive oraz maritime tech wokół Lindholmen. Brief WooCommerce rzadko brzmi „zróbcie sklep jak startup z Avenyn”. Częściej brzmi: odziedziczony Woo z piętnastoma wtyczkami, checkout, który po patchu Klarna zostawia zamówienia w statusie „oczekujące na płatność”, magazyn synchronizowany ręcznie z ERP, a dyrektor operacyjny pyta o RODO, hosting w UE i organisationsnummer na fakturze PDF.

Dla sklepu WooCommerce w Göteborgu te fakty oznaczają trzy twardsze wymagania niż na typowym rynku B2C. Po pierwsze płatności lokalne: Swish to nie dodatek do Stripe. Klarna to nie „włączymy później”. Kupujący w Szwecji traktuje brak Swish jak sygnał, że sklep nie jest dla nich. Po drugie moms i dokumenty: stawka VAT, numer organisationsnummer na fakturze, zgodność z szwedzką interpretacją sprzedaży B2B i B2C to temat checkoutu, nie księgowości „na końcu projektu”. Po trzecie ślad decyzji: kto akceptuje flow płatności, co idzie na środowisko testowe, co na produkcję, gdy premiera modelu albo konferencja maritime tech na Lindholmen zbliża zamrożenie zmian.

Lindholmen Science Park i okoliczne biura przy Volvo Campus dokładają recenzentów, którzy czytają pull request i pytają, czy webhook ERP nie wysyła danych osobowych poza UE bez podstawy prawnej. Chalmers University of Technology i University of Gothenburg wypuszczają ludzi, którzy odróżnią wtyczkę płatności od motywu i wiedzą, że WooCommerce Subscriptions nie zastąpi procesu fakturowania B2B. Pendlerzy z Mölndal, Partille i Kungsbacka kupują online po szwedzku i po angielsku, więc sklep SV/EN z polskim zapleczem redakcyjnym jest tu częstszy niż czysto polski front ze szwedzkim panelem.

Typowy brief, który trafia do seniorów, nie brzmi „zróbcie ładny sklep”. Brzmi: motyw marketplace z 2019 roku, trzy wtyczki podatkowe naraz, Swish działa na sandboxie, na produkcji callback nie dochodzi, a nowa kampania produktowa startuje za dziesięć dni. To problem architektury checkoutu i procesu Git, nie problem „ładniejszego szablonu karty produktu”.

WPPoland nie jest kancelarią prawną ani dostawcą automotive. Sąsiedztwo Volvo i portu ustawia poprzeczkę dokumentacji, ról i integracji. Nie ustawia listy referencji przemysłowych.

#Checkout pod Klarna, Swish i kartę

Szwedzki checkout to nie uniwersalny szablon WooCommerce z włączonym PayPal. Kupujący w Göteborgu oczekuje Swish przy kasie mobilnej, opcji Klarna (Pay Now, Pay Later, Invoice w zależności od profilu merchanta), karty przez lokalnego dostawcę albo Stripe, czasem faktury B2B z terminem płatności dla firm z organisationsnummer. Każda z tych metod ma własne webhooki, własne kody błędów i własny sposób raportowania zwrotów. Sklejenie ich w jednej wtyczce „all-in-one” bez runbooka kończy się ręcznym klejeniem statusów zamówień w magazynie.

#Swish: callback, który musi przeżyć aktualizację

Swish to domyślna metoda płatności mobilnej w Szwecji. W WooCommerce integracja idzie przez certyfikowany dostawcę (np. Klarna Checkout z Swish, dedykowana wtyczka dostawcy szwedzkiego albo Stripe z obsługą Swish tam, gdzie merchant ma profil). Krytyczne elementy to nie przycisk w kasie, tylko callback po autoryzacji w aplikacji bankowej, mapowanie statusu na processing albo completed w WooCommerce, idempotencja webhooka i log, który da się pokazać, gdy zamówienie na 1 290 SEK jest opłacone w telefonie, a w panelu wciąż wisi „oczekujące na płatność”.

Przykład z audytu w Göteborgu: sklep B2C z częściami zamienne do maszyn przemysłowych. Po aktualizacji wtyczki płatności callback Swish przestał docierać, bo zmienił się endpoint w konfiguracji sandbox vs production. Magazyn wysyłał towar na podstawie maila od klienta, nie statusu w Woo. To nie jest błąd UX. To incydent operacyjny, który w marcu, w tygodniu premiery modelu, kosztuje więcej niż w lipcu.

W implementacji dokumentujemy: URL callbacku, nagłówki autoryzacji, matrycę statusów Swish → WooCommerce, procedurę testu na sandboxie i ścieżkę wycofania wtyczki. QA obejmuje pełną ścieżkę: koszyk, Swish, potwierdzenie w aplikacji, webhook, mail, edycja zamówienia, zwrot.

#Klarna: Pay Now, Pay Later i faktura B2B

Klarna w Szwecji to nie tylko „kup teraz, zapłać później”. Merchant w Göteborgu może potrzebować Klarna Checkout jako hostowanej kasy, Klarna Payments osadzonej w WooCommerce albo faktury B2B z weryfikacją organisationsnummer. Każdy wariant ma inne wymagania KYC po stronie merchanta, inne limity i inne webhooki przy zwrocie częściowym.

Dla WooCommerce granica odpowiedzialności jest taka: wtyczka Klarna obsługuje komunikację z API Klarna. Własna wtyczka WPPoland obsługuje mapowanie pól checkoutu (dostawa do Mölndal vs Partille, pickup w punkcie), reguły moms, synchronizację z ERP i logikę B2B, której Klarna nie zna. Motyw tylko pokazuje. Jeśli po zmianie motywu znika opcja Klarna Pay Later, architektura była zła.

Checkout Klarna wymaga też zgodności z wytycznymi brandowymi i z testami na środowisku, które Klarna akceptuje przed przełączeniem produkcji. W Göteborgu nie włączamy Klarna „w piątek na żywo”, bo marketing chce startu kampanii w poniedziałek. Idzie plan: sandbox, testy transakcji, webhooki, zwroty, dopiero produkcja.

#Karta, Apple Pay i granica z PCI

Karta przez Stripe albo lokalnego acquirera wymaga 3DS tam, gdzie regulacja tego wymaga, tokenizacji danych karty poza WooCommerce (PCI DSS scope reduction) i webhooków payment_intent.succeeded z idempotencją. Apple Pay i Google Pay to warstwa na tokenie, nie osobna bramka bez dokumentacji.

Dla sklepu w Göteborgu porównanie warstw checkoutu wygląda tak:

#Moms, faktury i zgodność pod IMY

Szwecja stosuje RODO wraz z krajowymi przepisami uzupełniającymi. Organ nadzorczy to Integritetsskyddsmyndigheten (IMY). Dla WooCommerce w Göteborgu wynika z tego konkretny zakres: lista podprocesorów (host, CDN, bramka płatności, ERP, fulfilment), umowa powierzenia tam, gdzie agencja przetwarza dane, procedura naruszenia w 72 godziny, minimalizacja danych w checkoutcie, integritetspolicy zgodna z art. 13 RODO, organisationsnummer na fakturze PDF.

Programowanie WooCommerce nie zastępuje DPO klienta. Dostarcza logi zamówień, oś czasu webhooków i opis zmian po incydencie. Klient klasyfikuje, czy wyciek danych z formularza checkoutu wymaga zgłoszenia do IMY. Nikt po stronie agencji nie podpisuje się pod „jesteście zgodni z RODO, bo macie SSL”.

Moms w WooCommerce to nie jedno pole w ustawieniach. To stawki per produkt, stawki per kraj dostawy, obsługa sprzedaży B2B z odwrotnym obciążeniem tam, gdzie ma zastosowanie, numer VAT na fakturze i eksport do systemu księgowego używanego w Göteborgu. Wtyczka fakturująca, która po aktualizacji gubi organisationsnummer albo stawkę moms, produkuje dokumenty, których księgowość nie przyjmie. W runbooku checkoutu pilnujemy, żeby PDF, pole podatkowe i sync do ERP nie rozjechały się po patchu.

Cookie banner i tracking przed zgodą to osobny temat, ale checkout go dotyka: piksel remarketingowy, który odpala się przed akceptacją plików cookie, psuje zaufanie i compliance. Przy wdrożeniu WooCommerce w Göteborgu kwartalny przegląd tagów na stronie kasy jest częścią kryteriów odbioru, nie dodatkiem SEO.

#Göteborg jako kontekst e-commerce, nie ozdobnik w tytule

Göteborg to drugie co do wielkości miasto Szwecji, dom Volvo i największego portu w Skandynawii. Tu liczy się ekosystem wokół Lindholmen Science Park, scena maritime tech przy nabrzeżu oraz warstwa cyfrowa dla operatorów łańcucha dostaw automotive obsługujących fabryki i centra logistyczne w regionie Västra Götaland.

#Automotive, maritime tech i B2B

Sklep B2B z częściami do linii produkcyjnej przy Volvo Campus ma inne wymagania niż sklep D2C z odzieżą. Ceny według roli klienta, minimalne wielkości zamówień, zapytania ofertowe zamiast natychmiastowego checkoutu, synchronizacja stanów z ERP, które nie toleruje webhooka wysyłającego pusty payload po aktualizacji wtyczki REST. Każdy endpoint musi przeżyć cykl aktualizacji Woo, bo tam kończy się odpowiedzialność sklepu i zaczyna odpowiedzialność operacji produkcyjnej.

Operator logistyczny z portu w Göteborgu może mieć WooCommerce obok systemów TMS i ERP. Kalkulator frachtu, status przesyłki, panel dostawcy: logika idzie do wtyczki, prezentacja do motywu, komunikacja przez REST z autoryzacją i logiem audytowym. Shortcode z 2019 roku zostaje do migracji. Nowy kod go nie dokłada.

#Zamrożenie wdrożeń w oknie produktowym

Göteborski rynek ma szczyty inne niż kalendarz targowy w Madrycie: premiery modeli, konferencje produktowe, okna kampanii przed konferencją maritime tech. Runbook wdrożenia WooCommerce dla klientów Göteborgu ma wpisane zamrożenie zmian produkcyjnych na uzgodnione okno freeze, zwykle od tygodnia przed premierą modelu do tygodnia po zamknięciu konferencji. Aktualizacje krytyczne bezpieczeństwa przechodzą przez środowisko testowe i okno nocne. Reszta czeka. Patch wtyczki Swish w poniedziałek otwarcia konferencji na Lindholmen to lekcja, której nikt nie chce powtarzać.

#Integracje magazynowe, ERP i marketplace

Sklep w Göteborgu rzadko żyje w izolacji. Stany magazynowe muszą się zgadzać z systemem w Mölndal albo z fulfilmentem w portowym hubie. Zamówienia muszą trafiać do ERP z numerem organisationsnummer i poprawną stawką moms. Zwroty muszą synchronizować się z bramką Klarna i ze stanem w magazynie.

Synchronizacja w czasie rzeczywistym między WooCommerce, ERP, marketplace i POS wymaga: kolejki zadań (Action Scheduler albo zewnętrzna kolejka), idempotencji przy ponownym wysłaniu webhooka, logu audytowego i reguł rozwiązywania konfliktów, gdy ERP i sklep pokazują różny stan. „Ręczne klejenie w Excelu w piątek” to antywzorzec, który widzimy po przejęciu odziedziczonych instalacji.

Dla fulfilmentu morskiego i automotive często dochodzi integracja z przewoźnikiem (PostNord, DHL, lokalny operator portowy) ze stawkami strefowymi, wagą i wymiarami, pickup point w aglomeracji göteborskiej i śledzeniem w panelu klienta. Kalkulator wysyłki nie może wołać API przewoźnika synchronicznie na każdym załadowaniu karty produktu. Cache, timeout i fallback muszą być zapisane w runbooku.

#Architektura WooCommerce: hooki, wtyczka, motyw

Nowa budowa w Göteborgu startuje od decyzji, która później kosztuje miesiącami: co żyje w motywie, co w własnej wtyczce, co zostaje w rdzeniu WooCommerce przez hooki. Ta decyzja jest zapisywana przed pierwszym commitem.

#Granica rdzeń, wtyczka, motyw

Rdzeń WooCommerce nie jest modyfikowany. Customizacje idą przez add_action, add_filter, rozszerzenie REST API i bloki serwerowe tam, gdzie storefront tego potrzebuje. Logika checkoutu Swish, mapowanie pól B2B, sync do ERP: wtyczka z własnym prefixem, autoload PSR-4, testy na ścieżce krytycznej. Kolory, siatka karty produktu, wzorzec hero: motyw. Jeśli po zmianie motywu znika subskrypcja albo cennik B2B, architektura była zła.

Odziedziczone instalacje w Göteborgu często mają pięć, siedem lat: child theme na komercyjnym szkielecie, ACF w szablonie produktu, piętnaście wtyczek z autoloadem, trzy wtyczki podatkowe naraz. Przepisanie na headless „bo tak wypada w 2026” jest droższe niż wyciągnięcie logiki do wtyczki, uporządkowanie checkoutu Klarna i Swish oraz refaktoryzacja zapytań na stronach kategorii.

#Headless tam, gdzie ma sens

Headless WooCommerce (storefront na Astro, Next.js albo React z Woo REST API) ma sens, gdy zespół frontendowy potrzebuje pełnej kontroli nad INP i nad warstwą prezentacji, a backend Woo zostaje systemem zamówień i katalogu. Nie ma sensu, gdy problemem jest zła wtyczka płatności i brak stagingu. Kompromis techniczny trafia do pisemnego dokumentu przed kickoffem, nie do decyzji w czacie w czwartek wieczorem.

#Wydajność checkoutu i Core Web Vitals

Wolny checkout w Göteborgu to nie tylko zła konwersja. To sygnał dla kupującego, że sklep „nie jest szwedzki”. Core Web Vitals na stronie produktu, kategorii i kasy mierzymy na realnych URL-ach z Klarna i Swish włączonymi, nie na pustej instalacji.

Typowe bottlenecki, które naprawiamy:

• ciężki motyw z dziesiątkami zapytań SQL na karcie produktu;
• autoload optionów z porzuconych wtyczek page buildera;
• synchroniczne wołanie API przewoźnika na checkoutcie;
• obrazy produktowe bez AVIF i bez jawnych wymiarów (CLS);
• fragment koszyka cache’owany bez reguły dla zalogowanego użytkownika.

LCP poniżej progu na mobile, INP bez lagów od skryptów czatu i widgetów mapy, CLS z zarezerwowanym miejscem na baner Klarna: to kryteria odbioru, nie marketing. Monitoring przez Lighthouse CI w pipeline i RUM z punktu pomiaru w UE jest częścią runbooku wdrożeniowego.

Przed konferencją maritime tech na Lindholmen idzie osobny przegląd cache, limitów PHP i CDN. Po evencie idzie ścinka landingów kampanii i weryfikacja, że webhooki zamówień nadal docierają przy skoku ruchu z telefonów uczestników.

#Proces realizacji: audyt, gałęzie Git, QA, przekazanie

Każdy projekt WooCommerce w Göteborgu realizujemy według procesu minimalizującego ryzyko przy checkoutcie:

1. Audyt i specyfikacja. Przegląd katalogu, checkoutu, bramek Klarna i Swish, integracji ERP, punktu odniesienia Lighthouse. Pisemna specyfikacja z decyzjami architektonicznymi, harmonogramem i kryteriami odbioru przed pierwszym commitem.

2. Implementacja w gałęziach funkcyjnych. Kod zgodny z WordPress Coding Standards i WooCommerce best practices. przegląd kodu na każdej gałęzi. środowisko testowe z tym samym stosem PHP, tymi samymi wtyczkami płatności w trybie sandbox.

3. QA ścieżek zamówień. End-to-end na stagingu: koszyk, Swish, Klarna, karta, zwrot, mail, edycja w panelu, sync do ERP. Ścieżki błędów: odrzucona płatność, timeout webhooka, podwójne kliknięcie „zapłać”.

4. Wdrożenie i okno stabilizacji. Deploy przez udokumentowany proces z ścieżką wycofania. Po uruchomieniu zespół jest w gotowości przez uzgodnione okno na natychmiastową reakcję przy incydencie płatności.

5. Dokumentacja i przekazanie. Runbook dla każdej bramki, żyjąca dokumentacja dla managera sklepu i programistów, sesja przekazania. Sklep może trafić do zespołu klienta albo na opcjonalną opiekę.

#Przypadek: Swish działa na sandboxie, produkcja klei statusy ręcznie

Sklep B2C z akcesoriami outdoor w aglomeracji göteborskiej, checkout Swish przez certyfikowaną wtyczkę, kampania przed sezonem trekkingowym. Na sandboxie wszystko zielone. Po przełączeniu produkcji callback szedł na stary URL z poprzedniego hostingu w Irlandii, bo w .env stagingu nikt nie zaktualizował SWISH_CALLBACK_URL przy migracji na origin w eu-north-1.

Efekt: trzy dni ręcznego oznaczania zamówień jako opłacone po screenach z aplikacji Swish od klientów. Magazyn wysłał towar bez gwarancji, że płatność faktycznie przeszła. Po audycie: poprawka URL, test na stagingu z prawdziwym sandboxem Swish, matryca statusów runbooku, alert gdy webhook nie dociera w ciągu 120 sekund od pending. Nie ma tu nazwy firmy, bo to kształt zdarzenia. Jest mechanizm: najpierw środowisko testowe z tym samym callbackiem co produkcja, potem przełączenie.

Ten sam kształt wraca przy Klarna Pay Later po aktualizacji WooCommerce, przy sync ERP, który po patchu REST wysyła pusty line_items, i przy „drobnej” aktualizacji motywu, która usuwa pole organisationsnummer z checkoutu B2B. Göteborg nie wybacza tego ciszej niż inny rynek, bo obok siedzi ktoś, kto pyta o IMY, o premierę modelu albo o slot w kalendarzu konferencji maritime tech.

#Hosting w UE i latencja dla aglomeracji göteborskiej

Dane osobowe w checkoutcie ciągną pytanie: w której jurysdykcji stoi serwer. AWS eu-north-1 w Sztokholmie, eu-west-1 w Irlandii, Hetzner w Niemczech, Binero albo Loopia w Szwecji to różne odpowiedzi dla compliance officer, ale wszystkie mieszczą się w UE. Origin w USA bez Standard Contractual Clauses to zwykle veto.

Pytanie „czy hosting jest w Göteborgu” wraca rzadziej niż „czy w UE”. Odpowiedź operacyjna: jurysdykcja UE, kopia nie wyjeżdża na bucket w regionie US bez uzgodnienia, CDN kończy TLS w uzgodnionej strefie, cache nie trzyma prywatnego koszyka ani danych karty. Origin w Sztokholmie albo Frankfurt plus CDN z terminałem w UE zwykle wystarcza dla użytkowników Mölndal, Partille i Kungsbacka.

#Bezpieczeństwo checkoutu i PCI

Bezpieczeństwo to lista decyzji, nie plakietka. HTTPS z HSTS, nagłówki ograniczające XSS, 2FA do wp-admin, minimum kont administratorskich, zakaz wtyczek nulled, parametryzacja zapytań, nonce na formularzach checkoutu, rate limiting na endpoincie logowania. Dane karty nie trafiają do bazy WooCommerce, gdy bramka to obsługuje przez tokenizację.

Przy incydencie z danymi z checkoutu dziennik musi mieć datę pierwszej wiedzy, listę zmienionych wtyczek i oś czasu webhooków. Klient decyduje o zgłoszeniu do IMY. Agencja dostarcza materiał, nie zastępuje organu nadzorczego.

#Rodzeństwo w Skandynawii

Ten sam model programowania WooCommerce działa w innych nordyckich miastach, z tym samym runbookiem i innym kontekstem lokalnym:

• Programista WooCommerce w Sztokholmie
• Programista WooCommerce w Oslo
• Programista WooCommerce w Helsinkach

#Jak zaczynamy

Zakres, harmonogram i wycena są indywidualne i lądują w umowie przed startem. Na tej stronie nie ma tabeli pakietów ani stałych cen. Krótki opis sklepu, listy wtyczek, bramek Klarna i Swish oraz informacja, czy w najbliższych tygodniach jest premiera modelu albo konferencja maritime tech, wystarczy, żeby zaproponować audyt.

Kontakt: formularz. Z tego powstaje plan: co naprawiamy w checkoutcie, jakie integracje dokumentujemy i jakie kryteria odbioru obowiązują przed przełączeniem produkcji.

Programowanie WooCommerce w Göteborgu ma sens, gdy sklep ma nosić sprzedaż na rynku szwedzkim z Swish, Klarna, moms i dokumentacją, która przeżyje aktualizację i audyt IMY. Gdy trzeba tylko utrzymać istniejący sklep bez przebudowy checkoutu, wchodzi opieka techniczna. Gdy trzeba zbudować warstwę WordPressa obok sklepu, wracamy do developmentu motywu. Ta strona trzyma się jednego tematu: seniorskie programowanie WooCommerce dla firm w Göteborgu.