Programista WooCommerce w Barcelonie

Sklep WooCommerce w Barcelonie stoi obok landinga kampanijnego pod Mobile World Congress, sklepu modowego w Gràcia z checkoutem Bizum, hurtowni B2B z cenami według ról i katalogu w trzech językach ES/CA/EN. To nie jest powód, żeby Woo udawało ERP ani platformę płatniczą Redsys. To powód, żeby checkout, bramki, IVA, dostawa i integracje magazynowe były napisane tak, jak oczekuje hiszpański dział compliance, magazyn w Poblenou i zespół finansowy, który czyta wytyczne AEPD, a nie tylko wynik Lighthouse na stronie kategorii.

WPPoland realizuje programowanie WooCommerce z polskiego zespołu seniorów dla firm w Barcelonie i w szerszej Katalonii, które mają siedzibę, magazyn albo klientów Hiszpanii. Zakres to checkout, Redsys, Bizum, strefy dostaw, logika podatkowa, 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.

#Programowanie WooCommerce dla sklepów Barcelonie

Barcelona to stolica Katalonii i jeden z najważniejszych ośrodków e-commerce w Europie Południowej. Nie jest Madrytem administracyjnym ani Sewillą turystyczną. Tu liczy się dzielnica 22@ w Poblenou, sklepy od Eixample po Born, marki D2C z własnym fulfilmentem w aglomeracji barcelońskiej oraz sklepy, które muszą obsłużyć rynek hiszpański, kataloński i międzynarodowy z jednej instalacji WooCommerce. Brief od klienta w Barcelonie często brzmi: „mamy Elementor i trzydzieści wtyczek, checkout trwa wieczność, Bizum działa losowo, a po aktualizacji Woo zamówienia wiszą na oczekującym”. To jest problem architektury checkoutu i webhooków, nie problem szablonu z marketplace.

Typowy projekt, który trafia do seniorów Barcelonie, nie brzmi „zróbcie sklep”. Brzmi: odziedziczony Woo z page builderem, Redsys skonfigurowany przez agencję trzy lata temu, magazyn klei statusy ręcznie po Black Friday albo kampanii w tygodniu Mobile World Congress, a dział prawny pyta, czy checkbox zgody w checkout i política de privacidad da się obronić przed AEPD. To jest dług integracyjny, który wychodzi w lutym albo w szczycie sezonu, nie w audycie SEO.

#Checkout, Redsys i Bizum

Sklep kataloński zbiera Bizum, kartę przez Redsys, czasem Apple Pay albo Stripe dla klientów międzynarodowych. Webhooki bramki i status zamówienia muszą przeżyć aktualizację WooCommerce i patch wtyczki płatności. W Barcelonie do Stripe dochodzi Redsys i Bizum - metody, których kupujący oczekują w kasie, nie ciekawostka z ulotki integratora.

Przykład z audytu: zamówienie opłacone przez Bizum, a w panelu WooCommerce wciąż „oczekujące na płatność”, bo callback nie dotarł po patchu wtyczki albo bo środowisko testowe i produkcja miały różne URL callbacków. To nie jest błąd UX. To incydent operacyjny, który w tygodniu Mobile World Congress kosztuje więcej niż w styczniu, bo magazyn wysyła ręcznie albo anuluje zamówienia, które klient już opłacił.

Co wpisujemy w runbook bramki:

WooCommerce Blocks Checkout ma sens, gdy checkout ma być lekki i spójny z motywem blokowym. Klasyczny shortcode checkout zostaje, gdy odziedziczona warstwa pól i integracji jest zbyt kosztowna do migracji przed sezonem. Decyzja trafia do pisemnego kompromisu technicznego, nie do modę na bloki.

Skrypt bramki nie może blokować LCP na stronie checkout. Ładujemy go po interakcji albo z defer, testujemy na stagingu z tym samym CDN co produkcja. Dyrektor operacyjny z biura w 22@ nie akceptuje argumentu „strona produktu jest szybka”, kiedy checkout na mobile wisi trzy sekundy przed polem karty.

#IVA, faktury i dostawa po Katalonii

