Programista WooCommerce w Brukseli

Sklep WooCommerce w Brukseli stoi obok subskrypcji boxa D2C z Ixelles z checkoutem w EUR i dostawą bpost do biura przy Avenue Louise, hurtowni B2B dostawcy z Anderlecht z cenami według ról i fakturą z numerem BCE, sklepu merchu przed eventem branżowym w okolicy Heysel, który w szczycie tygodnia musi przeżyć skok ruchu bez gubienia webhooków Mollie, albo marki z Brussels Digital Hub rozliczanej cyklicznie przez Stripe. To nie jest powód, żeby Woo udawało platformę CRM unii branżowej albo system rezerwacji dla instytucji unijnych. To powód, żeby checkout, bramki Bancontact i Mollie, TVA/BTW, dostawa i integracje magazynowe były napisane tak, jak oczekuje belgijski dział compliance, magazyn w aglomeracji brukselskiej albo zespół prawny, który czyta GDPR i wytyczne APD (Autorité de protection des données / Gegevensbeschermingsautoriteit), a nie tylko wynik Lighthouse na stronie kategorii.

WPPoland realizuje programowanie WooCommerce z polskiego zespołu seniorów dla firm w Brukseli i w szerszej Belgii. Zakres to checkout, Bancontact, Mollie, Stripe, PayPal, strefy dostaw, logika podatkowa TVA/BTW, hooki zamiast modyfikacji rdzenia i QA end-to-end na ścieżkach zamówień. Motyw WordPress, abonament opieki i kontakt są osobnymi tematami, z linkami na końcu.

#Checkout WooCommerce w Brukseli

Bruksela to stolica Belgii, siedziba instytucji europejskich i węzeł Brussels Digital Hub, który koncentruje startupy, agencje i firmy technologiczne w aglomeracji od Etterbeek po Saint-Gilles. Miasto łączy okolice Schuman z uniami branżowymi i kancelariami prawnymi, Avenue Louise z biurami usługowych i MŚP, dzielnicę Ixelles z krótkim cyklem publikacji D2C oraz halę przy Heysel, gdzie eventy branżowe i targi generują skoki ruchu na landingach i sklepach WooCommerce. Sklep w tym układzie często nie jest wizytówką z koszykiem, tylko kanałem sprzedaży gadżetów eventowych, katalogiem B2B dla dystrybutorów, subskrypcją produktów cyfrowych albo sklepem merchu przed kampanią członkowską unii branżowej.

Brief od klienta w Brukseli często brzmi: mamy Elementor i trzydzieści wtyczek, checkout trwa wieczność, Bancontact działa losowo, a po aktualizacji Woo zamówienia wiszą na oczekującym. To jest problem architektury checkoutu i webhooków Mollie, nie problem szablonu z marketplace. Typowy projekt, który trafia do seniorów Brukseli, nie brzmi zróbcie sklep. Brzmi: odziedziczony Woo z page builderem, Mollie skonfigurowany przez agencję trzy lata temu, magazyn klei statusy ręcznie po eventu przy Heysel, a dział prawny pyta, czy checkbox zgody w checkout i polityka prywatności da się obronić przed APD przed publikacją raportu kwartalnego. To jest dług integracyjny, który wychodzi w tygodniu publikacji albo przy deadline rejestracji na konferencję, nie w audycie SEO.

WordPress Meetup Brussels spotyka się regularnie w ekosystemie brukselskim. To nie jest kanał sprzedaży. To sygnał, że lokalna społeczność zna WordPress Coding Standards i widzi różnicę między checkoutem z WooCommerce Blocks a page builderem generującym shortcode’y w treści. Sklepy, które tu stawiamy albo naprawiamy, zwykle łączą dwa rytmy: codzienną sprzedaż B2C z dostawą bpost do aglomeracji brukselskiej, oraz skoki katalogu przed publikacją raportu, kampanią członkowską albo eventem branżowym, gdy magazyn w Belgii albo fulfilment w okolicach Brukseli musi wyjechać paczkami DPD albo GLS, a nie listem poleconym bpost.

