WooCommerce Utvikler i Torino

En WooCommerce-butikk som selger bilreservedeler eller komponenter til underleverandører i Torino må håndtere tre ting som ikke står i standarddokumentasjonen til Woo: Nexi XPay eller Stripe IT i kassen med riktig 3DS2-flyt, IVA på 22 prosent skilt mellom B2C og B2B med partita IVA, og personvern som tåler ettersyn fra Garante per la protezione dei dati personali. Vi bygger og rydder opp i WooCommerce for bedrifter i Torino med utgangspunkt i nettopp disse kravene, ikke en generisk mal som siden lokaliseres med bynavn.

Torino er hovedsetet til Stellantis og et av Europas tyngste knutepunkter for bilindustri, reservedelsleverandører og aerospace-komponenter. Lingotto og Mirafiori-området samler fortsatt tusenvis av ingeniører og innkjøpere som bestiller reservedeler, verktøy og komponenter online. En kasse som ikke håndterer OE-nummer, tunge fraktsatser og B2B-fakturering, taper ordrer til konkurrenter som fortsatt tar imot bestillinger på telefon. Det er det praktiske utgangspunktet for arbeidet vårt.

#WooCommerce-utvikling i Torino

Torino-markedet er kresent. Italienske netthandlere, særlig innen bil og industri, forventer kasse med riktig IVA, betaling via Nexi eller Stripe IT, sporingslenke fra Poste Italiane eller BRT i e-posten, og produktsider der OE-nummer og kompatibilitet faktisk kan søkes. Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik en italiensk innkjøper eller verkstedkunde forventer, og å gjøre det på en måte som overlever oppdateringer av Woo, temaet og betalingstilleggene.

#Hva vi faktisk bygger

• Reservedelskatalog for bilindustri: OE-nummer og aftermarket-referanser som søkbare felt, kompatibilitet per merke og modell, tekniske datablad som nedlastbare vedlegg, og lagerstatus per SKU uten at katalogen kollapser under tusenvis av varianter
• B2B-kasse for underleverandører: partita IVA-validering mot VIES, rollebaserte priser for grossister, minste ordremengder, tilbudsforespørsel før kjøp og egne fraktsatser for tunge komponenter
• Nexi XPay og Stripe IT 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, priser vist inkludert IVA slik italienske forbrukere forventer, og OSS-flyt for grenseoverskridende EU-salg til verksteder i andre land
• Frakt med Poste Italiane, BRT og GLS Italy: fraktsoner innen Italia og til resten av EU, prisregler basert på vekt og volum for tunge deler, og fraktsedler/sporing koblet mot ordrebehandlingen
• Garante-tilpasset personvern: samtykkebanner etter italiensk praksis, cookie-kategorier, databehandleravtale, register over behandlingsaktiviteter og dokumentert slettelogikk for kundedata
• Tospråklig IT/EN-butikk: WPML eller Polylang for WooCommerce med riktig hreflang, separate URL-strukturer per språk, og checkout-felt tilpasset italiensk CAP-format og telefonnummer
• Utvidelser av WooCommerce REST API for hodeløs storefront, forhandlerportal eller integrasjon mot lagerstyring, med autentisering og idempotente betalingsstier

#Hvorfor italienske betalings- og katalogvalg styrer arkitekturen

I de fleste WooCommerce-prosjekter for Torino er det ikke produktkatalogen som er vanskelig, det er kassen og datastrukturen. Nexi XPay og Stripe IT oppfører seg ikke likt: Nexi 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 reservedelsbutikker der ordrer ble markert fullført på redirect tilbake fra 3DS, ikke på webhook, slik at avbrutte betalinger ga ordrer uten penger og feil lagerreservasjon på en enkelt OE-referanse. Den typen feil fanges bare med ende-til-ende-QA på selve betalingsstien.

Katalogen er den andre fellen. En verkstedkunde søker etter OE-nummer eller chassisnummer, ikke et produktnavn fra en markedsføringsavdeling. Når søket returnerer irrelevante treff eller katalogen laster alle varianter i én side, faller konverteringen blant innkjøpere som ellers ringer direkte til lageret. Vi bygger taksonomi og søk som speiler hvordan bilbransjen faktisk bestiller, med indekserte meta-felt og paginering som tåler kataloger på titusenvis av SKU-er.

