WooCommerce Utvikler i Bologna

En WooCommerce-butikk som selger til italienske bedrifter i Emilia-Romagna må håndtere tre ting som ikke står i standarddokumentasjonen til Woo: Partita IVA og B2B-fakturering i kassen, betaling via Nexi eller Stripe IT med riktig 3DS-flyt, og personvern som tåler en Garante-vurdering. Vi bygger og rydder opp i WooCommerce for bedrifter i Bologna med utgangspunkt i nettopp disse kravene, ikke en generisk mal som siden lokaliseres med bynavn.

Emilia-Romagna er et av Italias tyngste industriområder: maskinleverandører, emballasje, næringsmiddelteknologi og underleverandører til bilindustrien selger ofte B2B med reservdelkataloger, rollebaserte priser og ordre som må matche ERP. Det er det praktiske utgangspunktet for arbeidet vårt i Bologna.

#WooCommerce-utvikling i Bologna

Bologna-markedet er kresent. Italienske netthandlere, særlig i B2B, forventer kasse med Partita IVA-felt, tydelig IVA-oppsplitting, betaling via lokale gatewayer og dokumentasjon som holder for regnskap og personvern. Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik en italiensk bedriftskunde forventer, og å gjøre det på en måte som overlever oppdateringer av Woo, temaet og betalingstilleggene.

#Hva vi faktisk bygger

• B2B-kasse for Emilia-Romagna: Partita IVA-validering, rollebaserte priser, minste ordremengder, tilbudsforespørsel før kjøp og egne fraktsatser for grossistkunder
• Nexi XPay og Stripe IT i kassen: kort med 3D Secure, engangsbetaling og gjentakende trekk der abonnement er aktuelt, med testmatrise per gateway og webhook-bekreftelse før ordre markeres betalt
• Satispay og PayPal ved siden av kort der trafikken krever det, med riktig rekkefølge i kassen for italiensk mobiltrafikk
• IVA-oppsett for italiensk handel: standardsats, reduserte satser der de gjelder, priser vist med IVA slik forbrukere forventer, og OSS-flyt for grenseoverskridende EU-salg
• Frakt med BRT, GLS Italy og Poste Italiane: fraktsoner, vekt- og volumregler, hentested der leverandøren støtter det, og sporingsnummer i forsendelsesvarselet
• Garante-tilpasset personvern: samtykkebanner etter italiensk praksis, cookie-kategorier, databehandleravtale, register over behandlingsaktiviteter og dokumentert slettelogikk for kundedata
• Utvidelser av WooCommerce REST API for headless storefront, forhandlerportal eller POS, med autentisering og idempotente betalingsstier

#Hvorfor italienske betalings- og B2B-valg styrer arkitekturen

I de fleste WooCommerce-prosjekter for Bologna er det ikke produktkatalogen som er vanskelig, det er kassen. Nexi og Stripe IT oppfører seg ikke identisk: redirect-flyt, 3DS-vindu og webhook-bekreftelse krever at ordrestatus ikke settes til betalt før gatewayen faktisk har bekreftet. Vi har sett butikker der ordrer ble markert fullført på redirect tilbake, ikke på webhook, slik at avbrutte 3DS-forsøk ga ordrer uten penger. Den typen feil fanges bare med ende-til-ende-QA på selve betalingsstien.

B2B er den andre fellen. En grossistkunde i Modena eller Parma forventer å logge inn med bedriftskonto, se egne priser og få Partita IVA på fakturaen. Når dette mangler, faller konverteringen blant innkjøpere som ellers bestiller via telefon og e-post. Vi setter opp rollebasert prising, B2B-registrering og felt som trengs for senere fakturering, uten å blande det sammen med forbrukerkassen.

#Markedet og miljøet i Bologna

Bologna er administrasjonssenteret i Emilia-Romagna og huser Universitetet i Bologna, Europas eldste universitet, sammen med et tett nettverk av industribedrifter langs A1 og i byer som Modena, Reggio Emilia og Parma. For en netthandler betyr det at konkurransen om italienske og eksportkunder er hard, og at en kasse som ikke håndterer B2B-felt, IVA og betaling lokalt ikke blir tatt alvorlig av innkjøpere.

Kundene våre i Bologna spenner fra produsenter av emballasje- og prosessmaskiner som selger reservdeler på nett, til merkevarer i næringsmiddelsektoren som flytter fra lukket plattform til WooCommerce for å eie egen kode. Fellesnevneren er at de trenger en butikk som tar Nexi eller Stripe IT på alvor, regner IVA riktig og lar dem styre B2B-priser og frakt 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 trafikken øker, et betalingstillegg slutter å bli vedlikeholdt, eller Garante stiller spørsmål ved samtykkeloggen. 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.

WordPress Meetup Bologna er et naturlig sted å møte lokale utviklere når et prosjekt krever samarbeid på stedet. For oss er det like viktig at leveransen dokumenterer gateway-valg, Garante-tilpasning og B2B-flyt slik at teamet ditt kan drifte butikken etter overlevering.

#Slik jobber vi gjennom et prosjekt

1. Kasse- og katalogrevisjon. Vi går gjennom dagens WooCommerce-butikk: produkttaksonomi, B2B- og B2C-kasseflyt, aktive betalingstillegg (Nexi, Stripe IT, Satispay), fraktsoner, IVA-regler, samtykkeoppsett 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 B2B-fraktlogikk, IVA- og OSS-håndtering, 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, B2B-registrering og prisvisning, 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 Bologna-butikker

