WooCommerce Utvikler i Firenze

En WooCommerce-butikk i Firenze som selger håndlaget lær, smykker, vin fra Chianti eller guidede opplevelser må håndtere tre ting som ikke står i standarddokumentasjonen til Woo: italiensk IVA med riktig sats per varegruppe, betaling via Nexi eller Stripe med 3DS slik italienske kunder forventer, og personvern som tåler Garantes praksis for informasjonskapsler og markedsføring. Vi bygger og rydder opp i WooCommerce for bedrifter i Firenze med utgangspunkt i nettopp disse kravene, ikke en generisk mal som siden lokaliseres med bynavn.

Toscana mottar over førti millioner turister i året, og Firenze er det naturlige knutepunktet for luksushandel og opplevelsesbasert salg på nett. En kasse som fungerer i Berlin eller Oslo, men som ikke viser pris inkludert IVA, ikke tilbyr Satispay eller kort via Nexi, og som lagrer markedsføringssporing uten samtykke, taper konverteringer og inviterer klager til Garante. Det er det praktiske utgangspunktet for arbeidet vårt.

#WooCommerce-utvikling i Firenze

Firenze-markedet er preget av luksus, turisme og håndverkstradisjoner som strekker seg fra Oltrarno-verksteder til vinprodusenter i Chianti-klassen. Italienske netthandlere er vant til tydelig pris med IVA inkludert, flere betalingsvalg i kassen og frakt via Poste Italiane eller BRT med sporingsnummer i ordrebekreftelsen. Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik en italiensk kunde forventer, og å gjøre det på en måte som overlever oppdateringer av Woo, temaet og betalingstilleggene.

#Hva vi faktisk bygger

• Nexi og Stripe i kassen: kortbetaling med 3D Secure 2, Satispay som alternativ der trafikken forsvarer det, og test av webhooks for autorisasjon, belastning, refusjon og delvis refusjon mot testmiljø
• IVA-oppsett for italiensk handel: 22 prosent standardsats, 10 prosent redusert sats på mat og visse varer, 4 prosent superredusert der det gjelder, og priser vist inkludert IVA slik italienske forbrukere forventer
• Flerspråklig storefront for turisme og luksus: italiensk som hovedspråk, engelsk for internasjonale besøkende, tyske og franske varianter der trafikken krever det, med hreflang og uavhengige metadata per språk
• Frakt med Poste Italiane, BRT og GLS: fraktsoner innen Italia og til EU, prisregler basert på vekt og volum, og fraktsedler og sporing koblet mot ordrebehandlingen
• Opplevelsesbasert salg: datovalg for vinsmakinger, guidede turer og verkstedsbesøk, med lagerstyring som håndterer begrenset kapasitet per tidspunkt i stedet for fysisk lagerbeholdning
• Angrett og retur bygget inn i flyten: 14 dagers EU-angrerett, returskjema og riktig informasjon i ordrebekreftelse og e-post, slik at kundeservice ikke må håndtere manuelle unntak
• Utvidelser av WooCommerce REST API for hodeløs storefront, mobilapp eller POS, med autentisering og idempotente betalingsstier

#Hvorfor italienske betalings- og fraktvalg styrer arkitekturen

I de fleste WooCommerce-prosjekter for Firenze er det ikke produktkatalogen som er vanskelig, det er kassen. Nexi er den dominerende betalingsleverandøren i Italia, og integrasjonen krever at ordrestatus ikke settes til betalt før webhook bekrefter transaksjonen, ikke når kunden kommer tilbake fra 3DS-vinduet. Vi har sett butikker der ordrer ble markert fullført på redirect tilbake, slik at avbrutte betalinger ga ordrer uten penger. Den typen feil fanges bare med ende-til-ende-QA på selve betalingsstien.

Stripe brukes ofte ved siden av Nexi for internasjonale kort og for butikker som allerede har Stripe-konto fra andre markeder. To gatewayer betyr to sett med statuskoder, to refusjonsmodeller og to webhook-formater, så ordren må lagre i metadata hvilken gateway som eide betalingen og hvilken referanse den bruker. Uten dette blir refusjon fra admin et gjettespill.

Frakt er den andre fellen. En italiensk kunde forventer å se Poste Italiane eller BRT som leveringsalternativ, med sporingsnummer i e-posten når varen sendes. Turismebutikker som selger vin eller keramikk til utlandet trenger dessuten riktig toll- og IVA-dokumentasjon per destinasjon. Vi setter opp fraktsonene og leveringsvalgene som hører til det italienske markedet, og kobler dem mot sporing kunden ser i e-posten.

