Programista WooCommerce we Florencji

Sklep WooCommerce we Florencji stoi obok pracowni skórzanej w Scandicci, showroomu B2B w Oltrarno albo butiku luksusowego w centro storico. Kupujący płaci w euro przez PayPal, Stripe albo Nexi, wybiera BRT albo GLS z punktem odbioru w aglomeracji florenckiej i oczekuje faktury z IVA, którą księgowość wgra do gestionale. Checkout skopiowany z rynku północnoeuropejskiego - waluta w PLN albo GBP, brak walidacji codice fiscale, cookie banner ładujący tagi przed zgodą - gubi zamówienia zanim ktokolwiek oceni jakość skóry albo numer referencyjny kolekcji. Ta strona opisuje budowę i naprawę sklepu: katalog, checkout, płatności, dostawy, stany i zwroty. Nie opisuje opieki serwera ani motywu korporacyjnego bez koszyka.

Zakres pokrywa programistę WooCommerce w warunkach włoskich. Strona firmowa bez koszyka to osobna ścieżka: programista WordPress we Florencji. Sklep już na produkcji, który potrzebuje aktualizacji i kopii, a nie przebudowy checkoutu, idzie na opiekę techniczną WordPress we Florencji.

#Checkout WooCommerce we Florencji

Florencja nie jest Mediolanem i nie jest Bolonią. Mediolan ma Porta Nuova i Fashion Week w lutym. Bolonia ma Motor Valley wzdłuż A14. Florencja ma coś innego: Pitti Uomo w Fortezza da Basso, klastry skórzane w Scandicci, showroomy B2B w Oltrarno i San Frediano, jubilerów centro storico i ekspansję cyfrową luksusowych MŚP, które dotąd żyły głównie z agentów i targów. To nie jest slogan na slajdzie. To realny kontekst briefu: firma we Florencji często obsługuje hurtowników całej Europie i w Azji, a sklep musi działać dla odbiorcy w Niemczech albo w Japonii bez osobnej instalacji na każdy kraj.

Pitti Immagine organizuje Pitti Uomo dwa razy do roku we Florencji (styczeń i czerwiec, dokładne daty co sezon ogłasza Pitti Immagine). W tym oknie setki marek, agentów i mediów branżowych patrzą na lookbooki, landingi kolekcji i formularze spotkań B2B. Awaria checkoutu w środku tygodnia targowego to utracone spotkania wholesale i reputacja u agentów, którzy mają pięć minut między showroomami. Brief od klienta we Florencji często brzmi: mamy Woo z page builderem, magazyn w Scandicci synchronizowany ręcznie, checkout w EUR, ale webhook Stripe gubi się po weekendzie sprzedażowym, a dział prawny czyta wymogi Garante Privacy, nie tylko wynik Lighthouse.

Sklepy, które tu stawiamy albo naprawiamy, zwykle łączą dwa rytmy: codzienną sprzedaż B2C z dostawą BRT do aglomeracji florenckiej oraz skoki katalogu przed Pitti Uomo albo premierą lookbooka, gdy hurt z magazynu w Scandicci musi wyjechać paletami GLS albo DHL, a nie listem poleconym Poste Italiane.

Marka skórzana z Toskanii, producent tekstyliów z Prato albo showroom B2B w dzielnicy Oltrarno potrzebuje sklepu, który nie brzmi jak szablon z marketplace, ale ma ten sam rejestr formalny co katalog PDF wysyłany do agenta w Mediolanie. Ceny netto, pole partita IVA, płatność przelewem i paletowa wysyłka to nie opcje premium. To warunek, żeby zamówienie w ogóle przeszło u księgowości.

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 we Włoszech w 2026