Prace trzymają się WooCommerce. Customizacje idą przez hooki action i filter oraz własną wtyczkę, nigdy przez edycję plików rdzenia. Granica między rdzeniem Woo, kodem wtyczki i motywem zapada na audycie i trafia do runbooka.

#Płatności na checkoucie w Belgii w 2026

Belgijski koszyk zaczyna się od waluty. Sklep w Brukseli sprzedaje w EUR. Bancontact to metoda płatności, którą większość konsumentów Belgii wybiera jako pierwszą: redirect do banku (KBC, Belfius, ING Belgia, BNP Paribas Fortis), potwierdzenie w aplikacji mobilnej, powrót do sklepu ze statusem opłacone. WooCommerce obsługuje Bancontact przez Mollie, Stripe, MultiSafepay albo Adyen. Integracja wymaga poprawnej obsługi webhooków, idempotencji po stronie sklepu i testów na sandboxie przed produkcją.

Mollie to bramka, którą kupujący i księgowość w Brukseli znają z terminala w sklepie stacjonowym i z faktur miesięcznych. Stripe pokrywa większość scenariuszy międzynarodowych: karta z 3D Secure, Apple Pay, Google Pay i portfel PayPal. Klient z aglomeracji brukselskiej oczekuje, że kwota na checkoucie, w mailu potwierdzającym i na wyciągu bankowym będzie w euro, z jawną stawką TVA/BTW.

Dla każdej bramki w runbooku zostaje: obsługiwane flow (jednorazowe, cykliczne, capture, zwrot pełny, zwrot częściowy), adres webhooka, lista zdarzeń które zmieniają status, matryca kont sandbox i historia idempotencji. Mollie zgłasza payment.paid i refund.created osobnymi zdarzeniami. Stripe wymaga osobnej decyzji, czy capture idzie od razu, czy po nadaniu przesyłki - przy dużym gabarycie albo towarze personalizowanym druga opcja chroni przed pobraniem pieniędzy za SKU, którego nie ma w magazynie.

Kolejność metod na checkoucie ustawiamy pod belgijskie nawyki: Bancontact na górze, PayPal i karta przez Mollie albo Stripe niżej, Apple Pay tam gdzie Safari dominuje w ruchu mobilnym z kampanii eventowej, przelew bankowy (overschrijving) tylko w ścieżce B2B z jasnym komunikatem o czasie księgowania. Domyślny szablon Woo z kartą na górze i bez Bancontact pracuje wbrew nawykom rynku belgijskiego, w tym kupującego w Brukseli, który woli redirect do banku przy koszyku powyżej kilkuset euro.

Sklepy sprzedające do innych krajów UE muszą osobno rozwiązać VAT OSS albo lokalną rejestrację w kraju docelowym. Woo sam z siebie nie jest modułem OSS. Albo wtyczka podatkowa liczy stawki destynacji, albo ERP jest źródłem podatku, a Woo tylko zbiera adres i kwoty. Mieszanie obu źródeł to najczęstszy rozjazd w deklaracji TVA/BTW, który wychodzi dopiero na fakturze, a nie w koszyku.

#Strefy dostaw: bpost, DPD i GLS

Krajowa dostawa z Belgii w 2026 to przede wszystkim bpost (Pacco, bpack 24h Pro), DPD i GLS. bpost obsługuje paczki do standardowego gabarytu w aglomeracji brukselskiej. DPD daje kuriera do drzwi i sieć punktów ParcelShop w Brukseli: centrum miasta, Anderlecht, Woluwe, Zaventem, Molenbeek. Strefy Woo rozdzielamy nie tylko na Belgię / UE / reszta świata, ale na wagę i wymiar: do progu listu, do progu paczki standardowej, powyżej kurier paletowy dla gabarytów eventowych albo materiałów B2B.

