WooCommerce Utvikler i Roma

En WooCommerce-butikk for turisme eller offentlig sektor i Roma må håndtere tre ting som ikke står i standarddokumentasjonen til Woo: Nexi eller Stripe i kassen med 3DS2, IVA på 22 prosent regnet riktig, og personverndokumentasjon som tåler ettersyn fra Garante per la protezione dei dati personali. Vi bygger og rydder opp i WooCommerce for aktører i Roma med utgangspunkt i nettopp disse kravene, ikke en generisk mal som siden lokaliseres med bynavn.

Roma tar imot over ti millioner besøkende i året, og mange av dem bestiller billetter, guidede turer og overnatting på nett før de lander på Fiumicino. En kasse som ikke tåler påsketrafikk, bekrefter betaling på redirect i stedet for webhook, eller mangler informasjonsskjema på italiensk, taper salg nettopp når etterspørselen er størst. Det er det praktiske utgangspunktet for arbeidet vårt.

#WooCommerce-utvikling i Roma

Roma-markedet er sesongdrevet. Italienske og internasjonale kunder forventer rask kasse på mobil, tydelig pris med IVA inkludert, betaling med kort via Nexi eller Stripe, og produktsider som laster raskt selv med mange bilder fra Colosseum, Vatikanet eller Forum Romanum. Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik en turistkunde eller en offentlig innkjøper forventer, og å gjøre det på en måte som overlever oppdateringer av Woo, temaet og betalingstilleggene.

#Hva vi faktisk bygger

• Nexi XPay og Stripe i kassen: kort med 3DS2, Apple Pay og Google Pay der det passer, og test av webhooks for autorisasjon, belastning, refusjon og delvis refusjon mot testmiljø for begge gatewayer
• IVA-oppsett for italiensk handel: 22 prosent standardsats, reduserte satser der de gjelder, og priser vist inkludert IVA slik italienske forbrukere forventer, med egen flyt for B2B med partita IVA og offentlige oppdragsgivere
• Flerspråklig IT/EN-butikk for turister: WPML eller Polylang for WooCommerce med riktig hreflang, separate URL-strukturer per språk, og checkout-felt tilpasset italiensk CAP-format og internasjonale telefonnumre
• Tidsbasert produktlogikk for billetter og turer: dato- og klokkeslettvalg, kapasitetsgrenser per slot, og ordrebehandling som skiller mellom umiddelbar bekreftelse og manuell godkjenning der det kreves
• Frakt med Poste Italiane og BRT: fraktsoner innen Italia og til resten av EU, prisregler basert på vekt og volum, og fraktsedler/sporing koblet mot ordrebehandlingen for fysiske suvenirer og reiseutstyr
• Garante-tilpasset personvern: samtykkehåndtering for cookies og markedsføring, databehandleravtale, informasjonsskjema på italiensk, dokumentasjon som tåler ettersyn fra Garante, og datalagring innen EU/EØS
• Fatturazione elettronica mot PA der det gjelder: felt for Codice Destinatario, CIG/CUP ved offentlige anskaffelser, og XML-faktura via SDI (Sistema di Interscambio) i stedet for PDF i e-post
• Utvidelser av WooCommerce REST API for hodeløs storefront, mobilapp eller B2B-portal, med autentisering og idempotente betalingsstier

#Hvorfor italienske betalings- og personvernvalg styrer arkitekturen

I de fleste WooCommerce-prosjekter for Roma er det ikke produktkatalogen som er vanskelig, det er kassen og etterlevelsen. Nexi og Stripe oppfører seg ikke likt: Nexi XPay bruker ofte redirect til bank eller 3DS2-popup, Stripe kan kjøre embedded Elements, men begge krever at ordrestatus ikke settes til betalt før webhook bekrefter. Vi har sett turistbutikker der ordrer ble markert fullført på redirect tilbake fra 3DS, ikke på webhook, slik at avbrutte betalinger ga ordrer uten penger og feil kapasitetsreservasjon på en guidet tur. Den typen feil fanges bare med ende-til-ende-QA på selve betalingsstien.

Personvern er den andre fellen. Garante er Italias uavhengige tilsynsmyndighet for personvern, og butikker som samler e-post, telefon og betalingsdata fra turister må ha dokumentasjon som tåler ettersyn: behandlingsgrunnlag, informasjonsskjema på italiensk, samtykke for cookies og nyhetsbrev, og sletting av kundedata på forespørsel i tråd med personvernforordningen artikkel 17. Vi bygger dette inn i arkitekturen, ikke som et ettertankevedlegg når sesongen allerede er i gang.

