Programista WooCommerce w Amsterdamie

Polski zespół, który buduje i rozwija WooCommerce dla firmy w Amsterdamie, nie dokłada „kolejnego sklepu na szablonie”. Konfiguruje checkout w EUR z iDEAL, Bancontact, BTW holenderskim i wysyłką PostNL, na rynku, gdzie klient oczekuje redirectu do banku w trzy sekundy, a księgowość odrzuca fakturę bez poprawnego numeru BTW. Ta strona opisuje programowanie WooCommerce właśnie w tym układzie: polski delivery, amsterdamski kontekst e-commerce i fintech, bez cennika na stronie city.

Szerszy opis usługi programisty WooCommerce, niezależny od miasta, jest na stronie programisty WooCommerce. Tu schodzimy do Amsterdamu: iDEAL, Bancontact, BTW, PostNL, RODO z holenderską Autoriteit Persoonsgegevens (AP), integracje z Exact Online i runbook freeze na King’s Day. Utrzymanie po wdrożeniu to osobna ścieżka: opieka techniczna WordPress w Amsterdamie. Budowa motywu od zera albo przebudowa frontu idzie do programisty WordPress w Amsterdamie.

#Co oznacza programista WooCommerce przy sklepie holenderskim

Programowanie WooCommerce to nie „instalacja motywu z marketplace”. Dla sklepu D2C z centrum dystrybucji przy Port of Amsterdam, marki lifestyle z De Pijp, sklepu B2B z fakturą na BTW-nummer albo marketplace wielovendorowego z magazynem w Haarlem praca ma cztery twarde elementy: checkout, który kończy płatność iDEAL bez błędu redirectu, BTW zgodny z holenderską księgowością, wysyłka PostNL z etykietą, którą kurier skanuje, oraz integracje ERP, które nie rozjadą się po aktualizacji wtyczki. Reszta - konfigurator produktu, filtrowanie katalogu, headless storefront - stoi na tym fundamencie.

Sklep w Amsterdamie zbiera dane, których nie wolno traktować jak treści bloga. Konto klienta z adresem dostawy w Beneluksie, zapis karty w vault bramki, eksport zamówień do Exact Online, newsletter po zgodzie cookie zgodnej z holenderskim Urząd Ochrony Danych Osobowych: każdy z tych elementów po aktualizacji WooCommerce potrafi się rozsypać ciszej niż strona główna. Dlatego QA nie kończy się na „strona się ładuje”. Kończy się na ścieżce, którą kupujący z Amsterdamu-Zuid albo z Antwerpii naprawdę klika.

#Checkout w EUR z iDEAL i Bancontact

Holenderski rynek e-commerce operuje w EUR. iDEAL to metoda płatności, którą większość konsumentów Holandii wybiera jako pierwszą: redirect do banku (ABN AMRO, ING, Rabobank, bunq), potwierdzenie w aplikacji mobilnej, powrót do sklepu ze statusem opłacone. WooCommerce obsługuje iDEAL przez Mollie, Stripe, MultiSafepay albo Adyen. Integracja wymaga poprawnej obsługi webhooków (payment_intent.succeeded, charge.refunded), idempotencji po stronie sklepu i testów na sandboxie przed produkcją.

Bancontact uzupełnia iDEAL tam, gdzie sklep obsługuje klientów z Belgii i transgraniczne zamówienia w Beneluksu. W checkoutu kolejność metod ma znaczenie: iDEAL na górze dla adresów NL, Bancontact widoczny dla BE, karta jako fallback. Polski runbook z BLIK i Przelewy24 nie przenosi się do Holandii jeden do jednego. W Amsterdamie checkout, który pokazuje tylko kartę kredytową, traci konwersję szybciej niż wolna strona produktu.

Implementacja idzie przez hooki WooCommerce (woocommerce_available_payment_gateways, woocommerce_checkout_create_order, filtry na pola billing) zamiast modyfikacji rdzenia. Runbook dokumentuje, która bramka obsługuje subskrypcje, zwroty częściowe i 3DS, oraz matrycę kart i kont testowych na stagingu.

#BTW holenderski, nie niemiecki MwSt

