WooCommerce Utvikler i București

En WooCommerce-butikk som selger til rumenske og internasjonale kunder må håndtere tre ting som ikke står i standarddokumentasjonen til Woo: Netopia Payments for lokale kortbetalinger, Stripe der kunden betaler fra utlandet, og TVA på 19 prosent regnet riktig mot fakturering. Vi bygger og rydder opp i WooCommerce for bedrifter i București med utgangspunkt i nettopp disse kravene, ikke en generisk mal som siden lokaliseres med bynavn.

Rumensk netthandel har vokst jevnt de siste årene, drevet av økt kortbruk, bedre leveringsnettverk og sesongtopper rundt Black Friday og desemberkampanjer som legger mer press på kasse og hosting enn mange byråer er forberedt på. București er tyngdepunktet for den veksten: hovedstaden samler både D2C-merkevarer, grossister og selskaper som selger videre til EU-markeder fra servere i Romania eller nærliggende EU-hosting.

#WooCommerce-utvikling i București

București-markedet er kresent på kasseflyt og betaling. Rumenske netthandlere er vant til raske kasser, lokale kort via Netopia, tydelig pris med TVA, og leveringsvalg via Fan Courier, Cargus eller DPD med sporing kunden faktisk forventer. Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik en rumensk kunde forventer, og å gjøre det på en måte som overlever oppdateringer av Woo, temaet og betalingstilleggene.

#Hva vi faktisk bygger

• Netopia Payments i kassen: kortbetaling for rumenske kunder, redirect-flyt med webhook-bekreftelse, refusjon og delvis refusjon testet mot testmiljø, og idempotens slik at doble callbacks ikke gir doble ordrer
• Stripe ved siden av Netopia for internasjonale kunder og engelskspråklig trafikk, med 3D Secure på kort, riktig rekkefølge i kassen for RO/EN-butikker og testkort-matrise per gateway
• TVA-oppsett for rumensk handel: 19 prosent standardsats, reduserte satser der de gjelder, og prisvisning som matcher det kunden forventer i București og i eksport til EU
• Frakt med Fan Courier, Cargus eller DPD: fraktsoner, prisregler basert på vekt og volum, levering til adresse eller hentested der leverandøren støtter det, og sporingsnummer koblet mot ordrebehandlingen og forsendelses-e-post
• RO/EN-flerspråklige butikker med WPML WooCommerce Multilingual eller tilsvarende, hreflang, oversatte produktdata og kasseflyt som ikke bryter betalingscallback ved språkbytte
• Utvidelser av WooCommerce REST API for hodeløs storefront, mobilapp eller markedsplassintegrasjon, med autentisering og idempotente betalingsstier

#Hvorfor rumenske betalings- og fraktvalg styrer arkitekturen

I de fleste WooCommerce-prosjekter for București er det ikke produktkatalogen som er vanskelig, det er kassen. Netopia oppfører seg ikke som et generisk kortskjema: redirect-flyten, mobilbank 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.

Stripe ved siden av Netopia er den andre vanlige feilkilden. Internasjonale kunder forventer kort i euro eller valuta de kjenner, mens rumenske kunder forventer Netopia og pris i lei. To gatewayer betyr to sett med statuskoder, to refusjonsmodeller og to webhook-formater, så ordren må lagre i metadata hvilken gateway som eide betalingen. Uten dette blir refusjon fra admin et gjettespill.

Frakt er den tredje fellen. En rumensk kunde forventer å se Fan Courier, Cargus eller DPD som leveringsvalg med estimert leveringstid, ikke bare «standard frakt». Når frakt-API-et er nede eller tregt, skal kassen falle tilbake til en definert standardsats i stedet for å vise en kasse uten fraktvalg. Feilen logges slik at hyppige tidsavbrudd blir synlige før kundeservice oppdager dem.

#Markedet og miljøet i București

București er Rumunias administrative og økonomiske sentrum. Områder som Pipera, Floreasca og nordlige forstadsklynger huser IT-outsourcing, BPO og shared services, men parallelt vokser D2C- og B2B-netthandel raskt: nettbutikker selger lokalt og på tvers av EU, og sesongtopper legger mer press på hosting og kasseflyt enn mange byråer er forberedt på.

Kundene våre i București spenner fra nisjebutikker som selger direkte til forbruker, til etablerte merkevarer som flytter fra en lukket plattform over til WooCommerce for å eie egen kode og integrere mot regnskap i Saga eller SmartBill. Fellesnevneren er at de trenger en butikk som tar Netopia på alvor, regner TVA riktig og lar dem styre frakt og språk 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 rundt Black Friday, et betalingstillegg slutter å bli vedlikeholdt, eller TVA-reglene 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.

Personvern håndheves av Autoritatea Națională de Supraveghere a Prelucrării Datelor cu Caracter Personal (ANSPDCP). For nettbutikker i București betyr det samtykke til markedsføring, tydelig informasjon om databehandling ved checkout, og meldeplikt ved bekreftede brudd innen 72 timer. Dette er ikke en bunntekst-oppgave: samtykkeloggen, databehandleravtaler og hva som lagres i ordre-meta etter betaling må være kartlagt i arkitekturen fra start.

#Slik jobber vi gjennom et prosjekt

