WooCommerce Utvikler i Cluj-Napoca

En WooCommerce-butikk som selger til rumenske og europeiske kunder må håndtere tre ting som ikke står i standarddokumentasjonen til Woo: Netopia eller PayU i kassen, TVA i RON med korrekt visning og etterbetaling (ramburs) som betalingsvalg, og frakt via Fan Courier eller Cargus med sporingsnummer kunden faktisk forventer. Vi bygger og rydder opp i WooCommerce for bedrifter i Cluj-Napoca med utgangspunkt i nettopp disse kravene, ikke en generisk mal som siden lokaliseres med bynavn.

Cluj-Napoca er det største teknologisenteret i Transilvania og det nest største i Romania etter București. Byen lever av IT-outsourcing, produktutvikling og e-handel mot vest-europeiske markeder. En kasse som bare er testet mot Stripe i testmodus, uten Netopia-sandbox og uten ramburs-logikk, taper konverteringer på rumensk mobiltrafikk. Det er det praktiske utgangspunktet for arbeidet vårt.

#WooCommerce-utvikling i Cluj-Napoca

Cluj-markedet er kresent. Rumenske netthandlere er vant til rask kasse, pris i RON med TVA inkludert, ramburs som betalingsvalg og levering via Fan Courier eller Cargus. Bedrifter som selger til Tyskland, Østerrike eller Norden fra Cluj trenger i tillegg EUR-visning, OSS-kompatibel TVA-logikk og flerspråklig checkout uten at hver språkversjon blir en halv oversatt kopi. Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik markedet forventer, og å gjøre det på en måte som overlever oppdateringer av Woo, temaet og betalingstilleggene.

#Hva vi faktisk bygger

• Netopia og PayU i kassen: kortbetaling med 3D Secure 2, Apple Pay og Google Pay der gatewayen støtter det, webhook-bekreftelse på serveren i stedet for redirect, og testmatrise for autorisasjon, belastning, refusjon og delvis refusjon mot sandbox
• Ramburs (COD) som egen betalingsmetode med riktig gebyrlogikk og ordrestatus som ikke settes til betalt før leverandøren har mottatt kontanter
• TVA-oppsett for rumensk handel: standardsats, reduserte satser der de gjelder, priser vist inkludert TVA slik rumenske forbrukere forventer, og separat flyt for EU-eksport med OSS der butikken selger over grensen fra Cluj
• Dual-valuta storefront for RON og EUR med geolokasjon eller manuell valg, korrekt avrunding og separate fraktsoner for innland og eksport
• Frakt med Fan Courier, Cargus, DPD Romania, Sameday og Poșta Română: fraktsoner, prisregler basert på vekt og volum, og sporingsnummer koblet mot ordrebehandlingen og forsendelsesvarselet
• B2B-funksjonalitet for leverandører og nearshore-selskaper i Cluj: rollebaserte priser, CUI/CIF-validering, minste ordremengder, tilbudsforespørselsarbeidsflyter og dedikerte bedriftsportaler
• Utvidelser av WooCommerce REST API for hodeløs storefront, mobilapp eller POS, med autentisering og idempotente betalingsstier
• Produktimport og lager-sync fra ERP (SmartBill, Saga, Odoo), CSV-feeds og leverandør-APIer med planlagt synkronisering og revisjonslogging

#Hvorfor rumenske betalings- og fraktvalg styrer arkitekturen

I de fleste WooCommerce-prosjekter for Cluj er det ikke produktkatalogen som er vanskelig, det er kassen. Netopia oppfører seg ikke som et generisk Stripe-tillegg: redirect-flyten, 3DS-håndteringen og webhook-bekreftelsen krever at ordrestatus ikke settes til betalt før Netopia faktisk har bekreftet. Vi har sett butikker der ordrer ble markert fullført på redirect tilbake, ikke på webhook, slik at avbrutte betalinger ga ordrer uten penger. Den typen feil fanges bare med ende-til-ende-QA på selve betalingsstien.

Ramburs er den andre fellen. En rumensk kunde forventer å velge etterbetaling i kassen, spesielt utenfor storbyene. Når dette mangler eller gebyret er feil konfigurert, faller konverteringen. Vi setter opp ramburs som egen gateway med tydelig ordrestatus og admin-arbeidsflyt for kontantmottak ved levering.

Frakt er den tredje. Fan Courier og Cargus forventer API-nøkler, kundenummer og riktig volumvekt i prisberegningen. Når fraktpriser gjettes i stedet for å hentes fra leverandøren, eller når sporing ikke skrives inn i e-posten, øker kundeservice-trykket. Vi kobler frakt-API mot woocommerce_package_rates, mellomlagrer svar i transienter per postnummer og vektklasse, og skriver sporingsnummer inn i forsendelsesvarselet.

