WooCommerce Utvikler i Hamburg

En WooCommerce-butikk som selger til tyske kunder fra Hamburg må håndtere mer enn produktkatalog og kasse: Button-Lösung med korrekt prisvisning, Impressum og Datenschutzerklärung som tåler BfDI-praksis, MwSt regnet riktig, og betaling via Stripe DE slik tyske netthandlere forventer. Vi bygger og rydder opp i WooCommerce for bedrifter i Hamburg med utgangspunkt i nettopp disse kravene, ikke en generisk mal som bare får bynavn byttet ut.

Hamburg er Tysklands største havneby og et av de viktigste knutepunktene for logistikk og maritim handel i Europa. Havnen håndterer millioner av containere årlig, og rundt den vokser det frem B2B-leverandører, reservedelsbutikker og grossistportaler som selger alt fra skipsutstyr til emballasje og IT-utstyr til logistikkbedrifter. En kasse som fungerer for forbrukerhandel men bryter sammen når en bedriftskunde bestiller med USt-IdNr. og levering til havneterminal, er typisk feil vi ser når en Hamburg-leverandør vokser raskere enn teknologien.

#WooCommerce-utvikling i Hamburg

Tyske netthandlere er vant til tydelige totalpriser inkludert MwSt, flere betalingsvalg i kassen og en enkel returprosess innenfor angrefristen. I Hamburg legger logistikkbransjen et ekstra lag på toppen: B2B-kunder forventer faktura med omvendt avgiftsplikt, leveringstider knyttet til havneoperasjoner og sporbarhet som matcher det de kjenner fra frakt- og sporingssystemer. Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik en tysk kunde forventer, og å gjøre det på en måte som overlever oppdateringer av Woo, temaet og betalingstilleggene.

#Hva vi faktisk bygger

• Stripe DE i kassen: kortbetaling med 3D Secure, SEPA Direct Debit der det passer, og webhook-bekreftelse av betaling før ordren settes til betalt, testet mot Stripe sitt testmiljø med full matrise for autorisasjon, belastning, refusjon og delvis refusjon
• Klarna og PayPal ved siden av Stripe, med riktig rekkefølge i kassen for tysk trafikk og testkort per gateway
• MwSt-oppsett for tysk handel: 19 prosent standardsats, 7 prosent redusert sats på matvarer og bøker, og priser vist inkludert MwSt slik tyske forbrukere forventer under Button-Lösung
• OSS-håndtering for butikker som selger på tvers av EU: riktig MwSt-sats per destinasjonsland over terskelen, og fakturering som matcher One-Stop-Shop-rapporteringen
• B2B-flyt for logistikk- og maritim leverandører: USt-IdNr.-validering mot EU VIES, omvendt avgiftsplikt der det gjelder, minste ordremengder og rollebaserte priser for grossistkunder
• Frakt med DHL, Hermes og DPD: fraktsoner basert på postnummer og vekt, pakkeboks som leveringsvalg, og fraktsedler/sporing koblet mot ordrebehandlingen, inkludert leveringsvinduer for havne- og terminalleveranser der det er avtalt
• Widerrufsrecht bygget inn i flyten: returskjema, riktig informasjon i ordrebekreftelse og e-post, slik at den lovpålagte 14-dagersfristen ikke blir en manuell jobb for kundeservice
• Impressum, Datenschutzerklärung og samtykkehåndtering tilpasset GDPR og BfDI-praksis, med dokumentert databehandleravtale mot Stripe, fraktleverandører og andre tredjeparter
• Utvidelser av WooCommerce REST API for headless storefront, mobilapp, POS eller kobling mot lager- og ERP-systemer, med autentisering og idempotente betalingsstier

#Hvorfor havne- og logistikkhandel styrer arkitekturen

I de fleste WooCommerce-prosjekter for Hamburg er det ikke produktkatalogen som er vanskelig, det er kassen og ordrebehandlingen. En reservedelsbutikk som selger til skipsverft og logistikkbedrifter trenger B2B-flyt med USt-IdNr., omvendt MwSt og faktura som matcher det regnskapsføreren forventer. Samme butikk kan også selge til forbrukere med ordinær MwSt og Klarna. To parallelle flyt som ikke deler logikk, gir feil MwSt på ordre og avviste fakturaer i Lexoffice eller sevDesk.