Integracja z kurierem wymaga mapowania produktów Woo na usługi przewoźnika: bpost Pacco, DPD Classic, GLS Business Parcel. Wtyczka kuriera nie dodaje osobnej metody do listy stref Woo. Przypina się ją do istniejącej stawki ryczałtowej albo darmowej dostawy, a potem mapuje produkty w ustawieniach API. Ręczne klejenie etykiet w portalu bpost przy liczbie zamówień po eventu przy Heysel nie skaluje się.

Etykieta i numer śledzenia wracają do zamówienia Woo i do maila klienta. Generowanie etykiety po payment_complete zdejmujemy do Action Scheduler (as_enqueue_async_action), żeby handler webhooka oddał 200 zanim API kuriera policzy routing. Lokalny odbiór w aglomeracji (magazyn w Anderlecht, punkt przy Gare du Midi) ma osobną metodę z jasnym adresem punktu.

#TVA/BTW i pole BCE

Stawki TVA/BTW w Belgii w 2026: standardowa 21 procent, obniżona 6 procent (np. część produktów żywnościowych i książek), pośrednia 12 procent na wybrane kategorie. Koszyk mieszany jest codziennością przy sklepie B2B dostawcy z okolic Anderlecht albo sklepie D2C, który sprzedaje katalog eventowy obok gadżetu. Woo musi liczyć podatek per pozycja, a nie weź najwyższą stawkę koszyka. Błąd w klasie podatkowej produktu wychodzi dopiero na fakturze TVA/BTW.

B2B wewnątrz Belgii z ważnym numerem BCE/KBO (TVA / BTW) idzie jako transakcja z odwrotnym obciążeniem albo z zerową stawką tam, gdy przepisy na to pozwalają, o ile numer przejdzie walidację VIES i sklep zapisuje dowód sprawdzenia przy zamówieniu. Pole BCE na checkoucie, walidacja i przełączenie klasy podatkowej to nie ozdoba formularza. Przy płatności overschrijving B2B to samo pole decyduje, czy faktura w ogóle ma szansę przejść u księgowości w Brukseli.

Granicę co liczy podatek i wystawia dokument zapisujemy w runbooku: WooCommerce Tax, osobny silnik faktur (Yuki, Exact Online, Billit, własna integracja), albo system księgowy klienta. Jedno źródło numeracji. Dwa źródła dają podwójne numery albo dziury, a audyt podatkowy tego nie wybacza.

#Webhooki, rezerwacja stanu i HPOS

Najczęstsza wada sklepów, które wracają do naprawy w Brukseli, nie leży w wyglądzie checkoutu. Leży w tym, co dzieje się po kliknięciu Betaal met Bancontact albo Plaats bestelling. Sklep z magazynem w Belgii, który sprzedaje równolegle przez własne Woo i przez marketplace, płaci za ten błąd dwa razy: raz zamówieniem w limbo, drugi raz nadsprzedażą SKU, który był już zarezerwowany w drugim kanale.

#Status zamówienia ustala serwer, nie powrót klienta

Status zamówienia ustala powiadomienie serwer do serwera. Powrót klienta na stronę podziękowania nie jest źródłem prawdy. Endpoint order-received to zdarzenie przeglądarki. Przeglądarka jest zawodna: po autoryzacji Bancontact klient zamyka kartę w tramwaju między Schuman a Gare Centrale, traci sieć w parkingowym domu przy lotnisku, wraca z cache. Hook woocommerce_thankyou służy do wyświetlenia treści. Nie zmienia statusu płatności.

O pieniądzach decyduje callback bramki. W Woo odbiera go własny adres zwrotny z parametrem wc-api, czyli akcja z rodziny woocommerce_api_ rejestrowana przez wtyczkę bramki. Handler po weryfikacji sygnatury wywołuje payment_complete na obiekcie zamówienia i przenosi je z pending do processing. Sygnaturę sprawdzamy na surowym ciele żądania ze strumienia php://input, zanim cokolwiek zostanie sparsowane. Cięższą pracę po weryfikacji - synchronizację magazynu, wystawienie faktury, nadanie bpost albo DPD - zdejmujemy do Action Scheduler, żeby odpowiedź 200 wracała szybko i Mollie albo Stripe nie zaczęły ponawiać.