#Markedet og miljøet i Cluj-Napoca

Cluj-Napoca er Transilvanias IT-hub. Universitetet Babeș-Bolyai, teknologiparken i Cluj og konsentrasjonen av nearshore-selskaper langs strada Fabricii og i området rundt Iuliu Maniu gjør byen til et outsourcing-senter for Tyskland, Østerrike, Norden og Storbritannia. For en netthandler betyr det at konkurransen er hard, og at en treg eller halvfungerende kasse ikke blir tilgitt, verken av rumenske forbrukere eller av B2B-kjøpere som sammenligner leverandører på tvers av Romania, Bulgaria og Ungarn.

Kundene våre i Cluj spenner fra D2C-merker som selger fra Transilvania til hele Romania, til B2B-leverandører som eksporterer til EU, til e-handelsselskaper som bygger butikker for vest-europeiske merkevarer fra nearshore-team i byen. Fellesnevneren er at de trenger en butikk som tar Netopia og ramburs på alvor, regner TVA riktig og lar dem styre frakten selv, samtidig som de oppfyller GDPR og forventningene til ANSPDCP (Autoritatea Națională de Supraveghere a Prelucrării Datelor cu Caracter Personal), rumeniens tilsynsmyndighet for personvern.

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 markeder og betalingskrav dukket opp. Det fungerer helt til trafikken øker, et betalingstillegg slutter å bli vedlikeholdt, eller TVA-reglene for EU-eksport endrer seg. 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.

WordCamp Transylvania 2013 etablerte Cluj som et WordPress-miljø som tar open source på alvor. Seniorpraktikere i byen forventer kode som overlever oppdateringer, skriftlig dokumentasjon og tydelig arkitekturgrense mellom kjerne, plugin og tema. Det hever terskelen for hvem som får tillit, men gjør tekniske samtaler enklere når kravene er presise.

En tredje markedsrealitet er konkurransen med eMAG, Romanias dominerende markedsplass. eMAG setter forventninger til leveringshastighet, returprosesser og kundeservice. En WooCommerce-butikk i Cluj må ha et tydelig merkeverdi-tilbud: eksklusive produkter, B2B-kondisjoner, direkte kundeforhold eller nisjesortiment som ikke skalerer på markedsplassen. Teknisk betyr det ofte separat lagerlogikk, produktfeeds for sammenligningsportaler og en kasse som holder under last når kampanjer trekker trafikk fra hele Romania.

#Slik jobber vi gjennom et prosjekt

1. Kasse- og katalogrevisjon. Vi går gjennom dagens WooCommerce-butikk: produkttaksonomi, kasseflyt, aktive betalingstillegg (Netopia, PayU, Stripe, PayPal, ramburs), fraktsoner mot Fan Courier og Cargus, TVA-regler 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 leverandørlogikk, TVA- 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 og Netopia-sandbox på hver gateway, ramburs-flyt, 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 Cluj-Napoca-butikker

• Netopia er feilkoblet. En butikk markerte ordrer betalt på redirect i stedet for på webhook. Vi flyttet bekreftelsen til callback-håndtereren, la inn idempotens slik at dobbel webhook ikke ga dobbel ordre, og satte opp full testmatrise for autorisasjon, belastning og refusjon mot Netopia-sandbox.
• Treg kasse på mobil. En nearshore-drevet butikk med tungt tema og mange aktive tillegg 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.
• TVA og OSS regnet feil. En butikk som solgte både innenlands i Romania og til EU fra Cluj blandet sammen rumensk TVA og OSS-flyten for grenseoverskridende salg. Vi skilte de to stiene, satte riktig sats per produktgruppe og fikk EU-ordrer merket riktig for rapportering.
• Ramburs uten ordrestatus. En butikk tok imot etterbetaling, men ordre gikk direkte til «behandling» uten at lageret så at betaling ikke var mottatt. Vi introduserte egen status for COD, tydelig admin-filter og e-postmal som matcher forventningen til kunden.

#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 Netopia, PayU, Stripe eller PayPal avhengig av hva butikken trenger, alltid med 3D Secure på kort. Tunge jobber, som synkronisering mot lager, regnskap eller produktfeeds, kjøres via Action Scheduler i bakgrunnen slik at de ikke blokkerer kassen. HPOS-kompatibilitet deklareres eksplisitt der butikken bruker High-Performance Order Storage, og all ordrelogikk går gjennom wc_get_order og CRUD-metodene.

#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 rumenske markedet forventer fra Fan Courier og Cargus, TVA og ramburs håndtert i selve flyten i stedet for manuelt, 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, databehandleravtaler og personvern bygget inn i arkitekturen.