Frakt er den tredje. En bremseskive eller girkasse veier mer enn et par sko, og fraktprisen kan ikke gjettes i kassen. Når Poste Italiane- eller BRT-API-et ikke er koblet inn, ser kunden enten feil fraktpris eller ingen fraktvalg, og forlater handlekurven. Vi setter opp fraktregler som henter pris og leveringstid per CAP og vektklasse, med reserveløsning når API-et svarer for sent.

#Markedet og miljøet i Torino

Torino er Piemontes industrielle tyngdepunkt. Stellantis har hovedkontor og forskningssenter i byen, og klyngen av underleverandører langs Corso Maroncelli, i Grugliasco og i det tidligere Mirafiori-området selger reservedeler, spesialverktøy og komponenter både til OEM og aftermarket. Ved siden av bilindustrien finnes aerospace-leverandører og IIT (Istituto Italiano di Tecnologia) som driver spinouts med tekniske produkter som selges direkte online. WordPress Meetup Torino møtes jevnlig, og mange deltakere jobber med nettbutikker for lokale industribedrifter eller agenturer som betjener dem.

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 som ellers bestiller via EDI eller telefon. Kundene våre i Torino spenner fra verksteder som selger reservedeler til forbrukere, til underleverandører som selger komponenter B2B til hele Europa, og selskaper som flytter fra Magento eller en lukket plattform over til WooCommerce for å eie egen kode. Fellesnevneren er at de trenger en butikk som tar Nexi og Stripe IT på alvor, regner IVA riktig, og lar kunden finne riktig del uten å ringe lageret.

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 betalingskrav dukket opp. Det fungerer helt til katalogen vokser forbi hva temaet tåler, 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: reservedelsstruktur og OE-felt, kasseflyt for B2B og B2C, aktive betalingstillegg (Nexi, Stripe IT), fraktsoner for tunge varer, IVA-regler, Garante-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 sporingslogikk, IVA-håndtering for B2C og B2B, Garante-dokumentasjon, 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 IT, refusjon og delvis refusjon, B2B-ordre med partita IVA, 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 Torino-butikker

• Nexi bekreftet på redirect, ikke webhook. En reservedelsbutikk 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.
• OE-søk returnerte feil deler. En underleverandør hadde lagt OE-nummer i produktbeskrivelsen i stedet for indekserte meta-felt. Søket fant delvis treff på tvers av tusenvis av SKU-er og tok flere sekunder. Vi flyttet OE-referanser til dedikerte meta-felt, la til server-side søk via REST, og paginerte kategorisider slik at katalogen lastet raskt igjen.
• Frakt for tunge deler gjettes i kassen. En butikk som solgte girkomponenter viste flat fraktpris uavhengig av vekt. Vi koblet BRT-API inn via woocommerce_package_rates, regnet volumvekt der pakken oversteg faktisk vekt, og la inn reserveløsning når API-et ikke svarte innen tidsfristen.
• IVA og partita IVA blandet sammen. En butikk som solgte både til verksteder og til privatpersoner viste feil pris i kassen for B2B-kunder med gyldig italiensk MVA-nummer. Vi skilte B2C- og B2B-flyten, satte riktig sats per kundetype og fikk fakturafeltene til å matche det Fatture in Cloud forventet.

#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 IT, 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, ERP eller prislistefiler fra leverandør, 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, søk og katalogstruktur som speiler hvordan bilbransjen bestiller, 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, behandles og lagres slik regelverket krever. Garante per la protezione dei dati personali er den italienske tilsynsmyndigheten under personvernforordningen, og butikker som selger til italienske forbrukere 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 artikkel 17. Ved et personvernbrudd gjelder artikkel 33: varsling til tilsynsmyndigheten uten ugrunnet opphold, med 72 timer som ytre frist når bruddet medfører risiko for registrertes rettigheter. Garante har utstedt sanksjoner mot italienske virksomheter for utilstrekkelig sikkerhet, for sent varslet brudd og for cookie-praksis som ikke oppfyller kravene. Vi bygger logger, tidslinje og endringslogg inn i arkitekturen, slik at kunden kan vurdere om Garante må varsles.