Włoski koszyk zaczyna się od waluty. Sklep we Florencji sprzedaje w EUR. Stripe, Nexi i PayPal to trzy bramki, które pokrywają większość scenariuszy: karta z 3D Secure, Apple Pay, Google Pay, portfel PayPal i płatność odroczona tam, gdzie PayPal oferuje Pay in 3. Klient z Toskanii oczekuje, że kwota na checkoucie, w mailu potwierdzającym i na wyciągu bankowym będzie w euro, nie w funtach przeliczonych po kursie z wczoraj.

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. Stripe w praktyce zgłasza payment_intent.succeeded i charge.refunded osobnymi zdarzeniami. Nexi wymaga osobnej decyzji, czy capture idzie od razu, czy po nadaniu przesyłki - przy towarze fizycznym z magazynu w Scandicci druga opcja chroni przed pobraniem pieniędzy za SKU, którego nie ma.

Kolejność metod na checkoucie ustawiamy pod włoskie nawyki: PayPal i Apple Pay wysoko, karta przez Stripe albo Nexi niżej, bonifico bancario tylko w ścieżce B2B z jasnym komunikatem o czasie księgowania. Domyślny szablon Woo z kartą na górze i bez portfela pracuje wbrew nawykom rynku włoskiego, w tym kupującego we Florencji, który woli PayPal albo Apple Pay przy koszyku z luksusową torbą albo paskiem skórzanym.

Sprzedaż transgraniczna w UE wymaga osobnej decyzji o VAT OSS albo lokalnej rejestracji w kraju docelowym. Woo sam z siebie nie jest modułem OSS. Albo wtyczka podatkowa liczy stawki destynacji, albo gestionale jest źródłem podatku, a Woo tylko zbiera adres i kwoty. Mieszanie obu źródeł to najczęstszy rozjazd w deklaracji IVA.

#Strefy dostaw: BRT, GLS i DHL

Krajowa dostawa we Włoszech w 2026 to przede wszystkim BRT (Bartolini), GLS i DHL. Poste Italiane obsługuje listy i paczki do standardowego gabarytu. GLS i BRT dają kuriera do drzwi i sieć punktów odbioru w aglomeracji florenckiej: centro storico, Scandicci, Campi Bisenzio, Sesto Fiorentino, Bagno a Ripoli. Strefy Woo rozdzielamy nie tylko na Włochy / UE / reszta świata, ale na wagę i wymiar: do progu listu, do progu paczki kurierskiej, powyżej palety DHL.

Integracja z kurierem wymaga mapowania produktów Woo na usługi przewoźnika: BRT Express, GLS Business Parcel, DHL Express. 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 BRT przy liczbie zamówień po weekendzie Pitti Uomo 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 (Florencja, Prato, Pistoia) ma osobną metodę z jasnym adresem magazynu albo showroomu.

Pitti Uomo w Fortezza da Basso to kalendarz, nie temat transportowy na stronie sklepu. Okna targowe, zmiany w dostępności showroomów i kampanie lookbookowe wpisują freeze wdrożeń w runbooku. Firma z biurem w Oltrarno, która planuje premierę kolekcji na styczeń albo czerwiec, potrzebuje sklepu, który przeżyje zmianę adresu magazynu odbioru osobistego bez ręcznego grzebania w HTML.

#IVA i numer partita IVA

Stawka standardowa IVA we Włoszech w 2026 to 22 procent. Obniżone stawki dotyczą wybranych kategorii towarów. Koszyk mieszany jest codziennością przy sklepie, który sprzedaje akcesoria modowe obok materiałów B2B dla pracowni. Woo musi liczyć podatek per pozycja, a nie weź najwyższą stawkę koszyka. Błąd w klasie podatkowej produktu wychodzi dopiero na fattura elettronica.

B2B wewnątrz Włoch z ważnym numerem partita IVA 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 partita IVA na checkoucie, walidacja i przełączenie klasy podatkowej to nie ozdoba formularza. Przy płatności bonifico B2B to samo pole decyduje, czy faktura w ogóle ma szansę przejść u księgowości w Scandicci.

