Headless WooCommerce i Spania: betalingsløsninger (Bizum, Redsys) og nasjonal logistikk

#Headless WooCommerce i Spania: betalingsløsninger (Bizum, Redsys) og nasjonal logistikk

Spansk netthandel har nådd et høyt teknisk modenhetsnivå. I 2026 vurderer kundene ikke lenger bare produkt og pris: de forventer en rask og trygg handleopplevelse tilpasset lokale betalings- og fraktmetoder. Monolittiske netthandelsplattformer, der serveren genererer HTML og CSS i sanntid for hvert klikk, sliter med å levere de responstidene mobilbrukere venter av en moderne butikk.

Som svar på dette behovet for ytelse og fleksibilitet har headless WooCommerce etablert seg i Spania som det riktige valget for mellomstore og store detaljhandelsmerker. Denne artikkelen ser på hvor headless WooCommerce står i Spania i dag, hvordan du integrerer de dominerende betalingsløsningene (Redsys og Bizum), og hva som skal til for å samordne fakturering og logistikk for både fastlandet og øyene.

#Fordeler med headless WooCommerce for butikker i Spania

Headless-modellen skiller administrasjonspanelet og databasen i WordPress (backend) fra det offentlige grensesnittet kundene bruker (frontend). MySQL-databasen og forretningslogikken i WooCommerce kjører på en optimalisert privat server, mens butikkens offentlige utstillingsvindu bygges med moderne statiske generatorer som Astro eller Next.js og serveres via globale kantnettverk (CDN).

#Hastigheten til headless WooCommerce på mobil

Spania er et av EU-landene der størst andel av netthandelen skjer på mobil. Mobiltrafikken utgjør ofte over 70% av alle besøk i butikker for mote og forbruksvarer. Et tregt nettsted på en mobil med 4G eller dårlig dekning fører direkte til avbrutte kjøp i kassen.

Med en statisk frontend bygget på Astro går sidevekten kraftig ned. Bilder optimaliseres automatisk til AVIF, og interaktiv JavaScript begrenses til de dynamiske elementene (som legg i handlekurv-knappen). Det gjør det mulig å få tid til første byte (TTFB) under 20ms i Spania og nå en PageSpeed-score på 100/100.

#Sikkerheten i headless WooCommerce med tanke på NIS2

Når den statiske frontenden kobles fra WordPress-installasjonen, blir administrasjonspanelet (/wp-admin/) og MySQL-spørringene skjult for offentligheten. Sårbare utvidelser i backenden er ikke lenger eksponert i frontenden, noe som gir mindre angrepsflate, et nyttig argument for virksomheter som omfattes av NIS2-direktivet om cybersikkerhet (direktiv (EU) 2022/2555).

#Slik integrerer du Redsys og Bizum i headless WooCommerce

En nettbutikk som vil lykkes i Spania, må støtte kortbetaling via Redsys og tilby raske betalinger med Bizum. Bizum er enkelt på mobil fordi kunden bare skriver inn telefonnummeret sitt og godkjenner betalingen i et varsel fra bankappen (Bizum, netthandel).

#Hvorfor Redsys-varsler feiler i headless WooCommerce

I en vanlig WooCommerce-installasjon sender den offisielle Redsys-utvidelsen brukeren direkte videre til bankens virtuelle betalingsterminal (TPVV) og behandler betalingsbekreftelsen via en POST-forespørsel som Redsys-serveren sender til WordPress i bakgrunnen (nettvarselet, eller callback-webhooken).

I en headless-arkitektur gir denne flyten to vesentlige tekniske utfordringer:

1. Omdirigering og retur: Brukeren må sendes fra den statiske frontenden (f.eks. tienda.com) til Redsys-TPVV og etter betalingen tilbake til en bekreftelsesside i frontenden (tienda.com/pago-confirmado/), ikke til den interne WordPress-adressen (backend.tienda.com).
2. Cloudflare-brannmur og blokkerte callbacks: Hvis backend-subdomenet til WordPress er beskyttet av Cloudflare WAF (vanlig praksis mot brute force-angrep), kan brannmuren fange opp bakgrunnsvarselet Redsys-serverne sender for å bekrefte transaksjonen, og merke det som uønsket automatisert trafikk. Resultatet er at kundens bank trekker beløpet, men ordrestatusen i WooCommerce blir stående på “Venter på betaling”, og bekreftelsesmailen sendes aldri.