Powtórzony sygnał z bramki jest normą, nie awarią. Identyfikator zdarzenia zapisujemy w meta zamówienia i sprawdzamy przed przetworzeniem. Zamówienie już opłacone nie zmienia statusu drugi raz. Dostaje notatkę o zignorowanym duplikacie.

Płatność odrzucona i zwrot częściowy to dwie osobne ścieżki. Odrzucenie ustawia status failed, nie cancelled, bo zamówienie ma nadal dać się opłacić: klient dostaje link z get_checkout_payment_url. Zwrot częściowy idzie przez wc_create_refund z listą pozycji i kwot oraz z flagą zwrotu na bramce. Zamówienie zostaje w processing albo completed, a zwróconą kwotę czyta się z get_total_refunded, nie ze statusu.

#Rezerwacja magazynu i sprzedaż wielokanałowa

Stan 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 wchodzi w Bancontact na ostatnią sztukę limitowanego SKU z kolekcji przed eventem branżowym i oboje dostają potwierdzenie.

Przy sprzedaży wielokanałowej rezerwacja Woo nie wie nic o Bol.com, Amazon albo innym kanale. Źródłem prawdy zostaje wspólna pula w ERP albo w warstwie fulfilment, a Woo trzyma stan przez synchronizację. Hold stock przy płatności overschrijving B2B ustawia się dłużej niż przy Bancontact: przelew z banku potrafi iść do następnego dnia roboczego.

#Tabele wp_wc_orders i tryb zgodności

High-Performance Order Storage jest domyślny dla nowych instalacji od WooCommerce 8.2. Zamówienia żyją wtedy w wp_wc_orders, wp_wc_order_addresses, wp_wc_order_operational_data i wp_wc_orders_meta, a nie jako wpisy shop_order w wp_posts. Sklepy postawione wcześniej przełączają się świadomie: najpierw tryb zgodności, potem HPOS jako magazyn autorytatywny, na końcu wyłączenie dual-write gdy raporty i wtyczki przestaną się rozjeżdżać.

Diagnostyka i raporty idą przez wc_get_orders oraz OrderUtil, nie przez SQL w wp_posts. Wtyczka, która w 2026 nadal szuka zamówień wyłącznie w postmeta, na HPOS pokazuje puste listy i gubi zwroty. Oficjalne Mollie, Stripe, PayPal, bpost i DPD są na HPOS od dawna. Problemem są stare konektory magazynowe i autorskie crony.

#GDPR, APD i formularze w belgijskim kontekście

Belgia stosuje rozporządzenie UE 2016/679 (GDPR) wraz z krajową implementacją w ustawie z 30 lipca 2018 r. o ochronie osób fizycznych w związku z przetwarzaniem danych osobowych. Organ nadzorczy to APD (Autorité de protection des données po francusku, Gegevensbeschermingsautoriteit po niderlandzku). Dla sklepu WooCommerce w Brukseli to nie jest abstrakcyjny paragraf prawny. To decyzje w formularzach, w wtyczkach consent, w polityce prywatności i w logach audytowych.

Co wpisujemy w brief i w kod:

