WooCommerce Utvikler i Alicante

En WooCommerce-butikk som selger til kunder på Costa Blanca må håndtere tre ting som ikke står i standarddokumentasjonen til Woo: Bizum og Redsys i kassen, IVA beregnet etter spanske satser, og frakt via Correos eller SEUR med sporing kunden faktisk forventer. Vi bygger og rydder opp i WooCommerce for bedrifter i Alicante med utgangspunkt i nettopp disse kravene, ikke en generisk mal som siden lokaliseres med bynavn.

Alicante er inngangsporten til Costa Blanca. Turiststrømmen fra El Altet, ferieboliger langs kysten og et voksende lokalt næringsliv skaper et e-handelsmarked der sesongen styrer trafikken og kassen må fungere like godt på mobil som på desktop. En kasse uten Bizum taper konverteringer blant spanske kunder, uansett hvor pen resten av butikken er. Det er det praktiske utgangspunktet for arbeidet vårt.

#WooCommerce-utvikling i Alicante

Alicante-markedet er sesongdrevet. Netthandlere langs Costa Blanca er vant til raske kasser, Bizum-knapp for mobilbetaling, tydelig IVA og fraktalternativer som matcher det spanske post- og budnettverket. Arbeidet vårt handler om å få WooCommerce til å oppføre seg slik en spansk kunde forventer, og å gjøre det på en måte som overlever oppdateringer av Woo, temaet og betalingstilleggene.

#Hva vi faktisk bygger

• Redsys i kassen: integrasjon mot det dominerende spanske betalingsnettverket, med SHA-256-signering, 3D Secure 2.2 og støtte for Visa, Mastercard og lokale debetkort via TPV Virtual
• Bizum ved siden av Redsys: mobilbetaling som mange spanske kunder forventer som førstevalg, med redirect-flyt, webhook-bekreftelse og testmatrise for autorisasjon, belastning og refusjon
• Stripe ES for internasjonale kunder og Apple Pay / Google Pay der det gir mening, med riktig rekkefølge i kassen for blandet ES/EN-trafikk
• IVA-oppsett for spansk handel: 21 prosent standardsats, redusert sats på næringsmidler og bøker, riktig behandling av Canarias, Ceuta og Melilla der det gjelder, og priser vist inkludert IVA slik spanske forbrukere forventer
• Frakt med Correos, SEUR og MRW: fraktsoner, prisregler basert på vekt og volum, hentested som leveringsvalg, og fraktsedler/sporing koblet mot ordrebehandlingen
• Flerspråklig storefront ES/EN: hreflang, lokaltilpassede URL-er, uavhengig metadata per språk og kassefelt tilpasset både lokale og internasjonale turister
• HPOS-kompatibel egen kode: FeaturesUtil::declare_compatibility på before_woocommerce_init, og all ordrelogikk via wc_get_order og CRUD-metodene
• Utvidelser av WooCommerce REST API for hodeløs storefront, bookingintegrasjon eller POS, med autentisering og idempotente betalingsstier

#Hvorfor spanske betalings- og fraktvalg styrer arkitekturen

I de fleste WooCommerce-prosjekter for Alicante er det ikke produktkatalogen som er vanskelig, det er kassen. Bizum oppfører seg ikke som et vanlig kortgateway: redirect-flyten, app-switchen på mobil og webhook-bekreftelsen krever at ordrestatus ikke settes til betalt før Bizum faktisk har bekreftet. Vi har sett butikker langs Costa Blanca der ordrer ble markert fullført på redirect tilbake, ikke på webhook, slik at avbrutte Bizum-betalinger ga ordrer uten penger. Den typen feil fanges bare med ende-til-ende-QA på selve betalingsstien.

Redsys er den andre fellen. Mange spanske nettbutikker kjører Redsys via et ferdig WooCommerce-tillegg som ikke er oppdatert for High-Performance Order Storage. Når HPOS aktiveres, slutter gateway-kode som skriver med update_post_meta å virke uten å gi feilmelding. Vi har sett en ferieutleie-butikk i Alicante som mistet betalingsbekreftelser etter en Woo-oppdatering nettopp av den grunnen. Løsningen var å erklære HPOS-kompatibilitet, migrere all ordrelogikk til CRUD-API-et og teste hele stien på nytt.

Frakt er den tredje. En spansk kunde forventer å velge hentested hos Correos eller et SEUR Service Point i kassen, ikke bare «standard frakt». Turister som bestiller til ferieleilighet langs Playa de San Juan trenger tydelig leveringsadresse og sporing på spansk og engelsk. Når hentested mangler, faller konverteringen på mobil. Vi setter opp fraktsonene og leveringsvalgene som hører til det spanske markedet, og kobler dem mot sporing kunden ser i e-posten.

#Markedet og miljøet i Alicante