For rumenske nettbutikker betyr det i praksis også at kundedata fra Netopia- og kortbetalinger, samt navn og adresse for frakt, behandles og lagres slik regelverket krever. ANSPDCP forventer ettersporbare personvernerklæringer, dokumenterte behandlingsformål og samtykke før tredjepartsskript lastes. Cookie-banner alene er ikke nok; samtykke må ligge i arkitekturen. For forbrukervern er ANPC (Autoritatea Națională pentru Protecția Consumatorilor) relevant: obligatoriske tekster om angrerett, leveringsbetingelser og reklamasjon bygges inn i flyten, ikke bare kopiert inn i temaet. OUG 34/2014 definerer informasjonsplikter for elektronisk handel i Romania som en Woo-butikk må oppfylle fra dag én.

#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 Cluj-Napoca-butikker stiller oss

Setter dere opp Netopia og PayU i kassen? Ja. Vi integrerer kortbetaling med 3D Secure, tester autorisasjon, belastning, refusjon og delvis refusjon mot sandbox før lansering, og sørger for at bekreftelse av betaling skjer på webhook, ikke på redirect tilbake til butikken.

Støtter dere ramburs og rumensk frakt? Ja. Ramburs som egen betalingsmetode med riktig gebyrlogikk, Fan Courier, Cargus, DPD Romania og Sameday med fraktsoner, prisregler etter vekt og volum, og sporingsnummer koblet mot ordrebehandlingen og e-posten.

Kan dere håndtere TVA og OSS riktig? Ja. Vi setter rumenske satser der de gjelder, viser priser inkludert TVA slik rumenske forbrukere forventer, og skiller OSS-flyten for EU-salg fra ordinær innenlands TVA når butikken selger over grensen fra Cluj.

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 Cluj-Napoca? Ja. Vi har tyngdepunktet i Cluj-miljøet, men leverer til netthandlere i hele Romania og til rumenske butikker drevet fra nearshore-team mot vest-europeiske markeder.

#Integrasjoner en rumensk nettbutikk faktisk trenger

En rumensk nettbutikk på WooCommerce ender som regel opp med de samme fire koblingene: betaling med Netopia eller PayU og ramburs, frakt med Fan Courier eller Cargus inkludert sporingsnummer, regnskap i SmartBill eller Saga, 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: Netopia ved siden av ramburs og kort

Netopia er redirect og webhook, ikke et skjema. Integrasjonen bygges mot Netopias betalings-API for engangskjøp, med 3DS der kortutstederen krever det. Butikken oppretter en betaling, sender kunden til betalingssiden 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 Netopia har bekreftet.

Ramburs er en egen gateway, ikke et notatfelt. Etterbetaling krever egen ordrestatus, tydelig gebyr i kassen og admin-arbeidsflyt som skiller «sendt» fra «betalt ved levering». Uten dette blir regnskap og lager avvikende allerede i første uke.

PayU og Stripe går ved siden av, ikke i stedet for. PayU dekker rumenske kunder som forventer lokalt merke, Stripe dekker internasjonale kort og noen eksportscenarier. 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.

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: Fan Courier og Cargus med sporingsnummer

Fraktpriser hentes, de gjettes ikke. Fan Courier og Cargus gir pris og leveringstid per produkt og postnummer, autentisert med API-nøkkel og kundenummer fra leverandøren. 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.

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: SmartBill eller Saga

Salget bokføres én gang, med riktig TVA-kode. SmartBill og Saga har API-er som oppretter kunde og salgsdokument, og mapper hver produktgruppe til riktig TVA-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.

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 appen, bytte til en annen app mens betalingen fullføres, eller ha nettleseren i bakgrunnen. Redirect tilbake til butikken er dermed en hendelse som kanskje skjer. Betalingsbekreftelsen fra Netopias 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.

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 sandbox 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, 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.

#WooCommerce i andre rumenske byer

Trenger du WooCommerce-hjelp utenfor Cluj-Napoca, gjelder de samme rumenske kravene til Netopia, TVA og frakt, men med lokal logistikk og kundemønster. Se også WooCommerce-utvikler i București for hovedstadens Fintech- og e-handelsmiljø.

Etter lansering tar vedlikehold og support for WordPress i Cluj-Napoca oppdateringer, sikkerhetskopier og overvåking. Huber i Romania sammenligner ofte SLA med vedlikehold i București.

#Start et WooCommerce-prosjekt i Cluj-Napoca

Trenger butikken din i Cluj-Napoca en kasse som tar Netopia og ramburs på alvor, regner TVA riktig 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. Omfanget og investeringen avtales individuelt etter revisjonen, og du får oversikten skriftlig før arbeidet starter.