• Formularze zbierające dane osobowe (konto klienta, newsletter, zapytania B2B, checkout z zapisem do konta) dostają jawną podstawę prawną, checkbox zgody tam, gdzie consent jest wymagany, i minimalizację pól. Pola, których nie potrzebujesz do celu formularza, nie istnieją.
• Wtyczki consent (Cookiebot, Complianz, Didomi, popularne w Belgii) konfigurujemy tak, żeby skrypty marketingowe nie ładowały się przed akceptacją. Wytyczne APD wymagają świadomej zgody przed nieistotnymi plikami cookie. To jest decyzja w motywie i w kolejności enqueue, nie ticket opieki po pierwszym raporcie organu nadzorczego.
• Polityka prywatności i cookie policy są szablonami z polami, nie blokami, które redaktor może usunąć z drzewa. W Brukseli te strony są elementem compliance, nie stopką marketingową.
• Integracje z CRM (HubSpot, Salesforce, Pipedrive) dostają dokumentację przepływu danych: co trafia do systemu zewnętrznego, jak długo, kto jest administratorem. Umowy powierzenia przetwarzania to decyzja klienta, ale konfiguracja Woo musi umożliwiać realizację tej decyzji.
• Logi audytowe dla formularzy i zmian w panelu admina pomagają przy incydentach. Jeśli ktoś pyta kto zmienił ustawienia formularza checkout w piątek przed publikacją raportu, odpowiedź nie może być nie wiemy.

Zespół nie obiecuje zgodności z GDPR bez właściciela procesu po stronie klienta. Nie składa raportu do APD za klienta. Obiecuje konfigurację techniczną, którą właściciel może opisać w dokumentacji i włożyć do zgłoszenia naruszenia w 72 godziny, gdy procedura tego wymaga. APD publikuje wytyczne i narzędzia audytowe na autoriteprotectiondonnees.be; runbook checkoutu powinien być z nimi zgodny co do tego, co agencja dokumentuje, a co zostaje po stronie administratora danych.

#Hosting w UE

Dane osobowe pod GDPR ciągną pytanie: w której jurysdykcji stoi serwer. Combell w Belgii, OVH we Francji, Hetzner w Niemczech, AWS w Frankfurtzie (eu-central-1) to różne odpowiedzi dla compliance officer, ale wszystkie mieszczą się w UE. Ashburn albo Hillsboro to Stany i zwykle veto bez Standard Contractual Clauses albo innej podstawy transferu.

Pytanie czy hosting jest w Brukseli wraca rzadziej niż czy w UE. Odpowiedź operacyjna jest dwuczęściowa. Jurysdykcja: UE, kopia nie wyjeżdża nocą na bucket w regionie US bez uzgodnienia. Latencja: origin w Belgii albo Frankfurt plus CDN z terminałem TLS w UE zwykle wystarcza dla użytkowników Belgii i w Europie Środkowej. Bruksela ma centra danych w aglomeracji, ale origin WordPressa nadal często stoi u dostawcy z regionem frankfurckim albo paryskim. To nie jest wada. To jest jawna decyzja rezydencji, którą trzeba opisać w runbooku.

#Zwroty i prawo konsumenckie jako operacje sklepu

Poniższe akapity opisują skutki w sklepie. Nie są poradą prawną. Teksty terms and conditions, privacy policy i polityki zwrotów zatwierdza kancelaria albo odpowiedzialny w firmie. Zadaniem Woo jest spiąć ten tekst z koszykiem, z przyciskiem, z mailem i z magazynem.

Konsument w Belgii ma prawo odstąpić od umowy zawartej na odległość w ciągu 14 dni na podstawie belgijskiego prawa konsumenckiego (Wetboek van economisch recht, Boek VI). Termin zaczyna biec, gdy klient otrzymał towar. Dla magazynu w aglomeracji brukselskiej to nie ciekawostka prawna. To SKU, którego nie wolno sprzedać drugi raz, bo może wrócić za trzy kwartały.

Ścieżka operacyjna, którą budujemy:

1. Klient składa zwrot z numerem zamówienia albo danymi, które pozwalają je znaleźć w wp_wc_orders.
2. Sklep ustawia status RMA, wysyła potwierdzenie i etykietę zwrotną bpost albo instrukcję nadania DPD.
3. Przyjęcie na magazynie zdejmuje blokadę SKU i dopiero wtedy idzie wc_create_refund na Mollie, Stripe, PayPal albo przelew zwrotny przy overschrijving.
4. Częściowy zwrot (jedna pozycja z trzech) nie zamyka całego zamówienia i nie zwraca kosztów wysyłki w ciemno; kwoty bierze się z pozycji, nie z ręcznego zwróć wszystko.
5. Towar wyłączony ze zwrotu (higiena, personalizacja, treść cyfrowa po rozpoczęciu) musi mieć tę informację przy SKU przed zakupem.

