Programista WooCommerce w Sewilli

Sklep WooCommerce w Sewilli stoi obok landinga sezonowego pod Semana Santa, butiku z ceramiką z Triany z checkoutem Bizum, hurtowni B2B z cenami według ról i katalogu w ES/EN albo sklepu produktów regionalnych, który w kwietniu musi przeżyć skok ruchu bez gubienia callbacków Redsys. 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 aglomeracji sewillskiej 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 Sewilli i w szerszej Andaluzii, 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 Sewilli

Sewilla to stolica Andaluzji, europejski węzeł turystyczny i dom ważnego klastra aero w La Cartuja. Nie jest Barceloną e-commerce ani Madrytem administracyjnym. Tu liczy się Cartuja Science and Technology Park, operatorzy turystyczni obsługujący Alcázar i katedrę, butiki w Triana i centro histórico, marki D2C z produktami regionalnymi oraz sklepy, które muszą obsłużyć rynek hiszpański i międzynarodowy z jednej instalacji WooCommerce. Brief od klienta w Sewilli 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 Sewilli, 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 Semana Santa, 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 marcu albo w kwietniu przy Feria de Abril, nie w audycie SEO.

WordPress Sevilla spotyka się regularnie w ekosystemie andaluzyjskim. 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ą Correos Express do aglomeracji sewillskiej oraz skoki katalogu przed Semana Santa, Feria de Abril albo kampanią sezonową, gdy magazyn w La Cartuja albo fulfilment w okolicach Sewilli musi wyjechać paletami SEUR, a nie listem poleconym.

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.

#Checkout, Redsys i Bizum

Sklep andaluzyjski 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 Sewilli 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 Semana Santa 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 mody 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 La Cartuja nie akceptuje argumentu strona produktu jest szybka, kiedy checkout na mobile wisi trzy sekundy przed polem karty.

Kolejność metod na checkoucie ustawiamy pod hiszpańskie nawyki: Bizum wysoko, karta przez Redsys niżej, PayPal dla klientów zagranicznych, przelew bankowy tylko w ścieżce B2B z jasnym komunikatem o czasie księgowania. Domyślny szablon Woo z kartą na górze i bez Bizum pracuje wbrew nawykom rynku hiszpańskiego, w tym kupującego w Sewilli, który woli Bizum przy koszyku z produktem regionalnym albo prezentem turystycznym.

#IVA, faktury i dostawa w Andaluzii

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.

Stawka standardowa IVA w Hiszpanii w 2026 to 22 procent. Koszyk mieszany jest codziennością przy sklepie, który sprzedaje gadżety turystyczne obok materiałów B2B dla operatorów wycieczek. Woo musi liczyć podatek per pozycja, a nie weź najwyższą stawkę koszyka. Błąd w klasie podatkowej produktu wychodzi dopiero na fakturze, a nie w koszyku.

