Integrere betalingsløsning: hvad der reelt indgår
At integrere en betalingsløsning er ikke teknisk svært — moderne udbydere har god dokumentation og fungerende eksempler. Det der gør det svært, er alt uden for den lykkelige vej: fejlslagne betalinger, refusioner, tilbageførsler, duplikerede ordrer og hvad der sker, når kunden lukker fanen midt i betalingen.
Denne guide gennemgår selve integrationen og mere udførligt de grænsetilfælde, hvor der reelt går penge tabt.
Vælg de metoder dit marked bruger#
Betalingspræferencer er stærkt regionale. At tilbyde de forkerte metoder mister salg i kurven, hvilket er det dyreste sted at miste nogen.
| Metode | Hvor det tæller | Vær opmærksom på |
|---|---|---|
| Dankort | Uundværligt i Danmark | Lav omkostning, høj udbredelse |
| MobilePay | Meget udbredt i Danmark | Øjeblikkelig bekræftelse, stærk på mobil |
| Internationalt kort | Udenlandske kunder og erhverv | Højere omkostning, risiko for tilbageførsel |
| Apple Pay og Google Pay | Mobilt, hæver konverteringen mærkbart | Kræver HTTPS og domæneverifikation |
| Faktura eller delbetaling | Udbredt i Norden | Udbyderen bærer risikoen, mod en procentsats |
| PayPal | Internationalt, kendt mærke | Højere omkostning, egen tvistproces |
| Bankoverførsel | B2B og høje beløb | Langsom bekræftelse; ordrer bliver liggende |
Start med to til tre metoder, dit marked faktisk bruger. Hver ekstra metode er endnu et valg i kurven og mere subtilt endnu et forløb at teste efter hver opdatering.
Hvordan integrationen virker#
Formen er stort set den samme hos alle moderne udbydere, og den er værd at forstå, fordi fejlmåderne følger af den.
- Din server opretter en betalingshensigt med beløb, valuta og ordrereference.
- Kunden sendes til udbyderens betalingsside eller udfylder en indlejret formular.
- Kunden godkender hos sin bank eller kortudsteder, ofte med stærk autentificering.
- Udbyderen sender kunden tilbage til din retur-URL — som du aldrig må bruge som betalingsbevis.
- Udbyderen sender en webhook til din server med den endelige status. Dette er sandheden.
- Din server verificerer webhookens signatur, opdaterer ordren og sender bekræftelsen.
- Kortoplysninger rører aldrig din server — hvilket holder dig uden for den tunge del af PCI.
Trin fire og fem rummer flest fejl. Kunden kan lukke browseren, før hun kommer tilbage; webhooken kommer alligevel. Byg på webhooken, ikke på returen.
Grænsetilfældene hvor penge forsvinder#
De dukker ikke op i test og dukker op i den første rigtigt travle uge.
| Situation | Hvad der går galt | Håndtering |
|---|---|---|
| Webhook kommer to gange | Ordren behandles dobbelt | Idempotens: behandl hvert hændelses-id én gang |
| Webhook før returen | Kapløb der overskriver ordrestatus | Eksplicitte statusovergange, aldrig baglæns |
| Kunden lukker fanen efter betaling | Betalt, ingen ordre | Opret ordren på webhooken, ikke på returen |
| Betaling fejler efter lagerreservation | Lager låst uden salg | Lad reservationen udløbe efter et fast vindue |
| Delrefusion | Bogholderiet stemmer ikke | Modellér refusioner som førsteklasses hændelse |
| Tilbageførsel | Penge væk, vare afsendt | Gem dokumentation; risikoregler ved høje beløb |
| Udbyderen er nede | Nul salg, ikke mindre salg | En anden metode som reserve |
Compliance og test#
En kort liste der dækker det, der bliver dyrt, når det mangler.
- Brug hostede felter eller viderestilling, så kortoplysninger aldrig rører din server — det reducerer dit PCI-omfang markant.
- Stærk kundeautentificering er obligatorisk i Europa; test forløbet med et kort, der fremtvinger den.
- Verificér hver webhooks signatur. En uverificeret webhook er et offentligt endepunkt, der kan markere ordrer som betalte.
- Vis priser inklusive moms til forbrugere, og gør fragtprisen synlig før sidste trin.
- Gem ordre- og betalingsdata i den skattemæssige opbevaringsperiode og persondata ikke længere end nødvendigt.
- Test refusioner og delrefusioner før lanceringen, ikke når den første kunde beder om det.
- Foretag en rigtig transaktion i produktion med et rigtigt kort og refundér den til dig selv. Testtilstand dækker ikke alt.
Ofte stillede spørgsmål
Hvilken betalingsudbyder skal jeg vælge?
Vælg ud fra hvilke metoder de understøtter på dit marked, hvilke gebyrer de tager ved din omsætning, og hvor godt de integrerer med din platform. For en dansk webshop er understøttelse af Dankort og MobilePay det første filter. Prisforskellene mellem de store udbydere er ved beskeden omsætning små nok til ikke at være afgørende.
Har jeg brug for PCI-overholdelse?
Ja, men omfanget afhænger helt af, hvordan du integrerer. Bruger du hostede betalingsfelter eller viderestilling, så kortoplysninger aldrig rører din server, falder din forpligtelse tilbage på den enkleste selvvurdering. Behandler du kortoplysninger selv, er du i et helt andet regime — næsten ingen webshop bør gøre det.
Hvorfor har jeg brug for webhooks, når der findes en retur-URL?
Fordi returen afhænger af kundens browser. Lukker hun fanen, mister forbindelsen eller sidder fast på banksiden, kommer returen aldrig — men pengene er alligevel trukket. Webhooken kommer fra udbyderens server og når frem uanset hvad. Byg ordren på webhooken, og brug returen kun til at vise kunden noget.
Hvordan undgår jeg duplikerede ordrer?
Gør webhookhåndteringen idempotent: gem hændelses-id for hver behandlet webhook og ignorér gentagelser. Udbydere sender webhooks igen, når bekræftelse udebliver, så dobbelte leveringer er normal adfærd, ikke en fejl. Uden den kontrol sender du to bekræftelsesmails og trækker lageret to gange.
integrere betalingsløsningmobilepay webshopbetalingsgatewaywebhook betalingpci overholdelseonlinebetaling
