Programista WooCommerce w Antwerpii

Sklep WooCommerce w Antwerpii stoi obok marki fashion z Meir z checkoutem w EUR i dostawą bpost do klienta w Flandrii, hurtowni B2B dostawcy części z okolic portu Antwerp-Bruges z cenami według ról i fakturą z BTW-nummer, sklepu D2C z Eilandje rozliczanego cyklicznie przez Stripe, albo merchu przed otwarciem sezonu fashion, który w piątek przed premierą kolekcji musi przeżyć skok ruchu bez gubienia webhooków Mollie. To nie jest powód, żeby Woo udawało system TMS portowy albo platformę rezerwacji diamentów. To powód, żeby checkout, bramki Bancontact i Mollie, TVA/BTW, dostawa i integracje magazynowe były napisane tak, jak oczekuje flamandzki dział compliance, magazyn w aglomeracji antwerpskiej albo zespół prawny, który czyta GDPR i wytyczne belgijskiej 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 Antwerpii i w szerszej Flandrii. 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 Antwerpii

Antwerpia nie jest Brukselą i nie powinna brzmieć jak Bruksela w copy. Stolica Belgii ma inny kalendarz, inny profil klienta i inny ekosystem vendorów. Antwerpia jest drugim co do wielkości miastem Belgii, europejskim hubem logistycznym z portem Antwerp-Bruges, centrum fashion na Meir i w okolicach ModeMuseum oraz ośrodkiem Antwerp Digital Hub koncentrującym startupy, agencje i firmy technologiczne od Eilandje po Berchem. Sklep WooCommerce w tym układzie często nie jest wizytówką z koszykiem, tylko kanałem sprzedaży produktów D2C, katalogiem B2B dla dystrybutorów z portu, subskrypcją boxa regionalnego albo sklepem merchu przed otwarciem sezonu fashion.

Brief od klienta w Antwerpii 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 Antwerpii, nie brzmi zróbcie sklep. Brzmi: odziedziczony Woo z page builderem, Mollie skonfigurowany przez agencję trzy lata temu, magazyn klei statusy ręcznie po sezonie fashion, a dział prawny pyta, czy checkbox zgody w checkout i polityka prywatności da się obronić przed APD. To jest dług integracyjny, który wychodzi w tygodniu otwarcia sezonu albo w listopadzie przy Black Friday, nie w audycie SEO.

Antwerp Digital Hub to ekosystem, w którym Woo trzyma sklep produktu, dokumentację, strefę inwestorów albo portal partnerski B2B. Skok ruchu po ogłoszeniu partnerstwa albo po wystąpieniu na konferencji branżowej w okolicy Eilandje to realny profil awarii. Sklep bez stagingu, bez rollbacku i bez freeze w kalendarzu produktowym kończy się paniczną aktualizacją na żywo, bo to tylko patch bezpieczeństwa.

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 Antwerpii 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 Antwerpii znają z terminala w sklepie stacjonarnym na Meir 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 antwerpskiej 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 palecie części przemysłowych z portu 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 fashion, 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 Antwerpii, 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, GLS i odbiór w Antwerpii

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 antwerpskiej. DPD daje kuriera do drzwi i sieć punktów ParcelShop w Antwerpii: centrum miasta, Berchem, Wilrijk, Hoboken. 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 części przemysłowych albo materiałów logistycznych z portu.

Integracja z kurierem wymaga mapowania produktów Woo na usługi przewoźnika: bpost Pacco, DPD Classic, GLS BusinessParcel. 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 otwarciu sezonu fashion 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 okolicach portu, punkt w centrum Antwerpii) ma osobną metodę z jasnym adresem punktu.

#TVA/BTW i pole BTW-nummer

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 części z portu albo sklepie D2C fashion, który sprzedaje kolekcję sezonową 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 BTW-nummer (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 BTW-nummer 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 Antwerpii.

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 Antwerpii, 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 Flandrii, 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 Groenplaats a Meir, traci sieć w parkingowym domu przy dworcu Antwerpia-Centraal, 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 otwarciem sezonu fashion 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 Antwerpii 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 Antwerpii 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, w tym hosting w jurysdykcji UE tam, gdzie klient tego wymaga.
• 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 otwarciem sezonu fashion, 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) albo Paryżu (eu-west-3) 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 Antwerpii 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 Flandrii i w Europie Środkowej. Antwerpia 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 Flandrii to nie ciekawostka prawna. To SKU fashion, 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 otwarciu sezonu fashion to test tej ścieżki. Sklep, który 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 sezonu fashion i Black Friday