• Nexi markerte ordrer betalt på redirect. En maskinleverandør i Emilia-Romagna fikk ordrer satt til betalt 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.
• B2B-kasse uten Partita IVA. En grossist solgte til bedrifter i hele regionen, men kassen behandlet alle som forbrukere. Vi la inn bedriftsregistrering, Partita IVA-felt med validering, rollebaserte priser og egen checkout-mal for innloggede grossister, uten å ødelegge B2C-flyten.
• Treg kasse på mobil. En butikk med tungt tema og mange aktive tillegg hadde merkbar forsinkelse før betalingsknappen var klikkbar. Vi startet med Lighthouse, WP-CLI-profil og Query Monitor på kassesiden, fant cart-fragment-kall og autoloadede options som var skyld i mesteparten, og fjernet flaskehalsene én etter én i stedet for å installere enda et caching-tillegg.

#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 XPay og Stripe IT 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.

På butikker med High-Performance Order Storage deklarerer egen plugin-kode kompatibilitet via FeaturesUtil::declare_compatibility på before_woocommerce_init, og all lesing og skriving av ordredata går gjennom wc_get_order og CRUD-metodene i stedet for direkte postmeta-kall.

#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, B2B-felt som matcher det italienske innkjøpsmarkedet forventer, IVA håndtert i selve flyten i stedet for manuelt, Garante-tilpasset samtykke dokumentert i runbooken, 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 etter praksis Garante forventer: tydelig informasjon før samtykke, granulære cookie-valg, databehandleravtale og personvern bygget inn i arkitekturen.

For italienske nettbutikker betyr det i praksis også at kundedata fra kortbetalinger, Partita IVA og leveringsadresser behandles og lagres med dokumentert formål, lagringstid og slettemekanisme. Vi unngår unødvendig lagring av betalingsdata i Woo-databasen; token og referanser fra Nexi eller Stripe holdes i metadata med gateway-navn, slik at refusjon fra admin ikke blir et gjettespill.

#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. 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 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 Bologna-butikker stiller oss

Setter dere opp Nexi og Stripe IT i kassen? Ja. Vi integrerer engangsbetaling og gjentakende trekk der det passer, tester autorisasjon, belastning, refusjon og delvis refusjon mot testmiljø før lansering, og dokumenterer webhook-endepunkter og idempotens. Bekreftelse av betaling skjer på webhook, ikke på redirect tilbake til butikken.

Kan dere håndtere B2B med Partita IVA? Ja. Vi setter opp bedriftsregistrering, Partita IVA-felt med validering, rollebaserte priser og egne fraktregler for grossister, uten å blande B2B- og B2C-flyten i samme kasse uten kontroll.

Hvordan forholder dere dere til Garante og GDPR? Vi bygger samtykke, cookie-kategorier og dokumentasjon som matcher italiensk praksis, inkluderer databehandleravtale der det kreves, og unngår unødvendig lagring av betalings- og identitetsdata i Woo utover det gatewayen krever.

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 Bologna? Ja. Vi har tyngdepunktet i Emilia-Romagna og Italia, men leverer til netthandlere i hele EU og til italienske butikker drevet fra utlandet.

#Integrasjoner en italiensk nettbutikk faktisk trenger

En italiensk nettbutikk på WooCommerce ender som regel opp med de samme fire koblingene: betaling med Nexi eller Stripe IT, frakt med BRT eller GLS inkludert hentested der det støttes, regnskap i Fatture in Cloud, TeamSystem eller tilsvarende, 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 XPay ved siden av Stripe IT

Nexi er fortsatt standardvalget for mange italienske bedrifter. Integrasjonen bygges som en vanlig WC_Payment_Gateway-klasse der process_payment returnerer redirect til 3DS eller hosted side, mens fullføringen skjer i webhook-håndtereren. Ordren får payment_complete først når Nexi har bekreftet belastningen.

Stripe IT dekker internasjonale kort og Apple Pay. 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.

Satispay som mobilalternativ. Der trafikken er tung på mobil, kan Satispay stå ved siden av kort som et raskt valg. Det krever egen testmatrise og egen webhook-logikk, ikke bare en ekstra knapp i samme flyt som Nexi.

#Frakt: BRT, GLS og Poste Italiane

Fraktpriser hentes fra leverandørens API der det finnes. 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.

Hentested lagres som identifikator. Kunden velger et konkret utleveringssted i kassen, og valget må lagres på ordren som en ID fra leverandøren, ikke som fritekst. Fraktsedlene genereres senere mot den identifikatoren.

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.

#Regnskap og B2B-dokumentasjon

Salget bokføres én gang, med riktig IVA-kode. Integrasjonen mot italiensk regnskap oppretter kunde og salgsdokument, mapper hver produktgruppe til riktig IVA-kode, og skriver referansenummer tilbake på ordren. Eksistensen av dette nummeret hindrer dobbeltbokføring ved en ny kjøring.

B2B krever Partita IVA på ordren. Feltet valideres i kassen, lagres på ordren og følger med til regnskap og eventuell elektronisk fakturering. Uten dette må regnskapet manuelt etterfølge hver ordre.

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, lukke nettleseren under 3DS, eller bytte app mens betalingen fullføres. 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å. Callback-endepunktet skal først verifisere signaturen på varselet, 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.

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 og dobbelt kunde-e-post.

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.

Testing gjøres på feilstiene. Testmatrisen dekker avbrutt 3DS, varsel som kommer to ganger, varsel 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.

#WooCommerce i andre italienske byer

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

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

#Start et WooCommerce-prosjekt i Bologna

Trenger butikken din i Bologna en kasse som tar Nexi og Stripe IT på alvor, håndterer B2B med Partita IVA og tåler Garante-kravene, 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. Omfanget og investeringen avtales individuelt etter kartlegging, 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.