W Holandii podatek od towarów i usług to BTW (belasting over de toegevoegde waarde). To nie jest niemiecki MwSt ani polski VAT skopiowany do pola „tax”. Stawki standardowe to 21% dla większości towarów, 9% dla żywności, książek i niektórych usług medycznych, 0% dla eksportu poza UE po weryfikacji dokumentów.

W WooCommerce konfigurujemy klasy podatkowe, strefy dostaw powiązane z BTW, pole BTW-nummer (VAT ID) z walidacją VIES dla klientów B2B i reverse charge tam, gdzie prawo na to pozwala. Faktura PDF musi zawierać numer KVK (Kamer van Koophandel) sprzedawcy, BTW-nummer, poprawną stawkę i podstawę prawną zwolnienia, jeśli dotyczy. Po aktualizacji wtyczki fakturującej albo WooCommerce Tax sprawdzamy eksport do Exact Online, Twinfield albo AFAS: jedna rozjechana stawka psuje cały miesiąc księgowy.

Sklep, który sprzedaje do Niemiec albo Belgii z magazynu w Amsterdamie, potrzebuje osobnej mapy stawek OSS i reguł progu distance selling. To nie jest „włącz uniwersalną wtyczkę podatkową”. To decyzja architektoniczna zapisana przed implementacją. Szerszy kontekst rynków UE opisuje strona WooCommerce dla zagranicznych sklepów.

#PostNL, DHL i strefy dostaw w Beneluksu

PostNL to domyślny przewoźnik dla paczek konsumenckich w Holandii. Integracja w WooCommerce obejmuje strefy wysyłki (NL, BE, DE jako osobne reguły), kalkulację wagową, API etykiet i tracking z numerem zgodnym z formatem PostNL. Sklep z odroczoną wysyłką w oknie King’s Day albo Black Friday musi mieć runbook: które strefy są zamrożone, które stawki tymczasowo wyłączone, jak purge cache nie psuje koszyka z wybraną metodą PostNL PakjeGemak (odbiór w punkcie).

DHL i DPD uzupełniają PostNL przy większych paczkach B2B albo eksporcie poza Beneluks. Każda integracja kurierska to webhook statusu, mapowanie na status zamówienia WooCommerce i test po aktualizacji wtyczki wysyłkowej. Operator magazynu w Amsterdamie-Noord nie akceptuje argumentu „strona główna działa”, kiedy etykieta PostNL po patchu zwraca błąd API.

#Amsterdam jako kontekst rynku, nie ozdobnik w tytule

Amsterdam to największy ośrodek e-commerce w Holandii, węzeł fintech (Adyen ma siedzibę w mieście) i dom B. Amsterdam, jednego z największych hubów startupowych w Europie. Rynek holenderski ma wysoką penetrację zakupów online, silną adopcję iDEAL i wymagania compliance, które prawnik klienta zada zanim marketing zatwierdzi nowy landing. To nie jest Berlin z MwSt ani Warszawa z InPostem. Tu sklep WooCommerce musi przeżyć aktualizację w tym samym tygodniu, w którym klient pyta o AP i o rezydencję danych w EOG.

#B. Amsterdam, fintech i e-commerce

B. Amsterdam w Amsterdamie-Zuidoost koncentruje setki firm cyfrowych: od D2C przez SaaS po marketplace. WordPress z WooCommerce trzyma sklepy marek, które zaczęły od MVP na Shopify albo Magento i potrzebują własnego kodu checkoutu, integracji z Exact Online i kontroli nad danymi klienta. Adyen, Mollie i inni procesorzy płatności z regionu Amsterdamu ustawiają oczekiwania: webhook musi być szybki, idempotentny i udokumentowany.

Dla programisty WooCommerce wynika z tego prosta rzecz: integracja płatności nie kończy się na „wtyczka zainstalowana”. Kończy się na runbooku z diagramem redirect iDEAL, listą eventów webhook, procedurą reconcyliacji i testem zwrotu na stagingu przed każdym release.

#King’s Day, Black Friday i freeze wdrożeń