Sezon po świętach i po eventach branżowych to test tej ścieżki. Sklep, który w tygodniu publikacji ręcznie klika zwroty w panelu Mollie, a stany poprawia w Excelu, rozjeżdża raport TVA/BTW i nadsprzedaje wracający towar.

#Katalog i checkout pod kalendarz publikacji raportu i eventów przy Heysel

Publikacja raportu kwartalnego, rejestracja na event branżowy w okolicy Heysel i Black Friday to trzy kalendarzowe punkty, których nie da się zignorować w briefie od klienta w Brukseli. W tych oknach ruch na stronie rośnie wielokrotnie, newslettery idą w setkach tysięcy, a każda zmiana na produkcji jest ryzykiem. Dlatego w runbooku zapisujemy freeze wdrożeń: w tygodniu publikacji raportu nie idą aktualizacje wtyczek, nie idą nowe bloki, nie idą zmiany w motywie. środowisko testowe dostaje zmiany, produkcja czeka do kilku dni po szczycie.

Katalog, który przez jedenaście miesięcy ma osiemset pozycji, przed sezonem dostaje warstwę limitowanych zestawów, cen obowiązujących do wyczerpania zapasu i wariantów, których nie ma w stałej ofercie. Woo musi to udźwignąć bez zgonu strony kategorii.

Nowa architektura checkoutu, przełączenie HPOS albo zmiana mapy stref bpost i DPD nie wchodzi na produkcję w oknie sezonowym. Tydzień przed publikacją raportu produkcja nie dostaje drobnej aktualizacji SEO. Drobna aktualizacja SEO w piątek przed szczytem potrafi nadpisać robots, wyciąć landing kolekcji z indeksu albo zepsuć cache strony promocyjnej.

Warianty trzymamy jako prawdziwe variation z własnym SKU, wagą i klasą podatkową, nie jako pole tekstowe wpisz kolor. Duża macierz (rozmiar × kolor × materiał przy częściach B2B) dostaje własne zapytania i cache fragmentów.

Preorder przed premierą linii produktowej: SKU jest widoczny, płatność schodzi, ale fulfillment stoi aż do daty. Status on-hold albo własny status warte na magazyn musi blokować etykietę kuriera. Inaczej wtyczka bpost nada pustą paczkę pod punkt Pacco przy stacji.

Ceny netto / brutto na checkoucie B2B (netto plus TVA/BTW) i B2C (brutto) to dwa szablony, nie przełącznik CSS. Kupujący z numerem BCE w Brukseli oczekuje netto. Konsument z aglomeracji oczekuje brutto.

#Bruksela jako kontekst rynkowy, nie jako ozdobnik

Brussels Digital Hub to nie tylko nazwa w stopce. To dzisiaj dziesiątki startupów, agencji kreatywnych i firm SaaS w aglomeracji od Etterbeek po Saint-Gilles. Sklepy merchu, subskrypcje boxów D2C i platformy B2B dla dystrybutorów często startują na WooCommerce, bo szybko wstają, a potem utykają na checkout i compliance. Awaria checkoutu albo wyciek logów z wp-admin to nie problem marketingu. To problem compliance i często temat dla prawnika przed APD.

Okolice Schuman, Berlaymont i European Quarter to drugi filar briefów z Brukseli. Unie branżowe, kancelarie prawne, firmy doradcze i think tanki muszą obsługiwać publikacje w FR i NL (czasem EN i DE), formularze zgłoszeniowe na konferencje i treści regulacyjne z datą wejścia w życie. Sklep merchu eventowego albo portal członkowski z checkoutem musi wytrzymać deadline o 23:59 w piątek, nie produkować incydentu operacyjnego w poniedziałek rano.