Hiszpański sklep WooCommerce musi umieć IVA krajowy, stawki na Wyspy Balearskie, Kanary i Ceutę tam gdzie asortyment wchodzi, oraz OSS dla sprzedaży transgranicznej w UE bez ręcznego klejenia stawek w Excelu. Pola NIF/CIF w checkout B2B, numer faktury w eksporcie do ERP i zgodność z wymogami hiszpańskiego fakturowania to decyzje w wtyczce checkoutu i integracji, nie w motywie.

Dostawa w Barcelonie to nie jedna stawka „Hiszpania”. Klienci oczekują Correos Express, SEUR, GLS albo odbioru w punkcie. Kalkulator wysyłki musi liczyć wagę, wymiary i strefy (Katalonia, reszta Hiszpanii, Portugalia, reszta UE) bez trzydziestu ręcznych reguł w panelu, które nikt nie aktualizuje po zmianie cennika przewoźnika. Integracja API przewoźnika dostaje log błędów i test na stagingu z adresem testowym, nie tylko „działa u mnie na localhost”.

Wielojęzyczność ES/CA/EN w sklepie wymaga osobnej decyzji: WPML WooCommerce Multilingual, osobne slugi, hreflang na produktach i checkout, tłumaczenia maili transakcyjnych. Kampania w katalońskim bez hiszpańskiego checkoutu albo odwrotnie kończy się porzuconymi koszykami, których analytics nie wyjaśni bez nagrania sesji.

#Barcelona: 22@, Mobile World Congress i sezon e-commerce

Barcelona nie jest Walencją ani Saragossą. Tu liczy się dzielnica 22@ w Poblenou, Mobile World Congress w Fira Gran Via, równoległe wydarzenie 4YFN oraz ekosystem D2C i designu od Eixample po Born. Te osie ustawiają priorytety techniczne dla sklepu, który ma działać w Barcelonie, a nie tylko nosić to w tytule strony usługowej.

#22@ i sklepy scale-upów

Dzielnica 22@ w Poblenou to barceloński hub technologiczny z setkami firm z sektora tech, mediów i designu. WooCommerce trzyma sklep produktowy, subskrypcję boxa, katalog B2B dla partnerów i checkout, który musi przeżyć skok ruchu po współpracy z influencerem albo po wzmiance w mediach branżowych w oknie MWC. Awaria checkoutu po aktualizacji wtyczki cache albo regresja w tłumaczeniach ES/CA/EN boli w tygodniu kampanii, nie w sierpniu.

Development, który testuje tylko stronę główną kategorii, tego nie widzi. Development z runbookiem z listą bramek, webhooków, ścieżki koszyk → opłacone → mail → magazyn widzi. Barcelona nie wymaga DC w samym mieście. Wymaga sensownej jurysdykcji hostingu w UE, stagingu z tym samym stosem płatności i rollbacku zapisanego przed wdrożeniem.

#Mobile World Congress i zamrożenie wdrożeń

Mobile World Congress w Barcelonie co roku w lutym przyciąga ponad sto tysięcy uczestników, setki startupów i falę mediów. Równolegle 4YFN zbiera founderów pierwszym tygodniu kongresu. W tym oknie marki z Barcelony uruchamiają promocje, landingi produktowe i sklepy z limitowanymi edycjami. Awaria checkoutu w środku tygodnia MWC to utracona sprzedaż i ręczne klejenie zamówień w magazynie, nie ticket do backlogu na marzec.

Runbook developmentu dla klientów Barcelonie ma wpisane zamrożenie wdrożeń produkcyjnych na okno Mobile World Congress i 4YFN, zwykle od tygodnia przed kongresem do tygodnia po jego zakończeniu. Aktualizacje krytyczne bezpieczeństwa przechodzą przez środowisko testowe i okno nocne z pełną regresją Redsys i Bizum. Reszta czeka. Kto robi „drobny patch wtyczki płatności” w poniedziałek otwarcia MWC, uczy się tego na własnej skórze, kiedy callbacki nie docierają pod obciążeniem.

#RODO, AEPD i dane w checkout