#Ytelse, målt der det teller

Core Web Vitals påvirker både rangering og konvertering, og på en reservedelsnettbutikk er det kasse-, produkt- og søkesidene som betyr noe. Vi jobber mot lav LCP gjennom optimalisert kritisk renderingsvei og forhåndsinnlasting av produktbilder 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 Torino-butikker stiller oss

Setter dere opp Nexi og Stripe IT i kassen? Ja. Vi integrerer Nexi XPay og Stripe IT 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 B2B med partita IVA riktig? 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 italiensk MVA-nummer fra ordinær forbrukersalg.

Støtter dere OE-nummer og reservedelskataloger? Ja. Vi bygger taksonomi og søk med indekserte meta-felt for OE-referanser og kompatibilitet, tekniske datablad som vedlegg, og paginering som tåler kataloger med titusenvis av SKU-er uten at produktsidene kollapser.

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

Hva med Garante og personvern? Vi setter opp samtykkehåndtering etter italiensk praksis, dokumenterer behandlingsgrunnlag og datalagring innen EØS, og bygger slettelogikk for kundedata i tråd med personvernforordningen.

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

#Integrasjoner en italiensk bilreservedelsnettbutikk faktisk trenger

En italiensk reservedelsnettbutikk på WooCommerce ender som regel opp med de samme fire koblingene: betaling med Nexi og Stripe IT, frakt med Poste Italiane eller BRT inkludert sporingslenke, 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. For underleverandører i Torino kommer ofte en femte kobling: ERP eller lagerstyring som speiler reservedelslager og avtalepriser mot Stellantis-kjeden eller aftermarket-kanaler.

#Betaling: Nexi XPay og Stripe IT

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 IT kan embedded, men webhook gjelder fortsatt. Stripe tillater embedded betalingsskjema for internasjonale kunder som betaler med utenlandske kort, 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.

Reserver nå, trekk ved forsendelse. Italiensk praksis for reservedeler er ofte å reservere beløpet ved kjøp og trekke det når varen sendes, særlig når lageret må verifisere at riktig OE-referanse finnes på hylla. Integrasjonen må skille tydelig mellom autorisasjon, belastning, delvis belastning, annullering og refusjon, og hver av disse må kunne utløses både fra Woo-admin og fra en bakgrunnsjobb.

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 Italy

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. For bremseskiver, dekk og girkasser betyr det at fraktreglene må ta høyde for både vekt og mål, ikke bare antall enheter i handlekurven. Svarene mellomlagres i transienter per CAP 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, særlig når verksteder bestiller deler som skal være på plass til en avtalt service.

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. For reservedeler gjelder unntak når delen er spesialbestilt eller montert, og det bør reflekteres i produktinformasjonen og kassen.

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

B2B betyr e-faktura via SDI. Selger butikken til italienske bedrifter med partita IVA, skal fakturaen sendes elektronisk via Sistema di Interscambio (SDI), med riktig XML-format og mottakers MVA-nummer. Det er en egen flyt i kassen: felt for partita IVA, validering mot VIES, og et annet dokumentløp enn forbrukersalget. Underleverandører i Torino som selger til OEM-kjeder møter dette daglig.

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 mens verkstedet venter på en kritisk reservedel.

#Hvorfor ordrestatus må settes server-til-server

Takkesiden er et løfte, ikke et bevis. Kunden kan miste dekning i Mirafiori-området, 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 IT 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 Torino, 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 Bologna og WooCommerce-utvikler i Roma for hvordan oppsettet tilpasses der.

Etter lansering tar vedlikehold og support for WordPress i Torino 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:

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

#Start et WooCommerce-prosjekt i Torino

Trenger butikken din i Torino en kasse som tar Nexi og Stripe IT på alvor, regner IVA riktig, lar kunden finne riktig reservedel uten å ringe lageret, og tåler Garante-ettersyn, 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 Torino.