Avenue Louise, Place du Châtelain i okolice Flagey to trzeci filar. Biura firm usługowych, agencje kreatywne i MŚP z krótszym cyklem publikacji. Mają mniejszy budżet na infrastrukturę niż korporacja przy instytucjach, ale to samo ryzyko: zhakowana strona albo formularz wysyłający dane bez podstawy prawnej psuje wizerunek szybciej niż wolny LCP. Belgia wymaga numeru BCE/KBO w stopce i często dwujęzycznej treści FR/NL. Checkout, który testuje tylko wersję francuską, nie widzi regresji w wersji niderlandzkiej.

Eventy przy Heysel i Brussels Expo to czwarty filar. Producenci merchu, wyposażenia eventowego i materiałów branżowych publikują katalogi produktów, konfiguratory materiałów, zapisy na spotkania w stoisku i landingi pod konkretną edycję targów. Skoki ruchu w tygodniu eventu to realny profil awarii, który wymaga cache, CDN i stagingu z rollbackiem zapisanym przed wdrożeniem.

Typowy brief, który trafia do seniorów Brukseli, nie brzmi zróbcie ładny sklep. Brzmi: odziedziczony Woo z trzydziestoma wtyczkami, checkout który gubi webhook Mollie, magazyn w Belgii synchronizowany ręcznie z Excela, księgowość czeka na eksport do Exact Online, a za tydzień startuje publikacja raportu kwartalnego. To jest problem checkoutu, webhooków i HPOS, nie problem szablonu z marketplace.

#Subskrypcje, B2B i WooCommerce Blocks

WooCommerce Subscriptions w Brukseli spotykamy przy boxach D2C, subskrypcjach produktów cyfrowych albo abonamentach B2B z rozliczeniem cyklicznym przez Stripe. Subskrypcja wymaga osobnego runbooku: retry płatności, grace period, anulowanie, upgrade planu, synchronizacja z CRM. Webhook invoice.payment_failed od Stripe musi trafić do Woo i zmienić status subskrypcji, nie tylko wysłać maila.

B2B w Brukseli to ceny według ról, minimalne wielkości zamówień, procesy zapytań ofertowych i dedykowane portale do zarządzania kontami klientów biznesowych. WooCommerce B2B albo własna warstwa ról musi współgrać z numerem BCE i płatnością overschrijving. Portal B2B, który pokazuje ceny netto bez walidacji roli, to wyciek cennika hurtowego na front publiczny.

WooCommerce Blocks Checkout ma sens, gdy checkout ma być lekki i nie ciągnąć całego page buildera. Bloki checkoutu renderują się serwerowo tam, gdzie to możliwe. Skrypty Mollie, Stripe i bpost Location Finder ładujemy wtedy, gdy checkout jest na ekranie, z preconnect do ich domen, nie w stopce każdej strony kategorii.

#Wydajność koszyka i checkoutu

Checkout jest dynamiczny. Pełny page cache na cart i checkout serwuje cudzy koszyk albo pusty fragment mini-cart. Warstwa cache (Redis, Cloudflare) omija te ścieżki albo stosuje segmentację. Fragmenty mini-cart liczymy osobno.

Obrazy katalogu idą w AVIF / WebP z srcset. Kampanie eventowe generują ciężkie JPEG ze stoiska; bez przetwarzania LCP na karcie produktu spada, zanim kupujący zobaczy przycisk Bancontact. Query Monitor na stagingu pokazuje, czy wtyczka kuriera i bramka nie dokładają po N zapytań na każdy request koszyka.

Pomiar: Lighthouse i dane terenowe na URL produktu, kategorii i checkoutu, przed i po. Publikacja raportu albo event przy Heysel to test infrastruktury, nie średnia z kwartału. Monitoring z jednego regionu USA kłamie, gdy goście stoją w kolejce przy stoisku w centrum Brukseli. Punkt pomiaru w UE jest częścią kryteriów odbioru.