Dostawa w Sewilli to nie jedna stawka Hiszpania. Klienci oczekują Correos Express, SEUR, GLS albo odbioru w punkcie. Kalkulator wysyłki musi liczyć wagę, wymiary i strefy (Andaluzia, 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/EN w sklepie wymaga osobnej decyzji: WPML WooCommerce Multilingual, osobne slugi, hreflang na produktach i checkout, tłumaczenia maili transakcyjnych. Kampania w hiszpańskim bez angielskiego checkoutu albo odwrotnie kończy się porzuconymi koszykami, których analytics nie wyjaśni bez nagrania sesji.

#Sewilla: La Cartuja, Semana Santa i sezon e-commerce

Sewilla nie jest Malagą ani Granadą. Tu liczy się Cartuja Science and Technology Park, dzielnica Triana, operatorzy turystyczni przy Alcázar i katedrze oraz dwa sezonowe szczyty: Semana Santa i Feria de Abril. Te osie ustawiają priorytety techniczne dla sklepu, który ma działać w Sewilli, a nie tylko nosić to w tytule strony usługowej.

#La Cartuja i sklepy B2B

La Cartuja Science and Technology Park to jeden z najbardziej rozpoznawalnych hubów technologicznych w Andaluzii. WooCommerce trzyma sklep produktowy, katalog B2B dla partnerów przemysłowych, subskrypcję boxa albo checkout, który musi przeżyć skok ruchu po współpracy z mediami branżowymi albo po demo dla partnera z łańcucha dostaw aero. Awaria checkoutu po aktualizacji wtyczki cache albo regresja w tłumaczeniach ES/EN boli w tygodniu audytu dostawcy, 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 do opłacone do mail do magazyn widzi. Sewilla 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.

#Semana Santa i zamrożenie wdrożeń

Semana Santa w Sewilli to jeden z największych okresów ruchu turystycznego w Hiszpanii. Procesje, blokady ulic, pełne hotele i fala rezerwacji zaczynają się na tygodnie przed Wielkim Tygodniem. W tym oknie setki biur turystycznych, operatorów wycieczek, restauracji i partnerów hotelowych patrzą na landingi sezonowe, formularze rezerwacji i sklepy z produktami regionalnymi. Awaria checkoutu w środku Semana Santa to utracona sprzedaż i ręczne klejenie zamówień w magazynie, nie ticket do backlogu na kwiecień.

Runbook developmentu dla klientów Sewilli ma wpisane zamrożenie wdrożeń produkcyjnych na okno Semana Santa, zwykle od końca marca do tygodnia po Wielkanocy. 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 Wielkiego Tygodnia, uczy się tego na własnej skórze, kiedy callbacki nie docierają pod obciążeniem.

#Feria de Abril i drugie okno freeze

Feria de Abril, dwa tygodnie po Semana Santa, to drugi szczyt sezonu w Sewilli. Real de la Feria, casetas, rezerwacje noclegów i kampanie partnerskie generują kolejną falę ruchu. Runbook ma osobny wpis freeze na okno Feria de Abril, zwykle od tygodnia przed otwarciem do tygodnia po zamknięciu. Dwa freeze w jednym kwartale to nie wyjątek. To normalny kalendarz operacyjny andaluzyjskiego sklepu turystycznego albo eventowego.

#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 (GDPR) oraz krajową ustawę organiczną LOPDGDD. Organ nadzorczy to Agencia Española de Protección de Datos (AEPD). Dla WooCommerce w Sewilli 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 Andaluzii. Decyzję opisujemy w runbooku, nie zgadujemy w rozmowie sprzedażowej.

#Webhooki, rezerwacja stanu i HPOS

Najczęstsza wada sklepów, które wracają do naprawy w Sewilli, nie leży w wyglądzie checkoutu. Leży w tym, co dzieje się po kliknięciu Pagar con Bizum albo Realizar pedido. Sklep z magazynem w aglomeracji sewillskiej, 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 powiadomienie serwer do serwera. Powrót klienta na stronę podziękowania nie jest źródłem prawdy. O pieniądzach decyduje callback bramki. Handler po weryfikacji sygnatury wywołuje payment_complete na obiekcie zamówienia. Cięższą pracę po weryfikacji zdejmujemy do Action Scheduler, żeby odpowiedź 200 wracała szybko i Redsys albo Bizum nie zaczęły ponawiać.

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

Stan rezerwujemy w momencie rozpoczęcia płatności, nie po jej potwierdzeniu. WooCommerce zapisuje rezerwację w tabeli wp_wc_reserved_stock. Bez tego dwoje kupujących wchodzi w Bizum na ostatnią sztukę limitowanego SKU z kolekcji sezonowej i oboje dostają potwierdzenie.

High-Performance Order Storage jest domyślny dla nowych instalacji od WooCommerce 8.2. Zamówienia żyją w wp_wc_orders i powiązanych tabelach, a nie jako wpisy shop_order w wp_posts. Diagnostyka idzie przez wc_get_orders oraz OrderUtil, nie przez SQL w wp_posts. Oficjalne Redsys, Bizum i Stripe są na HPOS od dawna. Problemem są stare konektory magazynowe.

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

#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 Sewilli 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 Andaluzii. Punkt pomiaru w UE jest częścią kontraktu operatorskiego.

#Integracje ERP, magazyn i marketplace

Druga powtarzalna integracja w Sewilli to magazyn albo ERP: Holded, Sage, własny system w La Cartuja, fulfilment zewnętrzny. Zamówienie opłacone przez Bizum musi trafić do magazynu bez ręcznego eksportu CSV o północy. Webhook Woo do magazynu 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 Semana Santa.

#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/EN, regresja zwrotu i regresja aktualizacja Woo plus 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, 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 Sewilli: 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 sewillskim, i cele techniczne uzgadniane przed pierwszą linią kodu.

#Profil 1: sklep produktów regionalnych w Triana

Typowy projekt: sklep wielojęzyczny traci zamówienia w checkout podczas kampanii sezonowych i Semana Santa.

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 La Cartuja

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: operator turystyczny z ruchem międzynarodowym

Typowy projekt: sklep ES/EN ze Stripe dla UE poza Hiszpanią i Redsys dla rynku krajowego, kampania pod Semana Santa co roku.

Zakres pracy:

• Dwa TPV z routingiem kraju w checkout.
• Zamrożenie wdrożeń w oknie Semana Santa i Feria de Abril 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.

#Zwroty i prawo konsumenckie jako operacje sklepu

Poniższe akapity opisują skutki w sklepie. Nie są poradą prawną. Teksty condiciones de venta, política de privacidad 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 Hiszpanii ma prawo odstąpić od umowy zawartej na odległość w ciągu 14 dni. Termin zaczyna biec, gdy klient otrzymał towar. Dla magazynu w Sewilli 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ą Correos Express albo instrukcję nadania SEUR.
3. Przyjęcie na magazynie zdejmuje blokadę SKU i dopiero wtedy idzie wc_create_refund na Redsys, Bizum albo przelew zwrotny.
4. Częściowy zwrot nie zamyka całego zamówienia i nie zwraca kosztów wysyłki w ciemno; kwoty bierze się z pozycji.
5. Towar wyłączony ze zwrotu musi mieć tę informację przy SKU przed zakupem.

Sezon po Semana Santa i po Feria de Abril to test tej ścieżki. Sklep, który w maju ręcznie klika zwroty w panelu Bizum, a stany poprawia w Excelu, rozjeżdża raport IVA i nadsprzedaje wracający towar.

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

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 Sewilli? Tak. Znamy kontekst La Cartuja, Semana Santa, Redsys, Bizum i AEPD, ale współpracujemy z klientami w całej Hiszpanii i za granicą. Wiele firm w Sewilli obsługuje magazyn w Andaluzii 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/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 Sewilli: testowane aktualizacje, regresja checkoutu, kopie, monitoring i runbook freeze Semana Santa. Szczegóły na stronie opieki, nie w tym briefie WooCommerce.

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

#Rozpocznij swój projekt w Sewilli

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 Semana Santa. 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.