sequenceDiagram
    participant Cliente as Kundens nettleser
    participant Front as Astro-frontend (tienda.com)
    participant Back as WordPress-backend (wp.tienda.com)
    participant Redsys as Redsys- / Bizum-server

    Cliente->>Front: Starter betaling
    Front->>Back: Oppretter ordre via REST API
    Back-->>Front: Returnerer Redsys-signatur og data
    Front->>Redsys: Sender videre til TPVV
    Cliente->>Redsys: Godkjenner betaling (Bizum/kort)
    Redsys-->>Back: Sender nettvarsel (POST-callback)
    Note over Back: Fare! Cloudflare WAF kan blokkere POST fra Redsys
    Redsys->>Cliente: Returomdirigering etter vellykket betaling
    Cliente->>Front: Lander på /pago-confirmado/
    Front->>Back: Sjekker ordrestatus

#Slik hindrer du at Cloudflare blokkerer Redsys-varsler

For å hindre at betalingsvarsler blokkeres i frikoblede arkitekturer i Spania, bruker byråer to hovedstrategier:

• Unntaksregler i WAF: Egne regler i Cloudflare-brannmuren slipper gjennom HTTP POST-forespørsler fra de offisielle Redsys-subnettene, og bare mot callback-endepunktet i WooCommerce.
• Ruter i Cloudflare Workers: En lett serverless-funksjon (Worker) i nettverkslaget fanger opp Redsys-varsler på et offentlig subdomene, validerer HMAC-signaturen lokalt med algoritmen oppgitt i Ds_SignatureVersion og sender kommandoen om ordreoppdatering direkte til WooCommerce REST API via et internt, autentisert kall.

// Ejemplo conceptual de validación de firma criptográfica de Redsys en un Worker
export default {
  async fetch(request, env) {
    if (request.method !== "POST") {
      return new Response("Método no permitido", { status: 405 });
    }
    
    const formData = await request.formData();
    const ds_signature = formData.get("Ds_Signature");
    const ds_merchantParameters = formData.get("Ds_MerchantParameters");
    
    // Validar la firma HMAC con el algoritmo de Ds_SignatureVersion (HMAC_SHA512_V2 en la documentación actual de Redsys)
    const isValid = await checkRedsysSignature(ds_merchantParameters, ds_signature, env.REDSYS_KEY);
    
    if (!isValid) {
      return new Response("Firma no válida", { status: 400 });
    }
    
    // Comunicar confirmación de pago al backend de WooCommerce de forma segura
    const response = await fetch(`${env.WP_API_URL}/wp-json/wppoland/v1/update-order-status`, {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "Authorization": `Bearer ${env.WP_API_TOKEN}`
      },
      body: JSON.stringify({ parameters: ds_merchantParameters })
    });
    
    return new Response("OK", { status: 200 });
  }
};

#Slik aktiverer du Bizum i Redsys-terminalen

Bizum avtales ikke med Redsys, men med butikkens bank. Bizums side for nettbutikker oppsummerer prosessen i tre trinn: snakk med banken om vilkårene og bestill tjenesten, integrer Bizum i betalingsløsningen, og plasser knappen i butikken (Bizum, método de pago online). Samme side minner om at det alltid trengs en avtale med en Bizum-bank først, også når butikken bruker en modul eller utvidelse fra en bankløsning som allerede er sertifisert.

I en virtuell Redsys-terminal er den tekniske endringen liten. Veiledningen fra Cajamar, en av bankene som tilbyr denne terminalen, sier at det etter avtale om terminal og Bizum-tjeneste kan ta opptil 48 timer før synkronisering og aktivering er på plass, og at betalingsskjemaet sendes til https://sis.redsys.es/sis/realizarPago med verdien z i feltet DS_MERCHANT_PAYMETHODS (Cajamar, Configura Bizum en tu TPV virtual). Andre banker kan ha andre frister. I en headless-arkitektur legger WordPress-backenden dette feltet til de signerte parameterne, og frontenden viser bare knappen og omdirigeringsskjemaet. Derfra tar terminalen seg av autorisasjonen.