Stripe DE oppfører seg annerledes enn en generisk Stripe-konto satt opp for et annet land: valuta, MwSt-visning, SEPA-mandat og webhook-signaturer må matche det tyske merchant-oppsettet. Vi har sett butikker i Hamburg-området der ordrer ble markert fullført på redirect tilbake fra Stripe, ikke på webhook, slik at avbrutte betalinger ga ordrer uten penger. Den typen feil fanges bare med ende-til-ende-QA på selve betalingsstien.

Frakt er den andre fellen. En tysk kunde forventer å velge DHL Paketshop eller Hermes Paketshop i kassen, ikke bare «standard frakt». For B2B-leveranser til havneområdet kan leveringsvinduer og spesialadresser være en del av avtalen. Når dette mangler, faller konverteringen på mobil og kundeservice får telefoner om leveringstid. Vi setter opp fraktsonene og leveringsvalgene som hører til det tyske markedet, og kobler dem mot sporing kunden ser i e-posten.

#Markedet og miljøet i Hamburg

Hamburg er et av Nord-Europas tyngste knutepunkter for logistikk, maritim industri og medier. HafenCity og havneområdet samler shipping-selskaper, logistikkoperatører og leverandører som selger reservedeler, emballasje, verktøy og IT-utstyr til bransjen. MediaCity og det etablerte mediemiljøet gir et annet spor: forlags- og mediebedrifter som selger abonnementer, merchandise og B2B-tjenester via nettbutikk. WordPress Hamburg meetup samler utviklere og redaktører som jobber med nettbutikker og bedriftsportaler i regionen.

For en netthandler i Hamburg betyr det at konkurransen om tyske og internasjonale kunder er hard, og at en treg eller halvfungerende kasse ikke blir tilgitt når neste leverandør er ett klikk unna. Logistikkbedrifter som kjøper reservedeler eller emballasje forventer sporbarhet og faktura som matcher deres egne systemer, ikke en kasse bygget for ren D2C-handel.

Kundene våre i Hamburg spenner fra B2B-leverandører som selger til havne- og logistikkbransjen, til D2C-merker som selger direkte til forbruker på tysk. Fellesnevneren er at de trenger en butikk som tar Stripe DE og Klarna på alvor, regner MwSt riktig, har Impressum og personvern som tåler BfDI-praksis, og lar dem styre frakten selv uten å bytte plattform hver gang ordrevolumet øker.

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 BfDI stiller spørsmål ved samtykkehåndteringen. 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 (Stripe DE, Klarna, PayPal), fraktsoner mot DHL og Hermes, MwSt-regler, B2B-flyt der den finnes, 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 pakkebokslogikk, MwSt- 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, retur etter Widerrufsrecht, 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 Hamburg-butikker

• Stripe DE feilkoblet mot feil land. En B2B-leverandør av emballasje til logistikkbedrifter i havneområdet markerte ordrer betalt på redirect i stedet for på webhook, og Stripe-kontoen var satt opp uten tysk MwSt-visning. Vi flyttet bekreftelsen til webhooken, la inn idempotens slik at dobbel webhook ikke ga dobbel ordre, og korrigerte Button-Lösung-visningen slik at totalpris inkludert MwSt sto korrekt i kassen.
• B2B og B2C delte ikke MwSt-logikk. En reservedelsbutikk som solgte både til skipsverft med USt-IdNr. og til forbrukere blandet omvendt avgiftsplikt og ordinær MwSt på samme kasseflyt. Vi skilte de to stiene, validerte USt-IdNr. mot VIES og fikk riktig fakturaformat til Lexoffice for hver ordretype.
• Treg kasse på Hetzner under kampanje. En D2C-butikk med tungt tema og mange aktive tillegg hadde flere sekunders forsinkelse før betalingsknappen var klikkbar. Butikken lå på Hetzner Cloud i Falkenstein. Vi startet med Lighthouse, WP-CLI-profil og Query Monitor på kassesiden, fant cart-fragment-kallene og autoloadede options som var skyld i mesteparten, satte opp Redis object cache og optimaliserte CDN-ruting uten å flytte hosting.
• BfDI-spørsmål til samtykkehåndtering. En mediebedrift som solgte abonnementer og merchandise fikk henvendelse om cookie-samtykke og Datenschutzerklärung. Vi dokumenterte hvilke data Stripe og fraktleverandørene behandler, satte opp samtykke som blokkerer ikke-nødvendige skript før aksept, og oppdaterte personvernerklæringen slik at den matchet faktisk databehandling.