Core Web Vitals są czynnikiem rankingowym Google i jednocześnie czynnikiem konwersji na stronie, która zbiera zamówienia w szczycie kampanii. Nie obiecujemy konkretnej delty procentowej przed audytem, bo skala poprawy zależy od stanu wejściowego konkretnej instalacji. Budżety wydajnościowe ustalamy na starcie projektu i weryfikujemy je na danych terenowych z raportu CrUX, nie tylko w pomiarze laboratoryjnym.

#Zakres prac, QA i przekazanie

Audyt na wejściu obejmuje: taksonomię i klasy podatkowe TVA/BTW, kolejność metod płatności Bancontact, Mollie i Stripe, strefy bpost i DPD, HPOS i listę wtyczek czytających zamówienia, webhooki, hold stock, ścieżkę zwrotu, eksport do Exact Online albo systemu księgowego, baseline Lighthouse, kalendarz publikacji raportu i eventów przy Heysel w harmonogramie wydań, konfigurację GDPR, cookie consent pod APD. Na tym etapie zapada, co jest źródłem stanu, podatku i numeru dokumentu.

Implementacja idzie gałęziami funkcyjnymi. Każda bramka ma scenariusz sandbox: Mollie test mode, Stripe test mode, PayPal sandbox, Apple Pay w środowisku testowym. bpost i DPD mają środowiska testowe etykiet. QA kończy się zamówieniem, które przechodzi: koszyk mieszany ze stawkami TVA/BTW, punkt bpost Pacco, webhook, notatka w zamówieniu, etykieta, mail, a potem zwrot częściowy na tę samą bramkę.

Przekazanie to runbook bramek, mapa stref, opis zwrotu po stronie sklepu, instrukcja eksportu księgowego i zapis decyzji HPOS. Wycena jest indywidualna i na piśmie przed startem. Zmiany zakresu omawiamy z konsekwencją dla terminu. Nie publikujemy cennika SKU na tej stronie.

#Kiedy ta strona, a kiedy opieka albo programista WordPress

Ta strona zostaje przy sklepie: katalog, checkout, płatność, dostawa, stan, dokument, zwrot. Motyw bloga, Gutenberg, intranet albo strona korporacyjna centrali przy Brussels Digital Hub nie są tutaj tematem - to programista WordPress w Brukseli. Monitoring, aktualizacje rdzenia i kopie zapasowe bez przebudowy checkoutu to opieka techniczna WordPress w Brukseli. Szerszy opis utrzymania bez miasta: utrzymanie stron WordPress. Wspólny filar e-commerce: programista WooCommerce.

Brussels Digital Hub, okolice Schuman i Avenue Louise tłumaczą, skąd biorą się sklepy B2B z numerem BCE i płatnością overschrijving. Nie tłumaczą, czemu webhook Mollie bez idempotencji zostawia zamówienie w pending po publikacji raportu.

#Rozpocznij projekt sklepu WooCommerce w Brukseli

Do kontaktu wystarczy krótki opis: czy sklep już stoi, jakie bramki są włączone (Bancontact, Mollie, Stripe, PayPal), skąd leci dostawa (bpost, DPD, odbiór w aglomeracji brukselskiej), czy HPOS jest włączony, jaki jest magazyn (Bruksela, 3PL, centrala w regionie), czy księgowość czeka na eksport do Exact Online, czy cookie consent blokuje tagi przed zgodą, i które daty publikacji raportu albo eventów przy Heysel blokują wydanie. Na tej podstawie widać, czy potrzebna jest przebudowa checkoutu, czy zestawienie webhooków i stanów.

WPPoland pracuje przy WooCommerce od strony zamówienia, nie od strony slajdu. Bruksela dostaje ten sam rygor inżynierski co każdy inny sklep, tylko ze stackiem, którego kupujący w Belgii naprawdę używa, i z kalendarzem publikacji raportu oraz eventów branżowych wpisanym w harmonogram wydań.