#Markedet og miljøet i Firenze

Firenze er et av verdens fremste sentre for luksus og håndverk. Scuola del Cuoio ved Santa Croce, gullsmedene på Ponte Vecchio og motehusene som har røtter i byen skaper etterspørsel etter nettbutikker som formidler kvalitet, opprinnelse og historie, ikke bare pris. For en netthandler betyr det at produktsider må laste raskt selv med høyoppløselige bilder, at merkevarefortellingen ikke kompromitteres av en treg kasse, og at internasjonale kunder finner butikken på sitt eget språk.

Turismen driver et eget spor: vinsmakinger i Chianti, guidede turer i Uffizi-køen, matopplevelser og overnatting booket som pakker. Disse butikkene selger tidspunkter og kapasitet, ikke bare SKU-numre. WooCommerce må håndtere datovalg, begrenset antall plasser og automatiske påminnelser uten at lagerbeholdningen behandles som fysiske enheter på hylla.

Kundene våre i Firenze spenner fra familieeide lærværksteder som selger direkte til forbruker, til vinprodusenter som eksporterer til EU og USA, til reiseoperatører som pakker opplevelser for grupper. Fellesnevneren er at de trenger en butikk som tar Nexi og Stripe på alvor, regner IVA riktig og lar dem styre frakten selv.

Mange av disse butikkene har vokst organisk over flere år: et tema fra en kjøpt mal, et halvt dusin tillegg som overlapper, og en kasse som er lappet sammen i takt med at nye krav dukket opp. Det fungerer helt til turistsesongen øker trafikken, et betalingstillegg slutter å bli vedlikeholdt, eller Garante sender en forespørsel om informasjonskapsler. Da er det ikke en ny plugin som trengs, men en opprydding i arkitekturen: skille ut egen kode i en egen plugin, fjerne tillegg som dupliserer hverandre, og gjøre kassen forutsigbar igjen. Vi tar denne typen refaktorering uten å bygge alt på nytt, så lenge WooCommerce er riktig plattform for det butikken skal gjøre. Er det ikke det, sier vi det skriftlig.

#Slik jobber vi gjennom et prosjekt

1. Kasse- og katalogrevisjon. Vi går gjennom dagens WooCommerce-butikk: produkttaksonomi, kasseflyt, aktive betalingstillegg (Nexi, Stripe, Satispay), fraktsoner mot Poste Italiane og BRT, IVA-regler, Garante-krav til samtykke og Lighthouse-måling på de mest besøkte produkt- og kategorisidene.
2. Plan for betaling, frakt og integrasjon. Vi dokumenterer gateway-valg og rekkefølge i kassen, fraktsoner og leveringslogikk, IVA-håndtering og OSS for EU-salg utenfor Italia, og koblinger mot regnskap, lager eller fulfilment. Grensen mellom Woo-kjerne, egen plugin og temakode settes her.
3. Bygging i feature-brancher. Vi følger kodestandardene til WordPress og WooCommerce, utvider Woo via action- og filter-hooks i stedet for å endre kjernen, og tester betalings- og ordrestier underveis.
4. QA på ordrestien. Handlekurv, kasse, betaling med testkort på hver gateway, refusjon og delvis refusjon, retur etter angrerett, kunde-e-post og admin-redigering, kjørt i et testmiljø som speiler produksjon.
5. Utrulling og overlevering. Vi deployer via en dokumentert release-prosess med testet tilbakeføring, og leverer runbook for hver gateway og hver integrasjon sammen med dokumentasjon for butikkstyrere og redaktører.

#Typiske oppdrag fra Firenze-butikker

• Nexi markerte ordrer betalt på redirect. En lærvarebutikk i Oltrarno markerte ordrer fullført når kunden kom tilbake fra 3DS, ikke når Nexi sendte webhook. Vi flyttet bekreftelsen til webhook-håndtereren, la inn idempotens slik at dobbel webhook ikke ga dobbel ordre, og satte opp full testmatrise for autorisasjon, belastning og refusjon.
• Treg kasse på mobil under turistsesongen. En vinbutikk med tungt tema og mange aktive tillegg hadde merkbart forsinkelse før betalingsknappen var klikkbar på italiensk mobiltrafikk. Vi startet med Lighthouse, WP-CLI-profil og Query Monitor på kassesiden, fant cart-fragment-kallene og autoloadede options som var skyld i mesteparten, og fjernet flaskehalsene én etter én i stedet for å installere enda et caching-tillegg.
• IVA og OSS regnet feil. En keramikkbutikk som solgte både innenlands og til andre EU-land blandet sammen italiensk IVA og OSS-reglene for distansesalg. Vi skilte de to flytene, satte riktig sats per produktgruppe og fikk grenseoverskridende salg merket riktig mot fakturering.
• Garante-klage på informasjonskapsler. En luksusbutikk med Meta Pixel og Google Ads-sporing lastet sporingskoder før samtykke. Vi implementerte Consent Mode v2, blokkerte ikke-nødvendige scripts til aktivt samtykke, og dokumenterte behandlingsgrunnlaget i personvernerklæringen slik Garante forventer.