Po stronie hiszpańskiej klient pyta o coś innego niż polski zespół domyślnie zakłada: gdzie leżą dane zamówienia, czy serwer jest w Unii Europejskiej, jak długo trzymamy logi płatności, kto jest administratorem danych, czy mamy umowę powierzenia z bramką i z hostem. Te pytania trzeba umieć obsłużyć konfiguracją checkoutu i dokumentacją, nie sloganem o „zgodności z RODO”.

Hiszpania stosuje RODO oraz krajową ustawę organiczną LOPDGDD. Organ nadzorczy to Agencia Española de Protección de Datos (AEPD). Dla WooCommerce w Barcelonie wynika z tego konkretny zakres prac: lista podprocesorów (host, CDN, Redsys, Bizum, poczta transakcyjna, analityka), umowa powierzenia tam gdzie agencja przetwarza dane, procedura naruszenia w 72 godziny, minimalizacja pól w checkout, política de privacidad i cookie policy zgodne z art. 13 RODO.

Development nie zastępuje DPO klienta. Dostarcza konfigurację techniczną, którą właściciel może opisać w dokumentacji. Nikt po stronie agencji nie podpisuje się pod „sklep jest zgodny z RODO, bo macie SSL”. AEPD publikuje wytyczne na aepd.es; runbook projektu powinien być z nimi zgodny co do tego, co agencja dokumentuje, a co zostaje po stronie administratora danych.

Co wpisujemy w checkout i w kod:

• Checkbox zgody marketingowej tam gdzie consent jest wymagany, osobno od regulaminu sklepu i od polityki prywatności.
• Wtyczki consent (Complianz, Cookiebot, Iubenda) konfigurujemy tak, żeby skrypty analityczne i piksel nie ładowały się przed akceptacją. To decyzja w kolejności enqueue, nie ticket po pierwszym pytaniu audytora AEPD.
• Polityka prywatności i regulamin to szablony z polami, nie bloki, które redaktor może usunąć z drzewa produktu.
• Logi callbacków Redsys przechowujemy z retencją uzgodnioną w runbooku, bez pełnych numerów kart w plain text.

Hosting w UE (AWS eu-west-1, OVH, Hetzner, Arsys, Raiola, Scaleway) to odpowiedź na pytanie o jurysdykcję. Origin w Madrycie albo Frankfurt plus CDN z terminałem TLS w UE zwykle wystarcza dla użytkowników Katalonii. Decyzję opisujemy w runbooku, nie zgadujemy w rozmowie sprzedażowej.

#Architektura: hooki, wtyczka checkoutu i motyw

Sklep musi przetrwać aktualizacje WooCommerce. Customizacje idą przez udokumentowane hooki action i filter, plus podział na własną wtyczkę checkoutu i motyw tam gdzie powinno. Modyfikacje plików rdzenia Woo nie wchodzą w grę.

Granica jest prosta i zapisana w runbooku. Motyw umie pokazać produkt i kategorię. Wtyczka checkoutu umie wiedzieć: stawki IVA, mapowanie pól NIF, callback Redsys, eksport CSV do magazynu, reguły B2B. Jeśli po zmianie motywu znika logika Bizum albo ceny według ról, architektura była zła.

Porównanie warstw przy kickoffie:

Headless storefront przez Woo REST ma sens, gdy frontend jest w Astro albo aplikacji mobilnej, a magazyn zamówień zostaje w Woo. To osobny brief z OAuth, rate limiting i synchronizacją stanów. Nie dokładamy headless „bo modne”, jeśli problemem jest wolny checkout na shared hostingu.

#Wydajność checkoutu i Core Web Vitals

Core Web Vitals na stronie produktu nic nie dają, jeśli checkout ma INP powyżej progu albo CLS skacze, gdy ładuje się widget płatności. Dla sklepów Barcelonie budżet wydajności obejmuje checkout, koszyk i stronę produktu z galerią w AVIF.

• LCP: obraz hero produktu w WebP/AVIF, preload tylko na above-the-fold, edge cache dla kategorii bez personalizacji koszyka.
• INP: minimalna hydracja na checkout, debounce na polach kodu pocztowego, brak ciężkiego page buildera na stronie płatności.
• CLS: jawne wymiary obrazów katalogu, rezerwacja miejsca na banner consent, skeleton koszyka mini.