Otwarcie sezonu fashion w Antwerpii (Meir, Nationalestraat, okolice ModeMuseum) i Black Friday to dwa kalendarzowe punkty, których nie da się zignorować w briefie. 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 otwarcia sezonu 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 otwarciem sezonu 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 z portu) 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 dworcu.

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

#Antwerpia jako kontekst rynkowy, nie jako ozdobnik

Port Antwerp-Bruges i okolice Eilandje to inny profil briefu niż fashion na Meir. Strony operatorów logistycznych, firm spedycyjnych i dostawców usług portowych muszą obsługiwać kalkulatory wysyłki, formularze zgłoszeniowe z załącznikami i treści regulacyjne z datą wejścia w życie. WooCommerce w tym środowisku nie zastępuje systemu TMS, ale sklep B2B z katalogiem części, specyfikacjami technicznymi i checkoutem overschrijving musi wytrzymać deadline o 23:59 w piątek, nie produkować incydentu operacyjnego w poniedziałek rano.

Meir, Nationalestraat, okolice ModeMuseum: tu siedzą marki fashion, butiki i MŚP z krótszym cyklem publikacji. Mają mniejszy budżet na infrastrukturę niż korporacja portowa, ale to samo ryzyko: martwy checkout Bancontact albo formularz wysyłający dane bez podstawy prawnej psuje wizerunek szybciej niż wolny LCP. Belgia wymaga numeru BCE/KBO w stopce. W Flandrii dominuje niderlandzki, więc wersja NL jest często pierwsza, nie dodatek do francuskiego. Sklep, który testuje tylko wersję angielską, nie widzi regresji w wersji niderlandzkiej.

Antwerp Digital Hub to trzeci filar. Startup, SaaS i e-commerce spotykają się w aglomeracji od Eilandje po Berchem. Sklepy D2C z tego ekosystemu muszą obsłużyć TVA/BTW, chłodnię w łańcuchu dostaw i zwroty towaru higienicznego z jasnym komunikatem przed zakupem. Sklep, który obiecuje dostawę w 48 godzin bez mapowania stref bpost, generuje reklamacje, nie sprzedaż.

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

#Subskrypcje, B2B i WooCommerce Blocks

WooCommerce Subscriptions w Antwerpii 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 Antwerpii 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 BTW-nummer 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 fashion idą w AVIF / WebP z srcset. Kampanie sezonowe 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. Otwarcie sezonu fashion albo Black Friday to test infrastruktury, nie średnia z kwartału. Monitoring z jednego regionu USA kłamie, gdy goście stoją w kolejce przy sklepie na Meir. 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, DPD i GLS, 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 sezonu fashion i Black Friday 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 w Antwerp Digital Hub nie są tutaj tematem - to programista WordPress w Antwerpii. Monitoring, aktualizacje rdzenia i kopie zapasowe bez przebudowy checkoutu to opieka techniczna WordPress w Antwerpii. Szerszy opis utrzymania bez miasta: utrzymanie stron WordPress. Wspólny filar e-commerce: programista WooCommerce.

Port Antwerp-Bruges, Meir i Antwerp Digital Hub tłumaczą, skąd biorą się sklepy B2B z BTW-nummer i płatnością overschrijving. Nie tłumaczą, czemu webhook Mollie bez idempotencji zostawia zamówienie w pending po otwarciu sezonu fashion.

#Rodzeństwo w Belgii i w Beneluksu

Ten sam model checkoutu działa w innych belgijskich miastach i w sąsiednich stolicach Beneluksu, z tym samym runbookiem i innym kontekstem lokalnym:

• Programista WooCommerce w Brukseli
• Programista WooCommerce w Gandawie
• Programista WooCommerce w Amsterdamie

#Rozpocznij projekt sklepu WooCommerce w Antwerpii

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, GLS, odbiór w Flandrii), czy HPOS jest włączony, jaki jest magazyn (Antwerpia, 3PL, centrala w regionie), czy księgowość czeka na eksport do Exact Online, czy cookie consent blokuje tagi przed zgodą, i które daty sezonu fashion albo Black Friday 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. Antwerpia 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 sezonu fashion oraz Black Friday wpisanym w harmonogram wydań.