WooCommerce Utvikler i Budapest

En WooCommerce-butikk som selger til ungarske kunder må håndtere tre ting som ikke står i standarddokumentasjonen til Woo: SimplePay eller Barion i kassen, ÁFA på 27 prosent regnet riktig, og frakt via GLS, Foxpost eller Magyar Posta med hentested kunden faktisk forventer. Vi bygger og rydder opp i WooCommerce for bedrifter i Budapest med utgangspunkt i nettopp disse kravene, ikke en generisk mal som siden lokaliseres med bynavn.

Budapest er et av de tyngste fintech-miljøene i Sentral-Europa. Barion ble grunnlagt her, SimplePay eies av OTP-gruppen, og mange netthandlere i distriktet XIII og på Buda-siden kjører betaling gjennom minst én av disse. En kasse uten lokale betalingsvalg taper konverteringer på ungarsk mobiltrafikk, uansett hvor pen resten av butikken er. Det er det praktiske utgangspunktet for arbeidet vårt.

#WooCommerce-utvikling i Budapest

Det ungarske e-handelsmarkedet er modent nok til at kundene forventer rask kasse, lokale betalingsmetoder og tydelig ÁFA-visning. Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik en ungarsk kunde forventer, og å gjøre det på en måte som overlever oppdateringer av Woo, temaet og betalingstilleggene.

#Hva vi faktisk bygger

• SimplePay i kassen: redirect-flyt mot OTP-gruppens gateway, støtte for kort og bankoverføring, webhook-bekreftelse før ordre settes til betalt, og testmatrise for autorisasjon, belastning, refusjon og delvis refusjon mot testmiljø
• Barion ved siden av SimplePay: wallet-betaling og kort med 3D Secure, egnet for butikker som allerede har Barion-konto fra fintech-økosystemet i Budapest, med riktig rekkefølge i kassen for ungarsk trafikk
• ÁFA-oppsett for ungarsk handel: 27 prosent standardsats, reduserte satser der de gjelder, og priser vist inkludert ÁFA slik ungarske forbrukere forventer
• Frakt med GLS, Foxpost og Magyar Posta: fraktsoner, prisregler basert på vekt og volum, pakkeautomat som leveringsvalg, og fraktsedler/sporing koblet mot ordrebehandlingen
• GDPR og NAIH-tilpasset samtykkehåndtering: informasjonskapsler, markedsføringssamtykke, databehandleravtaler og slettingsforespørsler bygget inn i flyten, ikke lagt på som et banner tillegg i etterkant
• Utvidelser av WooCommerce REST API for hodeløs storefront, mobilapp eller POS, med autentisering og idempotente betalingsstier

#Hvorfor ungarske betalings- og fraktvalg styrer arkitekturen

I de fleste WooCommerce-prosjekter for Budapest er det ikke produktkatalogen som er vanskelig, det er kassen. SimplePay oppfører seg ikke som et vanlig Stripe-skema: redirect-flyten, bankautentisering og webhook-bekreftelsen 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 betalinger ga ordrer uten penger. Den typen feil fanges bare med ende-til-ende-QA på selve betalingsstien.

Barion har en egen wallet-flyt som mange ungarske kunder kjenner fra andre nettbutikker. Når begge gatewayene er aktive, må ordren lagre i metadata hvilken gateway som eide betalingen og hvilken referanse den bruker. Uten dette blir refusjon fra admin et gjettespill.

Frakt er den andre fellen. En ungarsk kunde forventer å velge Foxpost-automat eller GLS hentested i kassen, ikke bare «standard frakt». Når dette mangler, faller konverteringen på mobil. Vi setter opp fraktsonene og leveringsvalgene som hører til det ungarske markedet, og kobler dem mot sporing kunden ser i e-posten.

#Markedet og fintech-miljøet i Budapest

Budapest har blitt et knutepunkt for fintech og e-handel i Sentral-Europa. Barion, SimplePay, og en rekke betalings- og checkout-leverandører har hovedkontor eller utviklingssenter i byen. For en netthandler betyr det at konkurransen om ungarske kunder er hard, og at en treg eller halvfungerende kasse ikke blir tilgitt.

Kundene våre i Budapest spenner fra nisjebutikker som selger direkte til forbruker, til fintech- og SaaS-selskaper som selger abonnement eller digitale produkter via WooCommerce, til etablerte merkevarer som flytter fra en lukket plattform over til Woo for å eie egen kode. Fellesnevneren er at de trenger en butikk som tar SimplePay og Barion på alvor, regner ÁFA riktig og lar dem styre frakten 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 NAIH 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 (SimplePay, Barion, Stripe), fraktsoner mot GLS og Foxpost, ÁFA-regler, NAIH-relevante samtykker 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 hentestedslogikk, ÁFA-håndtering, GDPR/NAIH-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å SimplePay og Barion, 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 Budapest-butikker

• SimplePay markerte ordrer betalt på redirect. En fintech-butikk i distriktet XIII satte payment_complete når kunden kom tilbake fra banken, ikke når SimplePay sendte 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.
• Barion wallet manglet i kassen. En netthandler som solgte til unge kunder i Budapest hadde kun kort via Stripe. Konverteringen på mobil var lav. Vi la Barion wallet ved siden av SimplePay, satte riktig rekkefølge i kassen, og testet både wallet- og kortflyten mot Barions testmiljø.
• NAIH-klage på samtykkebanner. En butikk brukte et generisk cookie-banner uten granulert samtykke og uten dokumentert databehandleravtale for markedsførings-e-post. Vi bygget samtykkehåndtering inn i checkout og nyhetsbrev-påmelding, dokumenterte behandlingsgrunnlag og leverte mal for svar på innsynsforespørsler.
• Treg kasse på mobil. En 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.

