Programista WooCommerce w Madrycie

Sklep WooCommerce w Madrycie stoi obok hurtowni materiałów technicznych w Vallecas z katalogiem kilku tysięcy pozycji, producenta, który otwiera kanał digital dla dotychczasowych klientów handlowych, i importera obsługującego zarówno peninsulę, jak i rynki Ameryki Łacińskiej. 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 San Fernando de Henares 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 Madrycie i w szerszej Hiszpanii, które mają siedzibę, magazyn albo klientów na rynku hiszpańskim. Zakres to checkout B2B i B2C, Redsys, Bizum, strefy dostaw, logika podatkowa, integracja z ERP, SII AEAT, 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 firm w Madrycie

Projekty WooCommerce, które trafiają z Madrytu, rzadko są sklepem rzemieślnika ze stu referencjami dla konsumentów. To hurtownicy z Vallecas i San Fernando de Henares z własnym magazynem i katalogami tysięcy artykułów, producenci otwierający kanał digital bez rezygnacji z handlowca, importerzy obsługujący peninsulę i Amerykę Łacińską z jednej instalacji. Ten profil zmienia rozmowę. Pytanie nie jest, jak zrobić ładny escaparate, ale jak sprawić, żeby WooCommerce zachowywało się jak element systemu firmy: rozmawiało z ERP, respektowało hiszpański fiskus i rozumiało, że klient firmowy nie kupuje tak jak konsument.

WooCommerce wchodzi na ten teren z przewagą i pułapką. Przewaga: jako WordPress pod spodem nie narzuca zamkniętego modelu biznesowego, prawie każda reguła handlowa modeluje się hookami bez walki z platformą. Pułapka: ta sama elastyczność w instalacji pełnej luźnych wtyczek produkuje sklepy, które działają z trudem i padają przy każdej aktualizacji. Praca seniora B2B to wykorzystać pierwsze bez wpadania w drugie.

Typowy brief z Madrytu nie brzmi „zróbcie sklep”. Brzmi: odziedziczony Woo z page builderem, Redsys skonfigurowany trzy lata temu, magazyn klei statusy ręcznie po Black Friday, dział prawny pyta, czy checkbox zgody i política de privacidad obronią się przed AEPD, a finanse chcą, żeby zamówienia szły do SII bez ręcznego reteclowania w Excelu. To dług integracyjny, który wychodzi w szczycie sezonu, nie w audycie SEO.

#Checkout, Redsys, Bizum i płatność B2B

Checkout skierowany do Hiszpanii ma niepisane zasady. Dla klienta końcowego naturalna ścieżka to Redsys, bo stoi za TPV wirtualnymi większości hiszpańskich banków, z pokryciem płatności jednorazowej, pełnego i częściowego zwrotu oraz uwierzytelnienia wzmocnionego wymaganego przez regulacje płatnicze. Bizum przeszedł z ciekawostki do metody, której część hiszpańskich kupujących oczekuje w kasie. Pominięcie Bizum w sklepie B2C to konwersja pozostawiona na stole.

W B2B płatność zmienia naturę i to często zapominają. Firma kupująca od firmy rzadko płaci kartą zamówienie o określonej wielkości: płaci przelewem, z odroczeniem na trzydzieści lub sześćdziesiąt dni, albo z linii kredytu kupieckiej, którą przyznał handlowiec. Checkout hurtowy oferuje kombinację odpowiednią dla typu konta, nie jeden metodę myślanego pod konsumenta.

Webhooki bramki i status zamówienia muszą przeżyć aktualizację WooCommerce i patch wtyczki płatniczej. Przykład z audytu w Madrycie: zamówienie opłacone przez Bizum, a w panelu WooCommerce wciąż „oczekujące na płatność”, bo callback nie dotarł po patchu albo środowisko testowe i produkcja miały różne URL callbacków. To incydent operacyjny, nie błąd UX. 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 B2B i integracji jest zbyt kosztowna do migracji przed sezonem. Decyzja trafia do pisemnego kompromisu technicznego.

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 przy Paseo de la Castellana nie akceptuje argumentu „strona produktu jest szybka”, kiedy checkout na mobile wisi trzy sekundy przed polem karty.

#Katalogi tysięcy SKU: co łamie sklepy z szablonu

Sklep z dwustu produktów nie ujawnia limitów niczego. Problemy pojawiają się, gdy realny katalog hurtowy wchodzi do bazy: kilka tysięcy referencji, każda z wariantami formatu, koloru lub rozmiaru, często z jednostką sprzedaży inną od jednostki zakupu, bo klient zamawia palety, a faktura jest per sztuka. W tym wolumenie trzy rzeczy zaczynają pękać równolegle. Panel administracji produktów staje się wolny, bo każda ekran ciągnie metadane bez indeksów. Wyszukiwanie z filtrami atrybutów odpala zapytania, których żaden plugin facetów nie rozwiązuje sam. Masowa aktualizacja cen, gdy dostawca zmienia taryfę, wywraca witrynę, jeśli odpala się naiwnie w jednym żądaniu HTTP.