Monitorujemy Lighthouse CI na stagingu i CrUX po wdrożeniu. Regresja checkoutu blokuje deploy. Monitoring tylko z regionu USA kłamie dla kupujących w Katalonii. Punkt pomiaru w UE jest częścią kontraktu operatorskiego.

#Integracje ERP, magazyn i marketplace

Druga powtarzalna integracja w Barcelonie to magazyn albo ERP: Holded, Sage, własny system w 22@, fulfilment zewnętrzny. Zamówienie opłacone przez Bizum musi trafić do magazynu bez ręcznego eksportu CSV o północy. Webhook Woo → magazyn dostaje idempotencję, log błędów i alert, gdy kolejka stoi dłużej niż uzgodniony próg.

Synchronizacja stanów między Woo, marketplace (Amazon ES, Miravia) i POS wymaga rozwiązywania konfliktów i audytu, kto nadpisał stan. Budujemy to w wtyczce integracyjnej, nie w piętnastu snippetach w motywie. Każda integracja ma test end-to-end na stagingu przed produkcją i wpis w runbooku freeze MWC.

#Git, środowisko testowe i QA ścieżek zamówień

Repozytorium trzyma własną wtyczkę checkoutu i motyw sklepu. Gałąź funkcyjna na jedną zmianę: nowa strefa dostawy, poprawka callback Redsys, blok produktu. Pull request ma opis, nagranie checkoutu na mobile i checklistę: Redsys sandbox, Bizum test, mail transakcyjny, eksport magazynu.

Środowisko testowe jest kopią produkcji z zanonimizowanymi danymi klientów. TPV w sandbox, te same wtyczki płatności, ten sam CDN. Regresja ES/CA/EN, regresja zwrotu i regresja „aktualizacja Woo + wtyczka płatności” dzieją się tutaj. Promocja na produkcję jest udokumentowanym krokiem ze ścieżką wycofania. Zespół nie wgrywa „na szybko” jednego pliku PHP przez SFTP w tygodniu kampanii sezonowej.

QA end-to-end na stagingu pokrywa: koszyk gościa, koszyk zalogowany, Bizum, karta przez Redsys, błąd 3DS, anulowanie, zwrot częściowy, mail do klienta, status w panelu, wpis w logu magazynu. Bez tej listy każda aktualizacja jest ruletką.

#Profile projektów Barcelonie: cele techniczne na piśmie

Nie prezentujemy anonimowych case study z okrągłymi liczbami niemożliwymi do zweryfikowania. Opisujemy trzy profile projektów, które powtarzają się na rynku barcelońskim, i cele techniczne uzgadniane przed pierwszą linią kodu.

#Profil 1: marka kosmetyczna D2C w Gràcia

Typowy projekt: sklep wielojęzyczny traci zamówienia w checkout podczas kampanii promocyjnych i sezonu świątecznego.

Zakres pracy:

• WooCommerce Blocks Checkout z Bizum exprés i Redsys.
• Optymalizacja zapytań MySQL i cache obiektowy Redis na sesjach koszyka.
• Testy obciążeniowe checkoutu przed kampanią sezonową na stagingu.

Cele techniczne w umowie: checkout poniżej uzgodnionego czasu na mobile w stagingu przed wdrożeniem, stabilność callbacków pod symulowanym szczytem, monitoring porzuconych koszyków z alertem regresji.

#Profil 2: hurtownia B2B w Zona Franca

Typowy projekt: ceny według ról, minimalne zamówienia, faktura z NIF i integracja z magazynem w aglomeracji.

Zakres pracy:

• Wtyczka checkoutu z polami B2B i eksportem zamówień do ERP.
• Strefy dostaw Correos Express i paletowe stawki SEUR.
• RODO: rejestr podprocesorów i política de privacidad powiązana z checkout.

Cele techniczne w umowie: brak ręcznego eksportu CSV po opłaceniu zamówienia, regresja cen ról po aktualizacji Woo, dokumentacja przepływu danych pod pytania AEPD.

#Profil 3: marka lifestyle z 22@ i ruchem międzynarodowym

Typowy projekt: sklep ES/CA/EN z Stripe dla UE poza Hiszpanią i Redsys dla rynku krajowego, kampania pod Mobile World Congress co roku.