#Tekniske standarder

Vi kjører WooCommerce på PHP 8.2 eller nyere, med object caching (Redis) der trafikken forsvarer det, og CDN foran statiske ressurser. Betaling går via Nexi og Stripe avhengig av hva butikken trenger, alltid med 3D Secure på kort. Tunge jobber, som synkronisering mot lager eller regnskap, kjøres via Action Scheduler i bakgrunnen slik at de ikke blokkerer kassen.

#Hva du kan forvente etter lansering

Vi lover ikke faste prosenttall, fordi resultatet avhenger av utgangspunktet. Det vi leverer er en kasse som bekrefter ordrer på webhook, ikke på redirect, fraktvalg som matcher det italienske kunder forventer fra Poste Italiane og BRT, IVA og angrerett håndtert i selve flyten i stedet for manuelt, personvern som tåler Garantes praksis, og en målbar forbedring i Core Web Vitals på de sidene som faktisk konverterer. Måltallene settes mot dagens nivå i revisjonen, ikke mot oppdiktede bransjegjennomsnitt.

#Sikkerhet og personvern

Hvert prosjekt får en sikkerhetsgrunnlinje: HTTPS med HSTS, Content Security Policy mot XSS, sårbarhetsskanning av avhengigheter i CI, tofaktor for administratorkontoer og testede sikkerhetskopier. Butikker som håndterer personopplysninger får GDPR-tilpasset samtykkehåndtering, databehandleravtale og personvern bygget inn i arkitekturen.

I Italia håndheves GDPR av Garante per la protezione dei dati personali. Praksisen er konkret: informasjonskapsler for markedsføring krever aktivt samtykke før lasting, personvernerklæringen må nevne behandlingsansvarlig og formål, og kundedata fra betaling og frakt skal lagres bare så lenge det er nødvendig. Vi bygger samtykkeløsninger som blokkerer Meta Pixel, Google Ads og lignende til brukeren har valgt ja, og vi dokumenterer hvilke data som sendes til hvilke leverandører. For nettbutikker i Firenze som selger til turister fra hele EU, betyr det også at personvernet må fungere på tvers av språk og at samtykkeloggen kan dokumenteres ved en eventuell klage.

#Ytelse, målt der det teller

Core Web Vitals påvirker både rangering og konvertering, og på en nettbutikk er det kasse-, produkt- og kategorisidene som betyr noe. Luksusbutikker laster ofte store produktbilder, så vi jobber mot lav LCP gjennom optimalisert kritisk renderingsvei og forhåndsinnlasting av hero-bilder i moderne format (WebP/AVIF), lav INP gjennom minimal JavaScript og utsatt innlasting av tredjepartsskript (inkludert betalingsskript og samtykkeverktøy), og stabil layout (lav CLS) gjennom faste bildedimensjoner og reservert plass for dynamisk innhold som betalingsknappen. Vi måler kontinuerlig med Lighthouse i utrullingsløpet, slik at en regresjon blokkerer distribusjon i stedet for å nå produksjon.

#Spørsmål Firenze-butikker stiller oss

Setter dere opp Nexi og Stripe i kassen? Ja. Vi integrerer kortbetaling med 3DS, Satispay der det passer, og tester autorisasjon, belastning, refusjon og delvis refusjon mot testmiljø før lansering. Bekreftelse av betaling skjer på webhook, ikke på redirect tilbake til butikken.

Kan dere håndtere IVA og OSS riktig? Ja. Vi setter 22 prosent standardsats og reduserte satser der de gjelder, viser priser inkludert IVA slik italienske forbrukere forventer, og skiller OSS-flyten for distansesalg til andre EU-land fra ordinær innenlandsk IVA.

Hvilke fraktløsninger støtter dere? Poste Italiane, BRT og GLS, med fraktsoner, prisregler etter vekt og volum, og fraktsedler og sporing koblet mot ordrebehandlingen.