Koningsdag (27 kwietnia) i okres Black Friday to okna, w których sklep w Amsterdamie nie toleruje eksperymentu na produkcji. Runbook freeze zapisuje: brak deployów checkoutu od tygodnia przed eventem, aktualizacje krytyczne bezpieczeństwa tylko przez środowisko testowe i okno nocne, osobny przegląd cache i limitów PHP przed szczytem ruchu. Marketing zaplanował kampanię na piątek rano; developer, który robi „drobny patch bramki” w czwartek wieczorem, uczy się kosztu na własnej skórze, kiedy iDEAL redirect zwraca 500 przy pełnym koszyku.

To nie preferencja developera. To decyzja operacyjna uzgodniona z klientem przed sezonem. Ten sam schemat stosujemy przy wdrożeniach B2B, gdzie portal hurtowy musi zostać dostępny w oknie zamówień tygodniowych - opisuje to strona modernizacji WooCommerce B2B.

#WordPress Amsterdam i praktyka spoza panelu hostingu

WordPress Amsterdam spotyka się regularnie w ekosystemie holenderskim (wpmeetupamsterdam.nl). To nie kanał sprzedaży. To miejsce, w którym widać, jak lokalni maintainerzy aktualizują Woo, jak rozmawiają o uprawnieniach i o Mollie sandbox. Programowanie, które nigdy nie wychodzi poza ticket, gubi ten kontekst: w Amsterdamie część zespołów i tak siedzi po stronie e-commerce i usłyszy te same pytania o iDEAL i AP na meetupie w B. Amsterdam.

WP-CLI i Action Scheduler w utrzymaniu sklepu nie są ozdobą. To sposób, żeby synchronizację katalogu, kolejkę webhooków ERP i eksport zamówień zrobić powtarzalnie, z logiem, bez klików wp-admin na produkcji w piątek po południu.

#RODO, AP i oczekiwania holenderskiego klienta

Holandia stosuje RODO (AVG - Algemene verordening gegevensbescherming). Organ nadzorczy to Autoriteit Persoonsgegevens (AP). Dla WooCommerce w Amsterdamie wynika z tego konkretny zakres prac: lista podprocesorów (host, CDN, bramka płatności, poczta, analityka), umowa powierzenia tam, gdzie agencja przetwarza dane, procedura naruszenia w 72 godziny, cookie banner zgodny z holenderską interpretacją zgody przed marketingowymi tagami.

Utrzymanie sklepu nie zastępuje DPO klienta. Dostarcza logi, oś czasu i opis zmian po incydencie. Klient klasyfikuje, czy zdarzenie wymaga zgłoszenia do AP. Nikt po stronie agencji nie podpisuje się pod „jesteście zgodni z RODO, bo macie SSL”. Sklep, który po aktualizacji wtyczki cache wysyła Meta Pixel przed zgodą cookie, produkuje ryzyko, które compliance officer w Zuidas odczuwa szybciej niż spadek konwersji.

#Hosting w EOG i rezydencja danych

Pytanie „czy hosting jest w Holandii” wraca rzadziej niż „czy w EOG”. AMS1 u dostawców chmurowych, TransIP w NL, OVH we Francji, Hetzner w Niemczech: różne odpowiedzi dla compliance, wszystkie w EOG. Ashburn albo Oregon to Stany i zwykle veto bez Standard Contractual Clauses. Rozmowa o hostingu w onboardingu jest merytoryczna: czy produkcja jest w EOG, czy kopia nie wyjeżdża na bucket US, czy CDN kończy TLS w uzgodnionej strefie, czy Redis nie trzyma prywatnego koszyka.

Dla sklepu z klientami w Amsterdamie liczy się latencja checkoutu z sieci holenderskiej i niemieckiej, nie tylko wynik Lighthouse z laptopa developera w Krakowie. Monitoring syntetyczny z punktu pomiaru w EOG jest częścią kontraktu, nie dodatkiem.

#Integracje ERP, magazyn i fulfilment

Sklep w Amsterdamie, który rośnie powyżej ręcznego eksportu CSV, łączy WooCommerce z Exact Online, Twinfield, AFAS albo zewnętrznym WMS. Synchronizacja stanów magazynowych, cen B2B według roli klienta, numer zamówienia w ERP i zwrot stocku po anulowaniu to praca przez REST API, webhooki i Action Scheduler, nie przez „wtyczkę uniwersalną bez dokumentacji”.