Alicante er et av de viktigste turistknutepunktene på Costa Blanca. Flyplassen El Altet (Alicante-Elche) tar imot millioner av besøkende årlig, og kysten fra El Campello til Torrevieja har et tett nett av hoteller, ferieboliger, opplevelsesleverandører og lokale spesialbutikker som selger både til innbyggere og til besøkende. For en netthandler betyr det at trafikken svinger kraftig mellom høysesong og lavsesong, og at en treg eller halvfungerende kasse koster mer per time når solturistene er på plass.

Kundene våre i Alicante spenner fra lokale produsenter av vin og olivenolje som selger direkte til forbruker, til opplevelsesbedrifter som selger guidede turer og vannsport langs kysten, til etablerte merkevarer som flytter fra en lukket plattform over til WooCommerce for å eie egen kode og støtte både spansk og engelsk. Fellesnevneren er at de trenger en butikk som tar Bizum og Redsys på alvor, regner IVA 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 i juli, et betalingstillegg slutter å bli vedlikeholdt, eller AEPD 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 (Redsys, Bizum, Stripe), fraktsoner mot Correos/SEUR, IVA-regler, ES/EN-innhold 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, IVA-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 test-Bizum på hver gateway, refusjon og delvis refusjon, kunde-e-post på ES og EN, 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 Alicante-butikker

• Bizum mangler eller er feilkoblet. En opplevelsesbutikk markerte ordrer betalt på redirect i stedet for på webhook. Vi flyttet bekreftelsen til webhooken, 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 i høysesong. En butikk med tungt tema og mange aktive tillegg hadde flere sekunders forsinkelse før Bizum-knappen 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.
• IVA regnet feil for Canarias-leveranser. En butikk som solgte både til fastlandet Spania og til ferieboliger på Kanariøyene blandet sammen vanlig IVA og unntak. Vi skilte de to flytene, satte riktig sats per produktgruppe og fikk leveringsadressevalidering til å styre skatteberegningen.
• ES/EN-innhold uten hreflang. En turistbutikk hadde engelske produktsider uten korrekt hreflang-tagger, slik at Google indekserte feil språkversjon for internasjonale søk. Vi satte opp uavhengige metadata, hreflang og kassefelt på begge språk uten å duplisere ordrelogikken.

#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. Hosting ligger i EU for å oppfylle GDPR-kravene som AEPD håndhever i Spania. Betaling går via Redsys, Bizum og Stripe 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.

HPOS er standard på nye butikker vi bygger. Egen plugin-kode erklærer kompatibilitet via FeaturesUtil::declare_compatibility( 'custom_order_tables', __FILE__, true ) på before_woocommerce_init, og all lesing og skriving av ordredata går gjennom wc_get_order og CRUD-metodene. Gammel gateway-kode som skriver med update_post_meta migreres før HPOS aktiveres, ikke etterpå når betalingene allerede har sluttet å virke.

#Hva du kan forvente etter lansering

Vi lover ikke faste prosenttall, fordi resultatet avhenger av utgangspunktet. Det vi leverer er en kasse som tar Bizum og Redsys på alvor og bekrefter ordrer på webhook, ikke på redirect, fraktvalg som matcher det spanske kunder forventer fra Correos og SEUR, IVA håndtert i selve flyten i stedet for manuelt, flerspråklig storefront der ES/EN er konfigurert riktig, 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.

I Spania håndheves GDPR av AEPD (Agencia Española de Protección de Datos). For nettbutikker i Alicante betyr det i praksis at kundedata fra Redsys-, Bizum- og Stripe-betalinger, navn og adresse for frakt, og samtykke til markedsføring må behandles og lagres slik regelverket krever. Hosting i EU er et grunnleggende krav, ikke et tilvalg. Ved personvernbrudd med risiko for registrerte gjelder varslingsfristen på 72 timer til AEPD, så loggning, tilgangskontroll og revisjonsspor bygges inn fra start.

Cookie-samtykke følger LSSI (Ley de Servicios de la Sociedad de la Información) og ePrivacy-direktivet: analytikk og markedsføringssporing lastes ikke før brukeren har gitt eksplisitt samtykke, og samtykkeloggen lagres slik den kan dokumenteres ved en AEPD-henvendelse.

#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 fra Redsys og Stripe), og stabil layout (lav CLS) gjennom faste bildedimensjoner og reservert plass for dynamisk innhold som Bizum-knappen. Vi måler kontinuerlig med Lighthouse i utrullingsløpet, slik at en regresjon blokkerer distribusjon i stedet for å nå produksjon.

Sesongtrafikken på Costa Blanca gjør ytelse ekstra kritisk: når tusenvis av turister søker etter opplevelser eller ferieprodukter samtidig, er det cart-fragment-kall og autoloadede options som bestemmer om kassen svarer eller henger.

#Spørsmål Alicante-butikker stiller oss