#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. For Hamburg-prosjekter er Hetzner Cloud et vanlig valg: servere i Falkenstein eller Nürnberg gir lav latency mot tyske kunder, og infrastrukturen skalerer når en logistikk-leverandør går fra hundrevis til tusenvis av ordre i måneden. Hetzner sitt nettverk i Tyskland er godt egnet for nettbutikker som selger til det tyske fastlandet og til naboland. Betaling går via Stripe DE, Klarna og PayPal avhengig av hva butikken trenger, alltid med 3D Secure på kort. Tunge jobber, som synkronisering mot lager, ERP eller frakt-API, 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 tyske kunder forventer fra DHL og Hermes, MwSt og Widerrufsrecht håndtert i selve flyten i stedet for manuelt, B2B-flyt som skiller omvendt avgiftsplikt fra B2C der det trengs, 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 tyske nettbutikker betyr det i praksis at Datenschutzerklärung og samtykkelogikk må tåle en gjennomgang fra BfDI (Bundesbeauftragte für den Datenschutz und die Informationsfreiheit) eller delstatsmyndigheter. Hamburg har en sterk tradisjon for databeskyttelse, og mange nettbutikker i regionen behandler data fra både forbrukere og bedriftskunder med leveringsadresser til havneområdet. Vi dokumenterer hvilke data Stripe, Klarna og fraktleverandørene behandler, setter opp cookie-samtykke som blokkerer ikke-nødvendige skript før aksept, og sørger for at kundedata fra betaling og frakt lagres og slettes i tråd med oppbevaringskravene. Impressum med korrekt ansvarlig enhet er obligatorisk og kobles inn i footer og kasse der loven krever det.

#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 Stripe og Klarna), og stabil layout (lav CLS) gjennom faste bildedimensjoner og reservert plass for dynamisk innhold som betalingsknappene. På Hetzner-hosting optimaliserer vi object cache, databaseforespørsler og CDN-ruting slik at latency mot tyske kunder forblir lav. Vi måler kontinuerlig med Lighthouse i utrullingsløpet, slik at en regresjon blokkerer distribusjon i stedet for å nå produksjon.

#Spørsmål Hamburg-butikker stiller oss

Setter dere opp Stripe DE i kassen? Ja. Vi integrerer kort, SEPA 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 MwSt og OSS riktig? Ja. Vi setter 19 prosent standardsats og 7 prosent redusert sats der de gjelder, viser priser inkludert MwSt slik tyske forbrukere forventer, og skiller OSS-flyten for EU-salg over terskelen fra ordinær innenlandsk MwSt.

Støtter dere B2B-flyt for logistikk- og havneleverandører? Ja. Med USt-IdNr.-validering mot VIES, omvendt avgiftsplikt der det gjelder, og fakturaformat som matcher Lexoffice eller sevDesk.

Hvilke fraktløsninger støtter dere? DHL, Hermes og DPD, med fraktsoner, prisregler etter vekt og volum, pakkeboks som leveringsvalg, og fraktsedler og sporing koblet mot ordrebehandlingen.

Kjører dere på Hetzner? Ja. Mange Hamburg-prosjekter ligger på Hetzner Cloud. Vi optimaliserer object cache, CDN og database der det gir målbar effekt, uten å flytte hosting med mindre det er avtalt.

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 Hamburg? Ja. Vi har tyngdepunktet i Hamburg- og nordtysk miljø, men leverer til netthandlere i hele Tyskland og til tyske butikker drevet fra utlandet.

#Integrasjoner en tysk nettbutikk faktisk trenger