Żaden z tych problemów naprawia się kolejną wtyczką na wierzchu. Naprawia się w warstwie, którą większość instalacji ignoruje: indeksacja bazy pod realne zapytania, import katalogu partiami w tle zamiast jednego żądania wygaszonego na timeout, strategia cache rozróżniająca stronę publiczną, którą można serwować z cache, od widoku z cenami klienta, którego nie. Gdy hurtownik mówi, że sklep działa dobrze poza dniem aktualizacji taryfy, diagnoza prawie zawsze siedzi w tej warstwie, nie w motywie z marketplace.

#Ceny per klient, zamówienia po CIF i zakup firmowy

W B2B cena nie jest etykietą, jest umową. Ten sam komponent kosztuje inaczej dla instalatora kupującego palety i dla klienta okazjonalnego, a różnica nie może żyć w arkuszu obok systemu sprzedaży. WooCommerce modeluje to dobrze od początku: taryfy per rolę klienta, taryfy specyficzne dla negocjowanych kont, rabaty progowe i opcja ukrycia cen oraz przycisku kupna do logowania firmy, co wielu hurtowników wymaga, bo nie chcą pokazywać warunków konkurencji.

Wokół ceny jest inny flow zakupu. Konto identyfikuje się CIF, nie dowolnym mailem, i często za nim stoi kilka osób: kto wybiera materiał, kto zatwierdza wydatek i kto dostaje fakturę. Modelowanie kont firmowych z wieloma użytkownikami, rolami wewnętrznymi i obiegiem zatwierdzenia zamówienia zamienia sklep w narzędzie, którego dział zakupów klienta może używać bez telefonu. To budujemy na udokumentowanych hookach WooCommerce i rejestrujemy, żeby utrzymanie nie zależało od zgadywania, dlaczego jeden klient widzi inną cenę niż drugi.

#ERP, SII AEAT i gdzie naprawdę siedzi projekt

W większości tych briefów escaparate jest małą widoczną częścią. Projekt naprawdę siedzi w integracji. Firma madrytowska z magazynem ma już ERP, w którym żyje prawdziwa prawda biznesowa: SAP Business One w średnim segmencie, Sage 200 lub a3ERP w dużej części przemysłu i dystrybucji. Sklep nie może być wyspą duplikującą artykuły, stock i klientów ręcznie. Definiujemy dla każdego danych, który system rządzi i w jakim kierunku płynie: artykuł i taryfa zwykle rodzą się w ERP i schodzą do sklepu, stock synchronizuje się z częstotliwością, którą biznes toleruje, zamówienie z WooCommerce wchodzi do ERP jako albarán i faktura bez reteclowania. Ta architektura, z przypadkami konfliktu i rejestrem błędów, decyduje, czy projekt oszczędza pracę, czy ją podwaja. Szczegółowy zakres integracji opisuje strona integracje WooCommerce z ERP i API hurtowni.

Na tej integracji opiera się obowiązek fiskalny, który w Madrycie generuje najwięcej pytań: Suministro Inmediato de Información. Firmy powyżej progu fakturowania, w REDEME lub w grupie VAT muszą przesyłać rejestr faktur do Agencia Tributaria w bardzo krótkich terminach. Pokusa jest, żeby WordPress emitował do SII bezpośrednio. To błąd. Poprawna ścieżka prawie zawsze przechodzi przez ERP lub homologowany software fakturowania, gdzie mieszka pełna faktura i gdzie już istnieje certyfikowane połączenie. Nasza rolą jest, żeby zamówienie dotarło do tego systemu ze wszystkimi danymi, których SII wymaga, nie zamieniać sklepu w emisor fiskalny, którego nikt nie certyfikował. Z wejściem obowiązkowej faktury elektronicnej między firmami i regulacji weryfikowanych systemów fakturowania ta granica ma coraz większe znaczenie.

#IVA intracomunitario i eksport do Ameryki Łacińskiej

Firma w Madrycie sprzedająca poza peninsulę obsługuje dwa reżimy fiskalne, które sklep musi rozróżniać bez angażowania klienta w szczegóły prawa. Sprzedaż do innej firmy UE z numerem operatora intracomunitario idzie bez IVA przez reverse charge, jeśli numer przechodzi walidację VIES, a sprzedaż trafia potem do modelu 349. Konfigurujemy walidację VIES przy rejestracji lub checkout i klasy podatkowe, żeby zwolnienie stosowało się automatycznie, nie przez improwizowany kod rabatu.