Granica między rdzeniem Woo, wtyczką integracyjną a motywem zapada na etapie architektury. Szczegóły mapowania pól, retry webhooków i reconcyliacji opisuje integracja WooCommerce z ERP. Przy przejęciu sklepu z trzema wtyczkami sync naraz pierwszy sprint to inwentaryzacja i wyłączenie duplikatów, zanim cokolwiek dotknie produkcji.

#B2B: ceny według roli, BTW-nummer i minimalne zamówienie

Portal hurtowy w WooCommerce dla klienta z Amsterdamu wymaga logowania, mapowania roli na cennik, walidacji BTW-nummer przed reverse charge, minimalnej wartości koszyka i faktury zbiorczej. To nie jest rozszerzenie B2C z ukrytymi cenami. To osobna ścieżka checkoutu testowana na stagingu z kontem testowym Exact. Szerszy kontekst modernizacji B2B jest na stronie modernizacji WooCommerce B2B.

#Przypadek: patch cache położyłby redirect iDEAL przed kampanią, środowisko testowe to zatrzymał

Sklep D2C na WooCommerce, odzież, magazyn w Haarlem, ruch z Instagramu i newslettera, piątek 10:00 start kampanii z kodem rabatowym. W kolejce do produkcji leżała aktualizacja wtyczki cache obiektowego plus patch SEO, „drobny, na żywo, bo to tylko Redis”.

Na stagingu, sklonowanym z produkcji razem z Redisem i z Mollie w trybie test, checkout z iDEAL po dodaniu kodu rabatowego zwracał redirect na stronę błędu banku. Przyczyna: zmiana klucza sesji po patchu cache, stary fragment motywu wołał WC()->session przed inicjalizacją gateway, CDN trzymał HTML checkoutu bez rozróżnienia zalogowany/niezalogowany. Na produkcji ten sam zestaw poszedłby w czwartek wieczorem. Kampania wyszłaby o 10:00, setki koszyków utknęłyby bez płatności, support dostałby ticketów zanim ktokolwiek zdążyłby cofnąć deploy.

środowisko testowe zatrzymał release. wycofanie zmian na kopii testowej potwierdził, że sama wtyczka SEO jest niewinna, gdy motyw inicjalizuje sesję przed gateway. Motyw dostał poprawkę, checklista checkoutu (iDEAL test, Bancontact, kupon, purge, mail potwierdzenia, BTW na fakturze) przeszła, dopiero potem produkcja. Nie ma tu nazwy firmy, bo to kształt zdarzenia, nie case study z logotypem. Jest mechanizm: najpierw kopia, potem produkcja.

Ten sam kształt wraca przy wtyczce PostNL, która po aktualizacji gubi format etykiety PakjeGemak, przy polu BTW-nummer znikającym z PDF po patchu WooCommerce Tax i przy „drobnej” aktualizacji, która wyłącza webhook Mollie. Amsterdam nie wybacza tego ciszej niż inny rynek. Wygląda to gorzej, bo obok siedzi ktoś, kto pyta o AP, o iDEAL albo o slot w kalendarzu fulfilmentu.

#Jak pracujemy: sprinty, środowisko testowe i kryteria odbioru

Każdy projekt w Amsterdamie idzie przez ustrukturyzowany proces. Audyt istniejącego sklepu albo wymagań greenfield: katalog, checkout, bramki, BTW, PostNL, integracje, Lighthouse na kluczowych URL. Specyfikacja techniczna z decyzjami architektonicznymi, harmonogramem i kryteriami odbioru zanim padnie pierwsza linijka kodu produkcyjnego.

Implementacja w sprintach 1-2 tygodniowych z demo na końcu iteracji. QA end-to-end na stagingu identycznym z produkcją: ten sam PHP, Redis, Mollie sandbox, te same wtyczki. Wdrożenie z przetestowaną ścieżką wycofania. Dokumentacja runbooków dla bramek, BTW i kurierów. Sesja przekazania dla managera sklepu i developera klienta.