Granicę co liczy podatek i wystawia dokument zapisujemy w runbooku: WooCommerce Tax, osobny silnik faktur, albo gestionale (TeamSystem, Zucchetti, Danea). 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 we Florencji, nie leży w wyglądzie checkoutu. Leży w tym, co dzieje się po kliknięciu Paga con PayPal albo Effettua ordine. Sklep z magazynem w Scandicci, 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 PayPal klient zamyka kartę w tramwaju między Fortezza da Basso a Oltrarno, traci sieć w tunelu pod Arno, 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 fattura, nadanie BRT albo GLS - zdejmujemy do Action Scheduler, żeby odpowiedź 200 wracała szybko i Stripe albo Nexi 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 PayPal na ostatnią sztukę limitowanego SKU z kolekcji po Pitti Uomo i oboje dostają potwierdzenie.

Przy sprzedaży wielokanałowej rezerwacja Woo nie wie nic o marketplace, agentach hurtowych 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 bonifico B2B ustawia się dłużej niż przy PayPal: 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 Stripe, PayPal, Nexi, BRT i GLS są na HPOS od dawna. Problemem są stare konektory magazynowe i autorskie crony z epoki przed migracją.

#RODO, Garante Privacy i formularze we Włoszech

Włochy stosują rozporządzenie UE 2016/679 (RODO) wraz z krajową implementacją w D.Lgs. 196/2003 (Codice Privacy), nadzorowaną przez Garante per la protezione dei dati personali. Dla sklepu WooCommerce we Florencji to nie jest abstrakcyjny paragraf prawny. To decyzje w formularzach, w wtyczkach consent, w informativa privacy i w logach audytowych.

Co wpisujemy w brief i w kod:

• Formularze zbierające dane osobowe (konto klienta, newsletter, zapytania B2B od agentów, zapis na Pitti Uomo) dostają jawną podstawę prawną, checkbox zgody tam, gdzie consent jest wymagany, i minimalizację pól.
• Wtyczki consent (Iubenda, Cookiebot, Complianz i podobne popularne we Włoszech) konfigurujemy tak, żeby skrypty marketingowe nie ładowały się przed akceptacją. To jest decyzja w motywie i w kolejności enqueue, nie ticket opieki po pierwszym raporcie Garante.
• Informativa privacy i cookie policy są szablonami z polami, nie blokami, które redaktor może usunąć z drzewa. We Florencji 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 (DPA) to decyzja klienta, ale konfiguracja WooCommerce 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 zapisu na spotkanie B2B w piątek przed Pitti Uomo, odpowiedź nie może być nie wiemy.

Zespół nie obiecuje zgodności z RODO bez właściciela procesu po stronie klienta. Obiecuje konfigurację techniczną, którą właściciel może opisać w dokumentacji. Garante publikuje wytyczne na garanteprivacy.it; runbook checkoutu powinien być z nimi zgodny co do tego, co agencja dokumentuje, a co zostaje po stronie administratora danych.

Hosting danych osobowych pod RODO ciągnie pytanie: w której jurysdykcji stoi serwer. AWS eu-south-1 w Mediolanie, OVH we Francji, Hetzner w Niemczech, Aruba albo Seeweb we Włoszech to różne odpowiedzi dla compliance officer, ale wszystkie mieszczą się w UE. Ashburn albo Hillsboro to Stany i zwykle wymaga Standard Contractual Clauses albo innej podstawy transferu. Decyzję zapisujemy w liście podprocesorów, nie w stopce motywu.

#Zwroty i Codice del consumo jako operacje sklepu

Poniższe akapity opisują skutki w sklepie. Nie są poradą prawną. Teksty condizioni di vendita, informativa privacy 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 we Włoszech ma prawo odstąpić od umowy zawartej na odległość w ciągu 14 dni na podstawie Codice del consumo. Termin zaczyna biec, gdy klient otrzymał towar. Dla magazynu w Scandicci 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ą BRT albo instrukcję nadania GLS.
3. Przyjęcie na magazynie zdejmuje blokadę SKU i dopiero wtedy idzie wc_create_refund na Stripe, Nexi, PayPal albo przelew zwrotny przy bonifico.
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 Pitti Uomo i po świętach to test tej ścieżki. Sklep, który w lipcu ręcznie klika zwroty w panelu PayPal, a stany poprawia w Excelu, rozjeżdża raport IVA i nadsprzedaje wracający towar.