#Markedet og miljøet i Roma

Roma er Italias administrative og turistiske tyngdepunkt. Offentlige museer, kulturinstitusjoner og regionale enti pubblici selger i økende grad tjenester og varer online, samtidig som private aktører tilbyr guidede turer, matopplevelser og overnatting til et internasjonalt publikum. Påskeuken, sommersesongen og juleperioden sender trafikk som kan oversteige vanlig månedssalg på få dager. En nettbutikk som fungerer fint i januar kan fortsatt falle sammen når Colosseum-billetter og Vatikan-turer selges parallelt fra mobilbrukere over hele verden.

WordPress Roma møtes jevnlig via Meetup, og mange av deltakerne jobber med nettbutikker for lokale aktører eller agenturer som betjener turisme og offentlig sektor. Roma Startup Hub samler gründere som bygger digitale tjenester for besøksnæringen. For en netthandler betyr det at konkurransen om italienske og internasjonale kunder er hard, og at en treg eller halvfungerende kasse ikke blir tilgitt når sesongen er på sitt høyeste.

Kundene våre i Roma spenner fra private turoperatører som selger billetter og guidede turer, til offentlige eller semi-offentlige aktører som må fakturere elektronisk mot PA og oppfylle Legge Stanca-krav til tilgjengelighet. Fellesnevneren er at de trenger en butikk som tar Nexi og Stripe på alvor, regner IVA riktig, tåler trafikktopper, og har personverndokumentasjon som Garante kan etterspørre.

Mange av disse butikkene har vokst organisk over flere år: et visuelt tema fra en kjøpt mal, et halvt dusin tillegg som overlapper, og en kasse som er lappet sammen i takt med at nye betalingskrav dukket opp. Det fungerer helt til påsketrafikken kommer, et betalingstillegg slutter å bli vedlikeholdt, eller Garante stiller spørsmål om cookies og datalagring. 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: produktstruktur for billetter og tjenester, kasseflyt, aktive betalingstillegg (Nexi, Stripe), Poste Italiane-fraktsoner, IVA-regler, IT/EN-språkstruktur, Garante-dokumentasjon 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 sporingslogikk, IVA-håndtering for B2C og B2B/PA, fakturazione elettronica der det gjelder, 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å Nexi og Stripe, refusjon og delvis refusjon, 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 Roma-butikker

• Nexi bekreftet på redirect, ikke webhook. En turistbutikk som solgte guidede turer markerte ordrer betalt når kunden kom tilbake fra 3DS, ikke når Nexi sendte webhook. Vi flyttet bekreftelsen til callback-endepunktet, la inn idempotens slik at dobbel webhook ikke ga dobbel ordre, og satte opp full testmatrise for autorisasjon, belastning og refusjon.
• Treg kasse under påsketrafikk. En billettbutikk med tungt tema og mange produktbilder hadde flere sekunders forsinkelse før betalingsknappen var klikkbar. 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.
• Garante etterspurte cookie-dokumentasjon. En offentlig nær butikk hadde markedsføringspixels aktive uten samtykkebanner og uten behandlingsprotokoll på italiensk. Vi satte opp samtykkehåndtering med granulære valg, oppdaterte informasjonsskjemaet, og dokumenterte behandlingsgrunnlag og datalagring innen EØS slik at ettersynet kunne besvares skriftlig.
• Faktura mot PA manglet SDI-flyt. En aktør som solgte tjenester til offentlige oppdragsgivere sendte PDF-fakturaer i e-post i stedet for XML via SDI. Vi la inn felt for Codice Destinatario og CIG/CUP i kassen, koblet ordre mot Fatture in Cloud, og skilte forbrukersalg fra PA-fakturering i samme butikk.

#Belastningstest før sesongtopper

Trafikktopper i Roma er forutsigbare, men ikke trivielle. Påskeuken, sommersesongen og juleperioden sender internasjonal trafikk til turistaktører som ellers selger jevnt gjennom året. Vi kjører belastningstest mot checkout og produktsider før disse vinduene, verifiserer at object cache og CDN faktisk er aktive, og at Action Scheduler-køen ikke blokkerer kasseforespørsler når ordre strømmer inn. En butikk som fungerer fint i februar kan fortsatt falle sammen når Vatikan-billetter og Colosseum-turer selges parallelt fra tusenvis av mobilbrukere.