Setter dere opp Redsys og Bizum i kassen? Ja. Vi integrerer Redsys TPV Virtual med SHA-256-signering og 3D Secure, Bizum for mobilbetaling, og Stripe der internasjonale kunder trenger kort eller Apple Pay. Bekreftelse av betaling skjer på webhook, ikke på redirect tilbake til butikken.

Kan dere håndtere IVA riktig for Spania og spesialsoner? Ja. Vi setter 21 prosent standardsats og reduserte satser der de gjelder, viser priser inkludert IVA slik spanske forbrukere forventer, og skiller flyten for Canarias, Ceuta og Melilla der unntak gjelder.

Hvilke fraktløsninger støtter dere? Correos, SEUR og MRW, med fraktsoner, prisregler etter vekt og volum, hentested som leveringsvalg, og fraktsedler og sporing koblet mot ordrebehandlingen.

Trenger vi både spansk og engelsk? For de fleste Costa Blanca-butikker ja. Turistmarkedet krever ES/EN med hreflang, uavhengig metadata og kassefelt på begge språk. Vi bygger det inn i arkitekturen uten å duplisere ordrelogikk.

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 Alicante? Ja. Vi har tyngdepunktet i Alicante og Costa Blanca, men leverer til netthandlere i hele Spania og til nordiske bedrifter med kunder i EØS.

#Integrasjoner en spansk nettbutikk faktisk trenger

En spansk nettbutikk på WooCommerce ender som regel opp med de samme fire koblingene: betaling med Redsys, Bizum og Stripe, frakt med Correos eller SEUR inkludert hentesteder, regnskap i Holded eller Contasimple, 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: Redsys, Bizum og Stripe

Redsys er ryggraden. De fleste spanske nettbutikker går gjennom Redsys TPV Virtual, som støtter Visa, Mastercard og lokale debetkort med SHA-256-signering og 3D Secure 2.2. Integrasjonen bygges som en vanlig WC_Payment_Gateway-klasse der process_payment returnerer en redirect til Redsys, og fullføringen skjer i callback-håndtereren. Ordren får payment_complete først når Redsys har bekreftet.

Bizum er en app-switch, ikke et skjema. Integrasjonen bygges mot Bizum sitt API for engangskjøp. Butikken oppretter en betaling, sender kunden til appen og venter. Alt som skjer etterpå er utenfor nettleserens kontroll. Derfor implementeres gatewayen med redirect-flyt og webhook-bekreftelse, ikke med synkron statusendring på retur til butikken.

Stripe dekker internasjonale kunder. Turister langs Costa Blanca forventer fortsatt Visa, Mastercard, Apple Pay og Google Pay. Stripe ES gir dette ved siden av Redsys og Bizum, ikke i stedet for. To eller tre gatewayer betyr flere sett med statuskoder, refusjonsmodeller og 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 Redsys-plugin-kode som skriver med update_post_meta slutter å virke uten å gi feilmelding.

#Frakt: Correos, SEUR og MRW med hentesteder

Fraktpriser hentes, de gjettes ikke. Correos og SEUR har API-er som gir 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 utleveringssted eller et SEUR Service Point 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.

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. For ES/EN-butikker sendes e-posten på kundens valgte språk.

#Regnskap: Holded eller Contasimple

Salget bokføres én gang, med riktig IVA-kode. Både Holded og Contasimple 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. 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-faktura. Selger butikken til bedrifter i Spania, skal fakturaen inneholde CIF/NIF, riktig IVA-behandling og ofte e-fakturaformat. Det er en egen flyt i kassen: felt for organisasjonsnummer, 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å stranden i San Juan, 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 Redsys eller Bizum 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 utenfor sesongen.

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 spanske byer

Trenger du WooCommerce-hjelp utenfor Alicante, gjelder de samme spanske kravene til Redsys, Bizum, IVA og frakt, men med lokal logistikk og kundemønster. Se også WooCommerce-utvikler i Barcelona, WooCommerce-utvikler i Madrid og WooCommerce-utvikler i Valencia for hvordan oppsettet tilpasses der.

Etter lansering tar vedlikehold og support for WordPress i Alicante oppdateringer, sikkerhetskopier og overvåking. Nordiske huber sammenligner ofte med vedlikehold i Oslo og vedlikehold i Stockholm.

#Andre spanske og nordiske byer

Samme WooCommerce-leveranse finnes i flere byer, med lokalt tilpasset betaling og MVA/IVA:

• Barcelona - WooCommerce-utvikler i Barcelona
• Madrid - WooCommerce-utvikler i Madrid
• Valencia - WooCommerce-utvikler i Valencia
• Oslo - WooCommerce-utvikler i Oslo

#Start et WooCommerce-prosjekt i Alicante

Trenger butikken din i Alicante en kasse som tar Bizum og Redsys på alvor, regner IVA 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.

For butikker og nettsteder som trenger en strukturert gjennomgang av risiko, er inngangen sikkerhetsrevisjon for WordPress.