For kunden er flyten kort. Ifølge Bizum skriver kunden inn telefonnummeret som er knyttet til Bizum, får et varsel fra bankappen, sjekker det og godkjenner betalingen, og går så tilbake til butikkens nettsted for å fullføre kjøpet (Bizum, compra online). At kunden kommer tilbake, beviser ikke at betalingen gikk gjennom: siden /betaling-bekreftet/ i frontenden må lese ordrestatusen fra WooCommerce, og den endres først når Redsys-varselet er mottatt. Bizum støtter også gjentakende betalinger og abonnementer som kunden godkjenner med telefonnummeret første gang.

#Slik verifiserer du signaturen i et Redsys-varsel

Dagens utviklerdokumentasjon fra Redsys beskriver signaturen med Ds_SignatureVersion satt til HMAC_SHA512_V2 (Redsys, Firmar una operación). Butikkens hemmelige nøkkel diversifiseres per ordre med AES CBC-kryptering og en initialiseringsvektor av nuller, nøkkelen brukes til å beregne en HMAC SHA-512, og resultatet kodes i Base64URL. For å validere et nettvarsel oppgir Redsys disse trinnene:

1. Dekod de mottatte Base64-parameterne og les ordrenummeret, Ds_Order.
2. Beregn den diversifiserte nøkkelen med dette ordrenummeret.
3. Beregn HMAC SHA-512 over Base64-parameteren nøyaktig slik den kom inn, uten å dekode den.
4. Kod resultatet i Base64URL og sammenlign med Ds_Signature. Meldingen behandles bare hvis verdiene stemmer.

Hvis Workeren signerer JSON som allerede er dekodet, stemmer ikke den beregnede signaturen med Ds_Signature, selv om varselet er ekte. Mange eksisterende biblioteker og utvidelser bruker fortsatt forrige versjon, HMAC_SHA256_V1, så Workeren bør lese Ds_SignatureVersion i hvert varsel og validere med tilsvarende algoritme i stedet for å låse én fast i koden. Når signaturen er godkjent, kontrollerer Workeren i tillegg at beløp og ordrenummer stemmer med WooCommerce-ordren før den markeres som betalt.

#Slik setter du opp WooCommerce-frakt i Spania

Leveringen er avgjørende i spansk netthandel. Merkevarer i Spania trenger automatiske koblinger til de ledende nasjonale transportørene (som Correos Express, SEUR, GLS eller MRW) for å effektivisere lagerdriften.

#Slik validerer du spanske postnumre i kassen

For å unngå sorteringsfeil på lageret og tillegg for omdirigerte pakker må kassen validere spanske postnumre strengt:

• Format: 5 sifre.
• Regionale serier: De to første sifrene angir mottakerprovinsen (f.eks. 08 for Barcelona, 28 for Madrid, 35 og 38 for Kanariøyene).
• Takstsoner: Fraktberegningen i headless-kassen må skille tydelig mellom det spanske fastlandet, Balearene, Kanariøyene og Ceuta og Melilla.

#Mva. ved frakt til Kanariøyene, Ceuta og Melilla

Salg til områder utenfor det spanske fastlandets skatteområde krever presis avgiftsoppsett. Forsendelser til fastlandet og Balearene har ordinær (21%), redusert (10%) eller sterkt redusert (4%) mva., mens forsendelser til Kanariøyene, Ceuta og Melilla regnes som eksport skattemessig:

• Mva.-fritak: Kassen må fjerne mva. når leveringspostnummeret begynner med 35, 38 (Kanariøyene), 51 (Ceuta) eller 52 (Melilla).
• Lokale avgifter (IGIC og IPSI): Tollen på mottakerstedet krever inn IGIC (på Kanariøyene) eller IPSI (i Ceuta og Melilla) fra sluttkunden, eller via forenklet tollbehandling som transportøren står for.
• Tilleggsdata: Kundens NIF/CIF eller DNI må hentes inn i kassen til eksportdokumentasjonen i tollen (DUA-deklarasjonen), et felt som ikke trengs ved vanlige forsendelser på fastlandet.

#Slik kobler du kassen til transportørenes API-er

Headless-kassen bør kommunisere asynkront med API-ene til den valgte logistikkoperatøren for å:

1. Beregne priser dynamisk: Hente reelle fraktpriser ut fra pakkens volumvekt og mottakerens postnummer.
2. Tilby hentesteder: La brukeren velge et fysisk hentested (som et Correos-kontor eller en GLS-pakkeautomat) på et kart innebygd i kassen.
3. Lage etiketter: Varsle transportøren når betalingen er fullført, slik at henteetiketten på lageret lages automatisk.