#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 og produktbilder. Betaling går via Nexi XPay og Stripe, alltid med 3DS2 på kortbetalinger. Hosting ligger innen EU/EØS med databehandling som tåler GDPR-ettersyn fra Garante. Tunge jobber, som synkronisering mot lager, regnskap eller billettkapasitet, 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 håndtert i selve flyten i stedet for manuelt, personverndokumentasjon som tåler Garante-ettersyn, 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.

For italienske nettbutikker betyr det i praksis at kundedata fra Nexi- og Stripe-betalinger, samt navn og adresse for frakt eller faktura, behandles og lagres slik regelverket krever. Garante per la protezione dei dati personali er den italienske tilsynsmyndigheten, og butikker som selger til italienske forbrukere eller samler data fra turister bør ha dokumentasjon som tåler ettersyn: behandlingsgrunnlag, informasjonsskjema på italiensk, datalagring innen EØS, og sletting av kundedata på forespørsel i tråd med personvernforordningen artikkel 17. Offentlige eller semi-offentlige aktører må i tillegg vurdere Legge Stanca-krav til tilgjengelighet (WCAG 2.1) og sikkerhetskopiering av data som omfattes av nasjonal lovgivning.

#Ytelse, målt der det teller

Core Web Vitals påvirker både rangering og konvertering, og på en turist- eller offentlig nettbutikk er det kasse-, produkt- og landingssider som betyr noe. 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 fra Nexi og Stripe), 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 Roma-butikker stiller oss

Setter dere opp Nexi og Stripe i kassen? Ja. Vi integrerer Nexi XPay og Stripe med kort, Apple Pay og Google Pay 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 fakturering mot offentlige oppdragsgivere? Ja. Vi setter 22 prosent standardsats og reduserte satser der de gjelder, viser priser inkludert IVA slik italienske forbrukere forventer, og skiller B2B-flyten for kunder med gyldig partita IVA og PA-fakturering via SDI der det kreves.

Hvordan håndterer dere Garante og GDPR? Vi bygger samtykkehåndtering for cookies og markedsføring, informasjonsskjema på italiensk, databehandleravtale og dokumentasjon for behandlingsgrunnlag og datalagring innen EØS, slik at ettersyn fra Garante kan besvares skriftlig.

Tåler butikken trafikk under påske og sommersesong? Vi tester checkout og produktsider mot forventet topp før sesongvinduene, verifiserer caching og køhåndtering, og dokumenterer hva som må skaleres hvis trafikken vokser videre.

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 Roma? Ja. Vi har tyngdepunktet i Roma-miljøet, men leverer til netthandlere i hele Italia og til italienske aktører drevet fra utlandet.

#Integrasjoner en italiensk turisme- og offentlig nettbutikk faktisk trenger

En italiensk nettbutikk for turisme eller offentlig sektor på WooCommerce ender som regel opp med de samme fire koblingene: betaling med Nexi og Stripe, frakt med Poste Italiane inkludert sporingslenke der fysiske varer selges, 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

3DS2 er en avbrudd, ikke et skjema. Integrasjonen bygges slik at kunden redirectes til bank eller 3DS2-challenge, og alt som skjer etterpå er utenfor nettleserens kontroll. Derfor implementeres Nexi-gatewayen som en vanlig WC_Payment_Gateway-klasse der process_payment returnerer en redirect og ingenting mer, mens fullføringen skjer i webhook-håndtereren. Ordren får payment_complete først når Nexi har bekreftet.

Stripe Elements kan embedded, men webhook gjelder fortsatt. Stripe tillater embedded betalingsskjema, men ordrestatus skal fortsatt bekreftes via webhook, ikke via at kunden når takkesiden. 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.

Turister betaler med utenlandske kort. Stripe dekker ofte internasjonale kort bedre enn lokale gatewayer alene, mens Nexi er vanlig blant italienske forbrukere og offentlige innkjøpere. Rekkefølgen i kassen bør reflektere hvem som faktisk kjøper: internasjonale turister på engelsk produktside trenger kortbetaling som fungerer med utenlandsk utstedte kort og 3DS2 uten italiensk feilmelding.

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 og BRT

Fraktpriser hentes, de gjettes ikke. Poste Italiane og BRT gir pris og leveringstid per produkt og CAP. 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 CAP og vektklasse, fordi kassen ikke kan vente på et eksternt kall ved hver oppdatering av handlekurven.