#Katalog i checkout pod kalendarz Pitti Uomo

Pitti Uomo to jedno z najważniejszych wydarzeń mody męskiej na świecie. Tysiące agentów, mediów i kupujących, skoki ruchu na stronie, newslettery w tysiącach, a każda zmiana na produkcji jest ryzykiem. Dlatego w runbooku zapisujemy freeze wdrożeń: w tygodniu targowym nie idą aktualizacje wtyczek, nie idą nowe bloki, nie idą zmiany w motywie. środowisko testowe dostaje zmiany, produkcja czeka do poniedziałku po zamknięciu Fortezza da Basso.

Katalog, który przez jedenaście miesięcy ma setki 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 BRT i GLS nie wchodzi na produkcję w oknie Pitti Uomo. Tydzień przed otwarciem targów produkcja nie dostaje drobnej aktualizacji SEO. Drobna aktualizacja SEO w piątek przed premierą lookbooka potrafi nadpisać robots, wyciąć landing z indeksu albo zepsuć cache strony rejestracji na spotkanie B2B.

Warianty trzymamy jako prawdziwe variation z własnym SKU, wagą i klasą podatkową, nie jako pole tekstowe wpisz kolor. Duża macierz (materiał skórzany × rozmiar × wykończenie przy akcesoriach modowych) dostaje własne zapytania i cache fragmentów.

Preorder przed sezonem: SKU jest widoczny, płatność schodzi, ale fulfillment stoi aż do daty premiery kolekcji. Status on-hold albo własny status warte na magazyn Scandicci musi blokować etykietę kuriera. Inaczej wtyczka GLS nada pustą paczkę pod punkt odbioru w centro storico.

Ceny netto / brutto na checkoucie B2B (netto plus IVA) i B2C (brutto) to dwa szablony, nie przełącznik CSS. Kupujący z partita IVA w Mediolanie oczekuje netto. Konsument z aglomeracji florenckiej oczekuje brutto.

Język checkoutu: sklep we Florencji często idzie po włosku jako kanon, z angielskim i niemieckim dla agentów zagranicznych, czasem japońskim dla rynku azjatyckiego. WPML WooCommerce Multilingual albo Polylang nie mogą rozjechać klas podatkowych i metod dostaw między językami.

#Florencja jako kontekst toskański, nie jako ozdobnik

Toskania to jeden z najważniejszych klastrów mody i luksusu rzemieślniczego we Włoszech. Wokół Scandicci siedzą pracownie skórzane, w Prato tekstylia, w centro storico jubilerzy i butiki hotelowe. Dla WooCommerce we Florencji wynika z tego prosta rzecz: sklep B2B producenta musi pokazać certyfikaty, specyfikacje materiałów, numery katalogowe i formularz zapytania dystrybutorskiego. Awaria checkoutu albo nieaktualny stan magazynowy boli w łańcuchu dostaw do agentów, nie w UX slajdu.

Typowy brief, który trafia do seniorów, nie brzmi zróbcie ładny sklep. Brzmi: odziedziczony Woo z trzydziestoma wtyczkami, checkout który gubi webhook Stripe, magazyn w Scandicci synchronizowany ręcznie z Excela, księgowość czeka na eksport do gestionale, a za tydzień startuje kampania pod Pitti Uomo. To jest problem checkoutu, webhooków i HPOS, nie problem szablonu z marketplace.

Florencja nie jest Mediolanem pod kątem kalendarza mody. Pitti Uomo to inny rytm niż Milano Fashion Week. Firmy stąd obsługują klientów całej Europie i w Azji, a Florencja jest jednym z najczęściej odwiedzanych miast turystycznych na świecie. Dla WooCommerce to oznacza więcej pytań o wielojęzyczność, hreflang, wysyłkę międzynarodową i locale redaktora pracującego po polsku przy froncie po włosku.