En tysk nettbutikk på WooCommerce ender som regel opp med de samme fire koblingene: betaling med Stripe DE og Klarna, frakt med DHL eller Hermes inkludert pakkebokser, regnskap i DATEV-kompatibelt system via Lexoffice eller sevDesk, og en ordrestatus som settes av serveren til leverandøren, ikke av at kunden tilfeldigvis kommer tilbake til takkesiden. For Hamburg-leverandører som selger til logistikkbransjen kommer ofte en femte kobling: synkronisering mot lager eller ERP som speiler havne- og terminalleveranser. Rekkefølgen er ikke tilfeldig: hver kobling nedover i listen arver feilene fra den over hvis den første ikke er riktig bygget.

#Betaling: Stripe DE ved siden av Klarna og PayPal

Stripe er webhook-drevet, ikke redirect-drevet. Integrasjonen bygges 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 Stripe har bekreftet betalingen server-til-server. For tyske butikker må merchant-kontoen være satt opp med riktig land, valuta og MwSt-visning, ellers bryter Button-Lösung-kravene.

Klarna dekker delbetaling og faktura. Tyske forbrukere bruker Klarna i høy grad for «kjøp nå, betal senere» og faktura. 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.

SEPA krever mandatlagring. Der SEPA Direct Debit er aktuelt, lagres mandatreferansen på ordren og i metadata som overlever HPOS-migrering. Refusjon og chargeback håndteres med egne statusoverganger dokumentert i runbooken.

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: DHL, Hermes og DPD med pakkebokser

Fraktpriser hentes, de gjettes ikke. DHL og Hermes gir pris og leveringstid per produkt og postnummer via API. 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.

Pakkeboks er et eget datafelt. Kunden velger et konkret utleveringssted i kassen, og valget må lagres på ordren som en identifikator fra leverandøren, ikke som fritekst. Fraktsedlene genereres senere mot den identifikatoren. Skrives den som en adresse i et notatfelt, må lageret slå den opp manuelt, og fordelen ved integrasjonen forsvinner.

B2B-leveranser til havneområdet. For logistikk- og maritim leverandører kan leveringsadresser til terminaler eller havneområdet kreve egne felt og validering. Disse lagres på ordren som strukturerte data, ikke fritekst, slik at fraktsedler og sporing kan genereres uten manuell tolkning.

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.

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.

#Regnskap: Lexoffice, sevDesk og DATEV

Salget bokføres én gang, med riktig MwSt-kode. Lexoffice og sevDesk har REST-API med token-basert autentisering. Integrasjonen oppretter kunde og salgsdokument, og mapper hver produktgruppe til riktig MwSt-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.

DATEV-eksport for revisoren. Mange tyske regnskapsførere vil ha DATEV-format. Integrasjonen må kunne levere eksport som matcher kontoplanen, ikke bare en CSV med flat omsetning.

B2B og omvendt MwSt. Selger butikken til bedrifter med gyldig USt-IdNr., må kasseflyten skille B2B med omvendt avgiftsplikt fra B2C med ordinær MwSt. Validering av USt-IdNr. mot EU VIES og lagring på ordren er en del av denne flyten. For Hamburg-leverandører som selger til logistikkbedrifter er dette standard, ikke unntak.

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 på S-Bahn i Hamburg, 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 Stripe eller Klarna 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 på Hetzner eller annen hosting.

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, 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 tyske byer

Trenger du WooCommerce-hjelp utenfor Hamburg, gjelder de samme tyske kravene til Stripe DE, MwSt, Impressum og frakt, men med lokal logistikk og kundemønster. Se også WooCommerce-utvikler i Berlin, WooCommerce-utvikler i München og WooCommerce-utvikler i Frankfurt for hvordan oppsettet tilpasses der.

Etter lansering tar vedlikehold og support for WordPress i Hamburg 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 utenfor Tyskland, med lokalt tilpasset betaling og MVA:

• Amsterdam - WooCommerce-utvikler i Amsterdam
• Rotterdam - WooCommerce-utvikler i Rotterdam
• Antwerpen - WooCommerce-utvikler i Antwerpen
• København - WooCommerce-utvikler i København

#Start et WooCommerce-prosjekt i Hamburg

Trenger butikken din i Hamburg en kasse som tar Stripe DE og Klarna på alvor, regner MwSt riktig, håndterer B2B-flyt for logistikk- og havneleveranser der det trengs, 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 i Hamburg.