Digitale produkter trenger ikke frakt, men trenger leveringslogikk. Billetter og turer leveres som PDF, QR-kode eller bekreftelse på e-post. Ordren må skille mellom fysiske og digitale linjer slik at frakt ikke beregnes på en Vatikan-tur, og slik at kapasitetsreservasjon skjer før betaling bekreftes.

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, særlig når internasjonale kjøpere ikke kjenner butikkens supportrutiner.

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.

Retur etter diritto di recesso. EU-forbrukere har 14 dagers angrerett. Returskjema og returetikett bør kobles til ordrestatus slik at lageret ser hva som kommer tilbake, uten at kundeservice manuelt oppdaterer hver retur.

#Regnskap: Fatture in Cloud eller TeamSystem

Salget bokføres én gang, med riktig IVA-kode. Både 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.

Avstemming er mot utbetaling, ikke mot ordre. Nexi og Stripe 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.

PA-faktura betyr SDI, ikke PDF. Selger butikken til offentlige oppdragsgivere i Italia, skal fakturaen sendes elektronisk via SDI med riktig XML-format, Codice Destinatario og eventuelt CIG/CUP fra anskaffelsesdokumentet. Det er en egen flyt i kassen: felt for partita IVA og Codice Destinatario, validering mot VIES, og et annet dokumentløp enn forbrukersalget.

Oppbevaringsplikt. Bokføringspliktig dokumentasjon skal oppbevares i ti år etter regnskapsårets slutt i Italia. I praksis betyr det at butikken ikke er regnskapssystemet: WooCommerce er kilden, Fatture in Cloud eller TeamSystem er arkivet, og integrasjonen må overføre nok informasjon til at arkivet er komplett uten oppslag i databasen til nettbutikken.

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 midt i en sesongtop.

#Personvern: Garante og GDPR i praksis

Informasjonsskjema på italiensk er et krav, ikke en oversettelse. Turister kan handle på engelsk, men italienske forbrukere og Garante forventer personvernerklæring på italiensk som beskriver behandlingsgrunnlag, mottakere, lagringstid og rettigheter etter artikkel 13 og 14 i personvernforordningen.

Cookies krever samtykke før sporing. Markedsføringspixels og analyseverktøy skal ikke lastes før brukeren har gitt samtykke via et banner med granulære valg. Garante har gitt bøter til aktører som satte cookies uten gyldig samtykke, og butikker i turismen er et vanlig ettersynsmål fordi de samler data fra et stort internasjonalt publikum.

Databehandleravtale med Nexi, Stripe og hosting. Hver leverandør som behandler personopplysninger på vegne av butikken må ha signert databehandleravtale, og underleverandørkjeden (hosting, CDN, e-post) må dokumenteres. Vi kartlegger dette i leveransedokumentasjonen, ikke som et internt notat.

Sletting og dataportabilitet. Kunder kan be om sletting eller utlevering av data. WooCommerce lagrer ordrehistorikk som ofte må beholdes av regnskapsgrunner, så slettingslogikken må skille mellom data som kan anonymiseres og data som må oppbevares i henhold til bokføringsloven.

#Hvorfor ordrestatus må settes server-til-server

Takkesiden er et løfte, ikke et bevis. Kunden kan miste dekning på metroen i Roma, lukke bankappen etter 3DS, 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 Nexi eller Stripe er en hendelse som skjer uansett, og det er den ordrestatusen skal henge på.

Verifiser først, kvitter raskt, jobb etterpå. Webhook-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. Webhook-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 Nexi og Stripe 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 3DS i bankappen, webhook som kommer to ganger, webhook som kommer i feil rekkefølge, forsinket webhook, 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.

#WooCommerce i andre italienske byer

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

Etter lansering tar vedlikehold og support for WordPress i Roma oppdateringer, sikkerhetskopier og overvåking. Nordiske huber sammenligner ofte med vedlikehold i Stockholm og vedlikehold i København.

#Andre europeiske byer

Samme WooCommerce-leveranse finnes i flere europeiske byer, med lokalt tilpasset betaling og MVA/IVA:

• Paris - WooCommerce-utvikler i Paris
• Berlin - WooCommerce-utvikler i Berlin
• Amsterdam - WooCommerce-utvikler i Amsterdam
• Barcelona - WooCommerce-utvikler i Barcelona

#Start et WooCommerce-prosjekt i Roma

Trenger butikken din i Roma en kasse som tar Nexi og Stripe på alvor, regner IVA riktig, tåler trafikk under påske og sommersesong, og har personverndokumentasjon som Garante kan etterspørre, 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 løpende oppfølging etter lansering, er inngangen vedlikehold og support i Roma.