Po wdrożeniu sklep może zostać u klienta, trafić na opiekę techniczną WordPress w Amsterdamie albo na abonament opieki WooCommerce uzgodniony indywidualnie. Zakres, godziny reakcji i cena lądują w umowie przed startem. Na tej stronie nie ma tabeli pakietów ani transz procentowych.

#Wydajność checkoutu i Core Web Vitals

Origin w EOG nie naprawi ciężkiego motywu z dziesięcioma wtyczkami na każdej podstronie. HTTP/3, Brotli, AVIF, lazy load bez psucia LCP hero produktu, cache, który nie trzyma prywatnego koszyka ani sesji iDEAL w trakcie redirectu: to praca programisty WooCommerce, nie osobna „optymalizacja SEO”. Core Web Vitals mierzymy na checkoutu i na stronie produktu z galerią, nie na pustej instalacji. INP psuje się od skryptów chatu, od Mollie.js ładowanego w złej kolejności i od tag managera dodanego poza ticketingiem.

Przed King’s Day albo Black Friday idzie osobny przegląd cache, limitów PHP, kolejki Action Scheduler i CDN. Sklep z setkami wariantów i integracją Elasticsearch do wyszukiwania produktów wymaga profilu zapytań, zanim ktokolwiek dorzuci „kolejną wtyczkę cache”.

#Headless i migracje, kiedy mają sens

Nie każdy sklep w Amsterdamie potrzebuje headless. Front na Astro albo Next.js z WooCommerce jako backend ma sens przy wielokanałowym contentcie, wielojęzyczności poza WPML albo wymaganiach wydajności, których motyw blokowy nie spełni bez dziesięciu warstw cache. Decyzja jest pisemna, z porównaniem kosztu utrzymania. Migracja z Shopify albo Magento do WooCommerce opisana jest na stronie migracji WooCommerce headless tam, gdzie architektura to uzasadnia.

Przygotowanie sklepu pod wiele rynków UE (OSS, waluty, bramki lokalne) opisuje WooCommerce EU readiness. Amsterdam często jest pierwszym rynkiem wdrożenia w Beneluksu, zanim sklep otwiera DE albo FR.

#Bezpieczeństwo sklepu jako lista decyzji

HTTPS z HSTS tam, gdzie infrastruktura to uniesie. Nagłówki ograniczające XSS. 2FA na wp-admin. Minimum kont administratorskich. Zakaz wtyczek nulled. Zakaz edytora plików na produkcji. Rotacja kluczy API Mollie po odejściu freelancera. Test odtworzenia kopii, bo kopia, której nikt nie odtwarzał, jest plikiem. PCI DSS: dane kart nie przechodzą przez serwer sklepu, tokenizacja po stronie bramki.

Przy danych osobowych: umowa powierzenia, lista podprocesorów, procedura naruszenia pod AVG. Dokumentacja hardeningu WordPress jest w WordPress Developer Handbook. Programowanie WooCommerce w Amsterdamie dodaje do niej checklistę iDEAL, pytanie o AP oraz jawny opis rezydencji w EOG.

#Jak zacząć, bez cennika na stronie city

Krótki opis sklepu, stacku, bramek płatności, ERP i tego, czy jest środowisko testowe, wystarczy, żeby zaproponować audyt checkoutu. Kontakt: formularz. W zgłoszeniu przydaje się informacja, czy sklep musi obsługiwać iDEAL i Bancontact, jakie BTW-nummer i integracje magazynowe są w użyciu oraz czy w najbliższych tygodniach jest King’s Day, Black Friday albo freeze kampanii.

Programista WooCommerce w Amsterdamie ma sens, gdy checkout, BTW i PostNL mają działać na produkcji, a nie tylko na demo. Gdy trzeba sklep dopiero zbudować od zera albo przebudować motyw, patrz programista WordPress w Amsterdamie. Gdy sklep już stoi i trzeba go rozwijać przy iDEAL, holenderskim BTW i integracji z Exact, zostajemy przy tym, co ta strona opisuje: hooki zamiast rdzenia, środowisko testowe przed produkcją, QA ścieżki płatności i runbook, który da się pokazać księgowości i compliance bez rekonstruowania historii z pamięci.