Hvordan håndterer dere Garante-krav til personvern? Vi implementerer samtykke før markedsføringssporing, dokumenterer behandlingsgrunnlag i personvernerklæringen, og sørger for at betalings- og fraktdata lagres og slettes i tråd med GDPR og Garantes veiledning.

Endrer dere WooCommerce-kjernen? Nei. Tilpasninger går via dokumenterte action- og filter-hooks, med en klar deling mellom egen plugin og tema, slik at butikken overlever Woo-oppdateringer.

Jobber dere med butikker utenfor Firenze? Ja. Vi leverer til netthandlere i hele Italia og til italienske butikker drevet fra utlandet, med samme krav til betaling, IVA og personvern.

#Integrasjoner en italiensk nettbutikk faktisk trenger

En italiensk nettbutikk på WooCommerce ender som regel opp med de samme fire koblingene: betaling med Nexi og Stripe, frakt med Poste Italiane eller BRT inkludert sporingsnummer i e-post, regnskap i Fatture in Cloud eller TeamSystem, og en ordrestatus som settes av serveren til leverandøren, ikke av at kunden tilfeldigvis kommer tilbake til takkesiden. Rekkefølgen er ikke tilfeldig: hver kobling nedover i listen arver feilene fra den over hvis den første ikke er riktig bygget.

#Betaling: Nexi og Stripe ved siden av hverandre

Nexi er standarden i Italia. Integrasjonen bygges mot Nexi Payments API med redirect-flyt for 3DS og webhook for endelig bekreftelse. Butikken oppretter en betaling, sender kunden til autentisering og venter. Alt som skjer etterpå er utenfor nettleserens kontroll. Derfor implementeres gatewayen som en vanlig WC_Payment_Gateway-klasse der process_payment returnerer en redirect og ingenting mer, mens fullføringen skjer i callback-håndtereren. Ordren får payment_complete først når Nexi har bekreftet.

Stripe dekker internasjonale kort. Stripe brukes ofte for kunder utenfor Italia og for butikker som allerede har Stripe-konto fra andre markeder. Alltid med 3D Secure. To gatewayer betyr to sett med statuskoder, to refusjonsmodeller og to webhook-formater, så ordren må lagre i metadata hvilken gateway som eide betalingen og hvilken referanse den bruker.

Satispay som mobilalternativ. Satispay er utbredt blant italienske mobilbrukere. Integrasjonen følger samme webhook-prinsipp som Nexi: ordrestatus settes server-til-server, ikke på redirect.

HPOS må deklareres. På butikker med High-Performance Order Storage må egen plugin-kode melde kompatibilitet via FeaturesUtil::declare_compatibility på before_woocommerce_init, og all lesing og skriving av ordredata må gå gjennom wc_get_order og CRUD-metodene i stedet for direkte postmeta-kall. Gammel gateway-kode som skriver med update_post_meta slutter å virke uten å gi feilmelding.

#Frakt: Poste Italiane, BRT og GLS

Fraktpriser hentes, de gjettes ikke. Poste Italiane og BRT tilbyr API-er for pris og leveringstid per produkt og postnummer. Svaret kobles inn i kassen via woocommerce_package_rates, med volumvekt regnet ut fra pakkens dimensjoner der den overstiger faktisk vekt. Svarene mellomlagres i transienter per postnummer og vektklasse, fordi kassen ikke kan vente på et eksternt kall ved hver oppdatering av handlekurven.

Sporing hører hjemme i e-posten. Sporingsnummeret lagres på ordren og skrives inn i forsendelsesvarselet, typisk via woocommerce_email_before_order_table. Det fjerner en av de vanligste henvendelsene til kundeservice, spesielt for turister som venter på vin eller håndverk sendt hjem.

Tidsavbrudd krever en reserveløsning. Når frakt-API-et ikke svarer, skal kassen falle tilbake til en definert standardsats i stedet for å vise en kasse uten fraktvalg. Feilen logges via wc_get_logger med egen kilde, slik at hyppige tidsavbrudd blir synlige i WooCommerce-loggen før kundeservice oppdager dem.

#Regnskap: Fatture in Cloud, TeamSystem og SDI

Salget bokføres én gang, med riktig IVA-kode. Fatture in Cloud og TeamSystem har REST-API med token-basert autentisering. Integrasjonen oppretter kunde og salgsdokument, og mapper hver produktgruppe til riktig IVA-kode i stedet for å sende en flat sats. Nummeret på det opprettede dokumentet skrives tilbake på ordren, og eksistensen av dette nummeret er det som hindrer dobbeltbokføring ved en ny kjøring.