Luksusowe MŚP we Florencji (marki skórzane, winiarnie z e-commerce premium, butiki hotelowe) generują sklepy z mocnym storytellingiem, ale słabą warstwą operacyjną. Page builder generujący shortcode’y w treści, motyw bez wariantów SKU i brak webhook idempotencji to trzy osobne problemy, które razem dają sklep ładny na slajdzie i martwy w piątek po deployu.

Showroom B2B w Oltrarno nadal sprzedaje przez agentów, ale katalog online, strefa logowania dla hurtowników i rezerwacja terminów spotkań przeniosły się na WooCommerce. Integracje z gestionale, webhooki do CRM i eksport CSV zamówień B2B to typowy profil awarii: coś pada po aktualizacji wtyczki formularza albo po zmianie wersji PHP, a produkcja nadal wygląda OK na stronie głównej.

#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. Skrypty Stripe, Nexi i GLS Location Finder ładujemy wtedy, gdy checkout jest na ekranie, z preconnect do ich domen, nie w stopce każdej strony kategorii.

Obrazy katalogu idą w AVIF / WebP z srcset. Lookbooki Pitti generują ciężkie JPEG ze stoiska; bez przetwarzania LCP na karcie produktu spada, zanim kupujący zobaczy przycisk PayPal. 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. Tydzień Pitti Uomo to test infrastruktury, nie średnia z kwartału. Monitoring z jednego regionu USA kłamie, gdy agenci stoją w kolejce przy Fortezza da Basso. Punkt pomiaru w UE jest częścią kryteriów odbioru.

Dla serwisu B2B we Florencji liczy się też czas do pierwszego bajtu z sieci korporacyjnej w Scandicci, Campi Bisenzio albo przy A1, nie tylko z telefonu w centro storico.

#Zakres prac, QA i przekazanie

Audyt na wejściu obejmuje: taksonomię i klasy podatkowe IVA, kolejność metod płatności Stripe, Nexi i PayPal, strefy BRT i GLS, HPOS i listę wtyczek czytających zamówienia, webhooki, hold stock, ścieżkę zwrotu, eksport do gestionale, baseline Lighthouse, kalendarz Pitti Uomo w harmonogramie wydań, konfigurację RODO i cookie consent pod Garante Privacy. 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: Stripe test mode, PayPal sandbox, Nexi w środowisku testowym. BRT i GLS mają środowiska testowe etykiet. QA kończy się zamówieniem, które przechodzi: koszyk mieszany ze stawkami IVA, punkt GLS Pickup, 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 centro storico nie są tutaj tematem - to programista WordPress we Florencji. Monitoring, aktualizacje rdzenia i kopie zapasowe bez przebudowy checkoutu to opieka techniczna WordPress we Florencji. Szerszy opis utrzymania bez miasta: utrzymanie stron WordPress. Wspólny filar e-commerce: programista WooCommerce.

Pitti Uomo i klastry skórzane w Scandicci tłumaczą, skąd biorą się sklepy B2B z partita IVA i płatnością bonifico. Nie tłumaczą, czemu webhook Stripe bez idempotencji zostawia zamówienie w pending po weekendzie sprzedażowym.

#Rozpocznij projekt sklepu WooCommerce we Florencji

Do kontaktu wystarczy krótki opis: czy sklep już stoi, jakie bramki są włączone (Stripe, Nexi, PayPal), skąd leci dostawa (BRT, GLS, odbiór w Scandicci), czy HPOS jest włączony, jaki jest magazyn (Scandicci, 3PL, showroom w Oltrarno), czy księgowość czeka na eksport do gestionale, czy cookie consent blokuje tagi przed zgodą, i które daty Pitti Uomo albo premier lookbooka 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. Florencja dostaje ten sam rygor inżynierski co każdy inny sklep, tylko ze stackiem, którego kupujący we Włoszech naprawdę używa, i z kalendarzem toskańskim wpisanym w harmonogram wydań.