#Slik kobler du WooCommerce til VeriFactu og e-faktura

For at en headless WooCommerce-butikk i Spania skal stå driftsmessig stødig i 2026, må fakturering og skattehåndtering samordnes med verktøyene til den spanske skatteetaten (Agencia Estatal de Administración Tributaria, AEAT):

#Hva VeriFactu krever av en nettbutikk

Alle nettbutikker i Spania må sørge for at programvaren deres utsteder fakturaer som ikke kan endres, og i VERI*FACTU-modus sender tilhørende poster til AEAT. Real Decreto-ley 15/2025 utsatte fristene: selskaper som betaler selskapsskatt, må ha tilpassede systemer før 1. januar 2027, og alle andre før 1. juli 2027 (BOE-A-2025-24446).

Dette gjøres ved å koble kjøpsprosessen i WooCommerce, via webhooks eller sikre API-kall, til ERP- og e-fakturaplattformer godkjent i Spania (som Holded, Quaderno eller Factura Directa). Når ordrestatusen endres til “Behandles” eller “Fullført”, sendes transaksjonsdataene til ERP-systemet, som returnerer den offisielle fakturaen som PDF (med påbudt QR-kode), klar for nedlasting fra kundens konto i frontenden.

#Når en WooCommerce-butikk må registreres i OSS

Hvis headless WooCommerce-butikken din er basert i Spania, men selger over landegrensene til forbrukere (B2C) i andre EU-land, må du være klar til å håndtere mva.-ordningen OSS (One Stop Shop).

Når samlet salg innenfor EU passerer den årlige terskelen på 10 000 euro, må butikken ta mva.-satsen som gjelder i kundens bostedsland (f.eks. 19% i Tyskland, 23% i Polen). Headless-kassen må beregne disse satsene dynamisk ut fra kundens fakturaadresse og vise dem tydelig i oppstillingen av totalprisen.

#Slik utformer du en headless-kasse for WooCommerce

En god headless-kasse for WooCommerce utformes for å gi minst mulig friksjon for brukeren og synkronisere data trygt med WordPress-serveren. Her er en konseptuell skisse av samspillet mellom det statiske frontendlaget (Astro), sesjonstilstanden og backend-API-ene:

graph TD
    A[Kasse i Astro-frontend] --> B[Handlekurvstatus]
    A --> C[Validering av postnummer & NIF/CIF]
    A --> D[Betalingsløsning Redsys / Bizum]

    C --> C1{Kanariøyene / Ceuta / Melilla?}
    C1 -- Ja --> C2[Mva.-fritak & krev NIF/CIF]
    C1 -- Nei --> C3[Fastlands-mva. 21%]

    B --> E[Transportør-API: Correos Express / SEUR]
    E --> E1[Beregning av reell fraktkostnad]
    E --> E2[Valg av hentested på kart]

    D --> F[Transaksjonsbekreftelse i Redsys]
    F --> G[Ordreoppdatering via Cloudflare Workers]
    G --> H[WooCommerce-backend]
    H --> I[Faktura-ERP: VeriFactu-PDF]

#Beste praksis for headless-kasse i det spanske markedet

• Ansvarsdeling: Feltvalidering, adressehåndtering og visning av kartet over hentesteder bør skje på klientsiden i den statiske frontenden, så WordPress-serveren slipper gjentatte kall.
• Asynkron prisoppdatering: Lette fetch-forespørsler sender handlekurvens fraktdata til WooCommerce-endepunktet, og avgifter og frakt beregnes på nytt bare når provins eller postnummer endres i kasseskjemaet.
• Sesjonsvarighet: Sesjonscookies og JWT-tokens fra WooCommerce må holdes synkronisert på tvers av delte subdomener (f.eks. tienda.com og wp.tienda.com), slik at brukeren ikke mister varene i handlekurven ved omlasting eller nettverksbytte under betalingen.

#Konklusjon

En headless WooCommerce-butikk i Spania i 2026 forener teknisk ytelse i toppklassen med streng etterlevelse av nasjonale regler og driftsforhold.

Når butikkflaten kobles fra, får du lastetider som gjør flere mobilbesøk om til salg, merkevarens sikkerhet styrkes, og integrasjonen med Bizum, Redsys, VeriFactu-systemer og nasjonale logistikk-API-er blir enklere. Å jobbe med spesialiserte utviklere som kan denne arkitekturen i iberiske forhold, er en strategisk investering med høy avkastning for voksende detaljhandelsmerker.