Zakres pracy:

• Dwa TPV z routingiem kraju w checkout.
• Zamrożenie wdrożeń w oknie MWC z runbookiem incydentu.
• Feed produktowy Google Merchant Center z poprawnym IVA w feedzie.

Cele techniczne w umowie: hreflang na produktach, brak deploy checkoutu w oknie freeze bez pisemnej zgody, test callbacków po każdej aktualizacji wtyczki płatności.

#Bezpieczeństwo sklepu i PCI

WooCommerce z Redsys nie zastępuje certyfikacji PCI po stronie merchant ID klienta. Zespół nie pisze, że sklep „spełnia PCI DSS Level 1” bez audytu klienta. WordPress ma dostarczyć: brak numerów kart w logach, HTTPS, nonce na checkout, limitowanie prób płatności, WAF na endpointach wp-login i xmlrpc wyłączony jeśli nieużywany.

Sekretów TPV nie ma w Git. Klucze Redsys idą przez zmienne środowiska. Konta sklepu mają role minimalne: redaktor produktu nie instaluje wtyczek na produkcji. Szerszy audyt bezpieczeństwa opisuje audyt bezpieczeństwa WordPress.

#Pytania, które zadają nam firmy w Barcelonie

Czy możecie przejąć istniejący sklep WooCommerce? Tak. Audyt wyłania krytyczne luki: stary PHP, wtyczki płatności bez łatek, callback Redsys wskazujący na stary URL, brak testu Bizum po ostatniej aktualizacji Woo, magazyn synchronizowany ręcznie. Lista napraw idzie przed większą przebudową checkoutu.

Czy pracujecie z firmami spoza Barcelony? Tak. Znamy kontekst 22@, Mobile World Congress, Redsys, Bizum i AEPD, ale współpracujemy z klientami w całej Hiszpanii i za granicą. Wiele firm w Barcelonie obsługuje magazyn w Katalonii i klientów Madrycie bez osobnego sklepu na każde miasto.

Jak obsługujecie sklepy wielojęzyczne? WPML WooCommerce Multilingual albo osobna strategia slugów i hreflang. Każda wersja językowa dostaje zlokalizowany checkout, maile transakcyjne i reguły IVA tam gdzie rynek tego wymaga. ES/CA/EN to osobna decyzja architektoniczna zapisana przed implementacją.

Co obejmuje bieżące wsparcie? Po zakończeniu budowy sklep może przejść na opiekę techniczną WordPress w Barcelonie: testowane aktualizacje, regresja checkoutu, kopie, monitoring i runbook freeze MWC. Szczegóły na stronie opieki, nie w tym briefie WooCommerce.

Czym różni się współpraca z WPPoland od lokalnej agencji w Barcelonie? Doświadczenie WooCommerce od lat, własne zaplecze techniczne, praca na jasnych założeniach: zakres, etapy i odpowiedzialność opisane przed wdrożeniem. Wycena jest indywidualna i zależy od zakresu, nie z gotowego cennika.

#Powiązane usługi

Jeśli obecna strona firmowa działa i potrzebuje motywu, Gutenberga albo refaktoryzacji przed sklepem, zobacz programistę WordPress w Barcelonie z integracjami Redsys w kontekście całego WordPressa. Pillar bez miasta: programista WordPress. Stała opieka po uruchomieniu sklepu: opieka techniczna WordPress w Barcelonie albo pillar utrzymanie stron WordPress. Pełny zakres Woo bez miasta: programista WooCommerce.

#Rozpocznij swój projekt w Barcelonie

Jeśli chcesz omówić programowanie WooCommerce, wyślij krótki opis obecnej sytuacji: bramki, integracje magazynowe, wersje językowe, ograniczenia compliance i terminy kampanii albo Mobile World Congress. Na tej podstawie sprawdzamy checkout, wskazujemy ryzyka callbacków i proponujemy praktyczny plan działania.

Jeśli planujesz nowy sklep, migrację checkoutu na Blocks albo refaktoryzację Redsys i Bizum przed sezonem, zacznij od spisania celów, ograniczeń i obecnego stanu integracji. Wycena jest indywidualna i zależy od zakresu prac.