Eksport do Ameryki Łacińskiej to inny przypadek od podstaw. Wysyłka do Meksyku, Kolumbii lub Chile wychodzi z Unii Europejskiej, więc jest eksportem zwolnionym z hiszpańskiego IVA, z kontrapunktem dokumentacji celnej i podatków kraju docelowego, które idą na konto kupującego. Sklep musi odzwierciedlać to zwolnienie według destynacji i przygotować zamówienie pod obieg celny, a handlowiec musi wyjaśnić klientowi latinoamerykańskiemu, dlaczego cena nie ma hiszpańskiego IVA, ale będzie miała cła tam. Modelujemy reguły podatków per strefa i typ klienta, żeby zachowanie było poprawne i auditable, bo systematyczny błąd IVA na setkach zamówień to nie detal, to korekta.

#Madryt: La Nave, Vallecas i tejido corporativo

Madryt nie jest Barceloną ani Sewillą turystyczną. Tu liczy się La Nave Innovation Hub, poligony Vallecas i San Fernando de Henares z magazynami hurtowych, fintech i MŚP z biurami przy Castellana, oraz ekosystem B2B, w którym digitalizacja kanału hurtowego jest projektem operacyjnym, nie dodatkiem do strony firmowej.

#La Nave i sklepy scale-upów

La Nave w Villaverde to jeden z wyraźnych punktów odniesienia dla rynku technologicznego w Madrycie. WooCommerce trzyma sklep produktowy, subskrypcję, katalog B2B dla partnerów i checkout, który musi przeżyć skok ruchu po kampanii albo wzmiance w mediach branżowych. Awaria checkoutu po aktualizacji wtyczki cache albo regresja w logice cen B2B boli w tygodniu kampanii, nie w sierpniu. Development z runbookiem bramek, webhooków i ścieżki koszyk → opłacone → mail → ERP widzi to. Development testujący tylko stronę kategorii nie.

Madryt nie wymaga data center w mieście. Wymaga sensownej jurysdykcji hostingu w UE, stagingu z tym samym stosem płatności i rollbacku zapisanego przed wdrożeniem. Origin w Madrycie albo Frankfurt plus CDN z terminałem TLS w UE zwykle wystarcza dla użytkowników Hiszpanii.

#Vallecas i hurt z magazynem

Hurtownicy z Vallecas i aglomeracji madrytowskiej sprzedawali przez telefon i mail, zanim digitalizacja kanału stała się obowiązkiem. ERP już działał latami. Brief często nie jest „nowy sklep”, ale kanał digital dla dotychczasowych klientów z taryfami negocjowanymi widocznymi tylko po logowaniu i zamówieniem wpadającym do ERP bez reteclowania. Escaparate jest szybki; czas idzie na uzgodnienie, który system rządzi każdym danym i co robić, gdy stock sklepu i magazynu się rozjeżdża.

#RODO, AEPD i LOPDGDD 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 UE, jak długo trzymamy logi płatności, kto jest administratorem danych, czy mamy umowę powierzenia z bramką i hostem. Te pytania obsługujemy 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 Madrycie wynika z tego konkretny zakres prac: lista podprocesorów (host, CDN, Redsys, Bizum, poczta transakcyjna, analityka, ERP), umowa powierzenia tam, gdzie agencja przetwarza dane, procedura naruszenia w 72 godziny zgodnie z art. 33 RODO, 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ą i oś czasu po incydencie, 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. Brak szczegółów nie zwalnia z 72 godzin, ale pozwala na zgłoszenie etapowe.

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) to odpowiedź na pytanie o jurysdykcję. 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/CIF, callback Redsys, eksport do ERP, reguły B2B. Jeśli po zmianie motywu znika logika Bizum albo ceny według ról, architektura była zła.

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 Madrycie 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.

W sklepie B2B cache źle zrozumiany robi coś gorszego niż wolna strona: serwuje jednemu kupującemu cenę negocjowaną innego. Strategia cache projektowana jest per typ strony i stan sesji: publiczne cacheowane, zależne od klienta z identyfikatorem przechodzą do originu.

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 Hiszpanii.

#Integracje ERP, magazyn i marketplace

Powtarzalna integracja w Madrycie to magazyn lub ERP: SAP Business One, Sage 200, a3ERP, Holded, fulfilment zewnętrzny. Zamówienie opłacone przez Bizum musi trafić do magazynu bez ręcznego eksportu CSV o północy. Webhook Woo → ERP 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) 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.

#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 ERP.

Środowisko testowe jest kopią produkcji z zanonimizowanymi danymi klientów. TPV w sandbox, te same wtyczki płatności, ten sam CDN. Regresja zwrotu i regresja „aktualizacja Woo + wtyczka płatności” dzieją się tutaj. Promocja na produkcję jest udokumentowanym krokiem ze ścieżką wycofania.