#Bizum, Redsys og PCI-DSS i headless WooCommerce

Netthandel i det spanske markedet krever en solid teknisk integrasjon med lokale betalingsløsninger:

• Omdirigerings- og REST API-arkitektur for Redsys: I headless-oppsett (med Astro- eller Next.js-frontend) bør Redsys kommunisere med HMAC-signaturer generert i den sikre WordPress-backenden (HMAC_SHA512_V2 i dagens Redsys-dokumentasjon, HMAC_SHA256_V1 i mange eksisterende integrasjoner). Kunden sender aldri kortnumre til butikkens egne servere, slik at butikken holder seg på PCI-DSS-nivå SAQ A.
• Bizum i samme terminal som kort: Bizum aktiveres i den virtuelle Redsys-terminalen som allerede behandler kort, så headless-frontenden legger bare til en knapp og gjenbruker samme flyt for omdirigering og varsler. Aktiveringstrinnene står i delen om hvordan du aktiverer Bizum i Redsys-terminalen.
• Automatisk logistikksynkronisering med SEUR, GLS og Correos Express: WooCommerce-API-et kobles via sikre webhooks til systemene til de nasjonale transportørene. Hver ordre gir automatisk fraktetiketter, sporingsnumre og SMS-varsler til sluttkunden uten manuelt arbeid.
• Forretningsfordeler: Denne moderne, frikoblede infrastrukturen gir umiddelbare lastetider på mobil, beskyttelse mot nedetid under store kampanjer og en smidig handleopplevelse som maksimerer netthandelssalget i Spania.

#Slik unngår du betalingsbrudd i WooCommerce på Black Friday

Under store salgskampanjer som Black Friday eller sesongsalg:

• Asynkron håndtering av betalings-webhooks: Bekreftelsesvarsler fra Redsys og Bizum bør tas imot via meldingskøer (som Redis eller RabbitMQ), så en plutselig bølge av samtidige kjøp ikke blokkerer PHP-FPM-prosessene. Kunden får umiddelbar bekreftelse på betalingssiden mens ordren behandles i bakgrunnen.
• Lagersynkronisering med ERP i sanntid: Direkte integrasjon med forretningssystemer (som SAP, Navision eller Holded) holder lagerbeholdningen i den frikoblede butikkflaten oppdatert på sekundet og hindrer dobbeltsalg av utsolgte varer.
• E-faktura mellom bedrifter: Lov 18/2022 (Crea y Crece) utvider kravet om e-faktura til handel mellom næringsdrivende. Selger butikken til bedrifter, må ERP-systemet som er koblet til WooCommerce, kunne utstede strukturerte e-fakturaer for disse ordrene, og fakturapostene må lagres uforanderlig etter VeriFactu.
• Konklusjon: En godt strukturert headless WooCommerce-butikk gir spanske bedrifter full teknologisk selvstendighet, forutsigbare driftskostnader og et teknisk grunnlag for å ta ledelsen i salget i sin bransje.

#Slik øker du konverteringen i en WooCommerce-butikk i Spania

Hastigheten i en frikoblet nettbutikk slår direkte ut på bunnlinjen:

• Kraftig lavere fluktfrekvens på mobil: Mer enn 70 % av detaljhandelstrafikken i Spania kommer fra smarttelefoner. Produktsider som rendres statisk med Astro laster på under ett sekund, noe som holder på kjøperens interesse og mangedobler salget sammenlignet med trege, tradisjonelle butikker.
• Optimalisert kasse og biometrisk betaling: Når kunden kan betale med Apple Pay, Google Pay eller Bizum uten å taste inn kortnumre eller kompliserte bankpassord, forsvinner friksjonen i siste steg av kjøpet.
• Automatisk gjenvinning av forlatte handlekurver: Webhook-integrasjon med verktøy for markedsføringsautomatisering gjør det mulig å sende personlige påminnelser på e-post eller WhatsApp til brukere som ikke fullførte ordren.
• Oppsummering: Å investere i en headless WooCommerce-arkitektur for det spanske markedet kombinerer verdens mest brukte netthandelsmotor med dagens mest avanserte frontendteknologi og gir lønnsom, bærekraftig vekst. Moderne digital handel belønner teknisk kvalitet, og det er den korteste veien til varig lønnsomhet.