#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 SimplePay og Barion 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.

#Hva du kan forvente etter lansering

Vi lover ikke faste prosenttall, fordi resultatet avhenger av utgangspunktet. Det vi leverer er en kasse som tar SimplePay og Barion på alvor og bekrefter ordrer på webhook, ikke på redirect, fraktvalg som matcher det ungarske kunder forventer fra GLS og Foxpost, ÁFA håndtert i selve flyten i stedet for manuelt, GDPR og NAIH-krav dokumentert i arkitekturen, 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 bygget inn i arkitekturen. I Ungarn håndheves personvernreglene av NAIH (Nemzeti Adatvédelmi és Információszabadság Hatóság). Det betyr i praksis at kundedata fra betalinger, navn og adresse for frakt, og markedsføringssamtykke må behandles med dokumentert behandlingsgrunnlag, databehandleravtaler der det kreves, og en prosess for innsyn og sletting som ikke avhenger av at én person husker prosedyren.

Vi dokumenterer hvilke data som lagres i WooCommerce, hvilke som sendes til SimplePay, Barion og fraktleverandører, og hvor lenge de oppbevares. Cookie-banner alene er ikke nok: markedsføringssamtykke, checkout-felt og nyhetsbrev-påmelding må spore samtykke med tidsstempel.

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

Setter dere opp SimplePay og Barion i kassen? Ja. Vi integrerer begge gatewayene der det gir mening, tester autorisasjon, belastning, refusjon og delvis refusjon mot testmiljø før lansering, og bekrefter betaling på webhook, ikke på redirect tilbake til butikken.

Kan dere håndtere ÁFA riktig? Ja. Vi setter 27 prosent standardsats og reduserte satser der de gjelder, og viser priser inkludert ÁFA slik ungarske forbrukere forventer.

Hvilke fraktløsninger støtter dere? GLS, Foxpost og Magyar Posta, med fraktsoner, prisregler etter vekt og volum, pakkeautomat og hentested som leveringsvalg, og fraktsedler og sporing koblet mot ordrebehandlingen.

Hva med NAIH og GDPR? Vi bygger samtykkehåndtering inn i checkout og markedsføringsflyt, dokumenterer databehandling, og leverer mal for svar på innsyns- og slettingsforespørsler. NAIH er tilsynsmyndigheten; kravene følger EU-GDPR med ungarsk implementering.

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 Budapest? Ja. Vi har tyngdepunktet i Budapest-miljøet, men leverer til netthandlere i hele Ungarn og til ungarske butikker drevet fra utlandet.

#Integrasjoner en ungarsk nettbutikk faktisk trenger

En ungarsk nettbutikk på WooCommerce ender som regel opp med de samme fire koblingene: betaling med SimplePay og Barion, frakt med GLS eller Foxpost inkludert hentesteder, regnskap i Számlázz.hu eller Billingo, 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: SimplePay og Barion

SimplePay er en redirect-gateway, ikke et skjema. Integrasjonen bygges mot OTP-gruppens API for engangskjøp og mot avtale-endepunkter for gjentakende trekk der det trengs. Butikken oppretter en betaling, sender kunden til banken eller kortskjemaet 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 SimplePay har bekreftet.

Barion wallet går ved siden av kort. Barion dekker kunder som foretrekker wallet-betaling, alltid med 3D Secure på kort. 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.

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: GLS, Foxpost og Magyar Posta

Fraktpriser hentes, de gjettes ikke. GLS og Foxpost har API-er for pris og leveringstid per produkt og postnummer. 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 er et eget datafelt. Kunden velger et konkret Foxpost-automat eller GLS hentested i kassen, og valget må lagres på ordren som en identifikator 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, 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: Számlázz.hu eller Billingo

Salget bokføres én gang, med riktig ÁFA-kode. Både Számlázz.hu og Billingo har API med token-basert autentisering. Integrasjonen oppretter kunde og salgsdokument, og mapper hver produktgruppe til riktig ÁFA-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. 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, ikke når hver ordre er bokført hver for seg.

B2B betyr e-számla. Selger butikken til bedrifter i Ungarn, skal fakturaen sendes som elektronisk számla med riktig adószám (skattenummer) på mottakeren. Det er en egen flyt i kassen: felt for adószám, validering, og et annet dokumentløp enn forbrukersalget.

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å metroen i Budapest, 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 SimplePay eller Barion 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 testmiljø 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 i appen, 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 sentraleuropeiske byer

Trenger du WooCommerce-hjelp utenfor Budapest, gjelder de samme ungarske kravene til SimplePay, Barion og ÁFA for butikker som selger inn i Ungarn, men med lokal logistikk og kundemønster. Se også WooCommerce-utvikler i Wien, WooCommerce-utvikler i Praha og WooCommerce-utvikler i București for hvordan oppsettet tilpasses der.

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

#Start et WooCommerce-prosjekt i Budapest

Trenger butikken din i Budapest en kasse som tar SimplePay og Barion på alvor, regner ÁFA 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. Prisen settes individuelt etter omfang, og du får oversikten skriftlig før arbeidet starter.