B2B betyr FatturaPA via SDI. Selger butikken til bedrifter i Italia, skal fakturaen sendes elektronisk via Sistema di Interscambio med riktig XML-format. Det er en egen flyt i kassen: felt for Partita IVA, validering, og et annet dokumentløp enn forbrukersalget.

Avstemming er mot utbetaling, ikke mot ordre. Betalingsleverandøren utbetaler samlet og trekker gebyr. Regnskapet stemmer først når integrasjonen bokfører utbetalingen som en egen post med gebyret skilt ut, ikke når hver ordre er bokført hver for seg.

Synkronisering kjøres i kø. All overføring til regnskap legges på Action Scheduler med gjentatte forsøk ved feil, aldri synkront i kasseforespørselen. En regnskapstjeneste som er nede, skal forsinke bokføringen, ikke blokkere et kjøp.

#Hvorfor ordrestatus må settes server-til-server

Takkesiden er et løfte, ikke et bevis. Kunden kan miste dekning i Uffizi-køen, lukke appen, bytte til en annen app mens betalingen fullføres, eller ha nettleseren i bakgrunnen når batteriet sparer strøm. Redirect tilbake til butikken er dermed en hendelse som kanskje skjer. Betalingsbekreftelsen fra leverandørens server er en hendelse som skjer uansett, og det er den ordrestatusen skal henge på.

Verifiser først, kvitter raskt, jobb etterpå. Callback-endepunktet skal først verifisere signaturen på varselet mot delt hemmelighet, deretter svare med en rask kvittering, og først etterpå gjøre det tunge arbeidet i en bakgrunnsjobb. Leverandører prøver på nytt når svaret drøyer, og et tregt endepunkt utløser dermed flere kopier av det samme varselet.

Idempotens lagres, den antas ikke. Hvert varsel har en identifikator. Den lagres når hendelsen er behandlet, og et varsel med en allerede lagret identifikator forkastes. Uten dette gir gjentatte forsøk dobbel belastning, dobbel bokføring i regnskapet og dobbelt kunde-e-post. Hendelser kan også komme i feil rekkefølge, så håndtereren må tåle en belastningsmelding som kommer før autorisasjonsmeldingen.

Endepunktet må være åpent for maskiner. Callback-URL-en skal holdes utenfor sidecache, ikke stå bak passordbeskyttelse eller IP-sperre, og ikke ligge på et testmiljø som krever innlogging. Dette er en vanlig årsak til at en integrasjon virker i testmiljø og ikke i produksjon.

Avstemmingsjobben er sikkerhetsnettet. En planlagt jobb henter status fra leverandøren for ordrer som har blitt stående som ventende lenger enn et definert vindu, og retter opp der varselet aldri kom fram. Jobben kjøres via ekte systemcron mot wp cron event run --due-now med DISABLE_WP_CRON satt, fordi WordPress’ egen pseudo-cron avhenger av trafikk og dermed er upålitelig akkurat når butikken er stille om natten.

Testing gjøres på feilstiene. Testmatrisen dekker ikke bare vellykket betaling, men avbrutt betaling i appen, varsel som kommer to ganger, varsel som kommer i feil rekkefølge, forsinket varsel, frakt-API som svarer for sent, og regnskaps-API som avviser dokumentet. Hver av disse skal ende i en ordre med riktig status og en linje i loggen. Reaksjonstider ved feil i drift avtales skriftlig i vedlikeholdsavtalen.

#WooCommerce i andre italienske byer

Trenger du WooCommerce-hjelp utenfor Firenze, gjelder de samme italienske kravene til Nexi, IVA og Garante, men med lokal logistikk og kundemønster. Se også WooCommerce-utvikler i Roma, WooCommerce-utvikler i Milano og WooCommerce-utvikler i Torino for hvordan oppsettet tilpasses der.

Etter lansering tar vedlikehold og support for WordPress i Firenze oppdateringer, sikkerhetskopier og overvåking.

#Start et WooCommerce-prosjekt i Firenze

Trenger butikken din i Firenze en kasse som tar Nexi og Stripe på alvor, regner IVA riktig, tåler Garantes personvernspraksis og lar deg styre frakten selv, ta kontakt for en uforpliktende gjennomgang. Vi ser på dagens oppsett, peker på den faktiske flaskehalsen og gir en ærlig vurdering av hva som bør gjøres først. Prisen settes individuelt etter omfang, og du får oversikten skriftlig før arbeidet starter.

For butikker og nettsteder som trenger en strukturert gjennomgang av risiko, er inngangen sikkerhetsrevisjon for WordPress.