QA end-to-end na stagingu pokrywa: koszyk gościa, koszyk zalogowany z taryfą B2B, Bizum, karta przez Redsys, błąd 3DS, płatność odroczona, anulowanie, zwrot częściowy, IVA intracomunitario, eksport, mail do klienta, status w panelu, wpis w logu ERP. Bez tej listy każda aktualizacja jest ruletką.

#Profile projektów Madrycie: 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 madrytowskim, i cele techniczne uzgadniane przed pierwszą linią kodu.

#Profil 1: dystrybutor z magazynem i ERP

Typowy projekt: hurtownia materiałów technicznych z kilku tysięcy referencji sprzedawała telefonem i mailem, ERP działał latami. Brief to kanał digital dla dotychczasowych klientów z taryfami negocjowanymi widocznymi tylko po logowaniu i zamówieniem wpadającym do ERP.

Zakres pracy:

• Wtyczka checkoutu z polami B2B i eksportem zamówień do SAP Business One lub a3ERP.
• Strefy dostaw z paletowymi stawkami dla peninsuly i eksportu.
• RODO: rejestr podprocesorów i política de privacidad powiązana z checkout pod pytania AEPD.

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

#Profil 2: marka z kanałem B2B i B2C

Typowy projekt: producent chce sprzedawać do dystrybutorów i bezpośrednio do konsumenta z jednej witryny, z różnymi cenami, podatkami i metodami płatności według rol.

Zakres pracy:

• Jedna instalacja, dwa zachowania rozdzielone rolą klienta.
• Konsument: ceny z IVA, Redsys i Bizum. Dystrybutor: netto, zakup na volume, płatność odroczona.
• Walidacja VIES dla klientów UE w tym samym checkoutu.

Cele techniczne w umowie: jeden katalog produktów, brak duplikacji stanów między kanałami, test regresji cen po każdej aktualizacji Woo.

#Profil 3: eksporter do Ameryki Łacińskiej

Typowy projekt: firma sprzedająca w Hiszpanii otworzyła rynki w Meksyku i Kolumbii i odkryła, że sklep źle liczy podatki na każdym zamówieniu eksportowym.

Zakres pracy:

• Modelowanie zwolnienia IVA przy eksportu poza UE.
• Przygotowanie zamówienia pod dokumentację celną.
• Jasne copy dla handlowca wyjaśniające cenę dla klienta docelowego.

Cele techniczne w umowie: auditable reguły podatków per destynacja, brak systematycznego błędu na rosnącym wolumenie zamówień.

#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.

Checkout to powierzchnia, którą atakant ogląda pierwszą. Dane wrażliwe kart delegujemy do pasarelas, reszta instalacji jest utwardzana przez parametryzowane zapytania, escapowanie wyjścia, nonce na formularzach i limitowanie na logowaniu. Wyciek danych firmy z taryfami negocjowanymi to nie drobny incydent techniczny, gdy klient to inna firma, która zaufała warunkom w twoim sklepie.

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

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, logika cen B2B w motywie zamiast w wtyczce. Lista napraw idzie przed większą przebudową checkoutu.

Czy pracujecie z firmami spoza Madrytu? Tak. Znamy kontekst Vallecas, La Nave, Redsys, Bizum, SII AEAT i AEPD, ale współpracujemy z klientami w całej Hiszpanii i za granicą. Wiele firm w Madrycie obsługuje magazyn w aglomeracji i klientów Barcelonie 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 i maile transakcyjne tam, gdzie rynek tego wymaga. Decyzja architektoniczna zapisana przed implementacją.

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

Czym różni się współpraca z WPPoland od lokalnej agencji w Madrycie? 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 Madrycie z integracjami Redsys w kontekście całego WordPressa. Pillar bez miasta: programista WordPress. Stała opieka po uruchomieniu sklepu: opieka techniczna WordPress w Madrycie albo pillar utrzymanie stron WordPress. Pełny zakres Woo bez miasta: programista WooCommerce. Integracja z ERP opisana na integracje WooCommerce z ERP.

#Rozpocznij swój projekt w Madrycie

Jeśli chcesz omówić programowanie WooCommerce dla firmy w Madrycie, wyślij krótki opis obecnej sytuacji: bramki, integracje z ERP, model cen B2B, obowiązki SII AEAT, wersje językowe, eksport poza UE i terminy kampanii. Na tej podstawie sprawdzamy checkout, wskazujemy ryzyka callbacków i proponujemy praktyczny plan działania.

Jeśli planujesz nowy sklep hurtowy, 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 wolumenu katalogu, liczby integracji i reżimu fiskalnego, nie z listy stałych stawek.

Ostatnia aktualizacja: 28 sierpnia 2026