1. Kasse- og katalogrevisjon. Vi går gjennom dagens WooCommerce-butikk: produkttaksonomi, kasseflyt, aktive betalingstillegg (Netopia, Stripe), fraktsoner mot Fan Courier, Cargus eller DPD, TVA-regler, RO/EN-struktur 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 leveringslogikk, TVA-håndtering, GDPR/ANSPDCP-krav 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å Netopia 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 București-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.
• Treg kasse på mobil under kampanje. En butikk med tungt tema og mange aktive tillegg hadde merkbart forsinkelse før betalingsknappen var klikkbar under Black Friday-trafikk. 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.
• Stripe og Netopia i samme kasse uten metadata. Refusjon fra admin feilet fordi ordren ikke lagret hvilken gateway som eide betalingen. Vi skilte flytene, satte gateway-referanse i ordre-meta og testet refusjon på begge stier.

#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 Payments og Stripe avhengig av hva butikken trenger, alltid med 3D Secure på kort der gatewayen krever det. 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 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.

#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 kunder forventer, TVA håndtert i selve flyten i stedet for manuelt, RO/EN-struktur som ikke bryter betalingscallback, 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 nettbutikker i București betyr det i praksis at kundedata fra Netopia- og Stripe-betalinger, navn og adresse for frakt, og samtykke til markedsføring behandles og lagres slik regelverket krever. Bekreftede brudd vurderes meldeplikt til ANSPDCP innen 72 timer. Callback-endepunkter for betaling holdes utenfor sidecache og uten passordbeskyttelse, fordi maskiner må nå dem server-til-server.

#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 betalingsknappene. Vi måler kontinuerlig med Lighthouse i utrullingsløpet, slik at en regresjon blokkerer distribusjon i stedet for å nå produksjon.

#Spørsmål București-butikker stiller oss

Setter dere opp Netopia Payments i kassen? Ja. Vi integrerer redirect-flyt, webhook-håndtering 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 Stripe brukes ved siden av Netopia? Ja. Stripe dekker internasjonale kunder og engelskspråklig trafikk, med 3D Secure på kort. Ordren lagrer hvilken gateway som eide betalingen, slik at refusjon fra admin fungerer på begge stier.

Hvordan håndterer dere TVA? Vi setter 19 prosent standardsats og reduserte satser der de gjelder, kobler produktgrupper til riktig sats, og sørger for at prisvisning matcher det kunden forventer i Romania og ved eksport til EU.

Hvilke fraktløsninger støtter dere? Fan Courier, Cargus og DPD, med fraktsoner, prisregler etter vekt og volum, og sporingsnummer koblet mot ordrebehandlingen og forsendelses-e-post.

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 București? Ja. Vi leverer til netthandlere i hele Romania og til rumenske butikker drevet fra utlandet som selger tilbake til det rumenske markedet.

#Integrasjoner en rumensk nettbutikk faktisk trenger

En rumensk nettbutikk på WooCommerce ender som regel opp med de samme fire koblingene: betaling med Netopia og Stripe, frakt med Fan Courier, Cargus eller DPD, regnskap i Saga eller SmartBill, 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 Stripe

Netopia er en redirect-gateway, ikke et skjema. Integrasjonen bygges 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.

Stripe dekker det Netopia ikke dekker. Internasjonale kort, Apple Pay og Google Pay der Stripe støtter det, og engelskspråklig kasse uten å tvinge rumenske kunder gjennom feil valuta. To gatewayer betyr to webhook-formater, så ordre-meta må lagre gateway-referanse og transaksjons-id per sti.

HPOS må deklareres. På butikker med High-Performance Order Storage må egen plugin-kode melde kompatibilitet og lese/skrive ordredata via CRUD-API-et. Gammel gateway-kode som skriver direkte til postmeta slutter å virke uten feilmelding.

#Frakt: Fan Courier, Cargus og DPD

Fraktpriser hentes der API finnes, ellers defineres soner. Leverandørenes API gir pris og leveringstid per vektklasse og destinasjon. 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. Feilen logges via wc_get_logger med egen kilde.

#Regnskap: Saga eller SmartBill

Salget bokføres én gang, med riktig TVA-kode. Saga og SmartBill har API-er som oppretter kunde og salgsdokument. Integrasjonen 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 hindrer dobbeltbokføring ved en ny kjøring.

Avstemming er mot utbetaling, ikke mot ordre. Betalingsleverandøren utbetaler samlet og trekker gebyr. Regnskapet stemmer først når integrasjonen bokfører utbetalingen som en egen post med gebyret skilt ut.

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 eller bytte til en annen app mens betalingen fullføres. Redirect tilbake til butikken er dermed en hendelse som kanskje skjer. Betalingsbekreftelsen fra Netopia 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 i regnskapet 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, 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 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 București, gjelder de samme kravene til Netopia, Stripe, TVA og frakt, men med lokal logistikk og kundemønster. Se også WooCommerce-utvikler i Cluj-Napoca for hvordan oppsettet tilpasses Transilvania-huben.

Etter lansering tar vedlikehold og support for WordPress i București oppdateringer, sikkerhetskopier og overvåking, inkludert Netopia- og Stripe-callbacks og ANSPDCP-relevante endringer i samtykkehåndtering.

#Start et WooCommerce-prosjekt i București

Trenger butikken din i București en kasse som tar Netopia på alvor, Stripe for internasjonale kunder, regner TVA riktig og lar deg styre frakt og språk 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 av WordPress-nettsted.