Integrera betallösning: vad som faktiskt ingår
Att integrera en betallösning är inte tekniskt svårt — moderna leverantörer har bra dokumentation och fungerande exempel. Det som gör det knepigt är allt utanför den lyckliga vägen: misslyckade betalningar, återbetalningar, återkrav, dubblerade ordrar och vad som händer när kunden stänger fliken mitt i betalningen.
Den här guiden går igenom själva integrationen och, mer utförligt, gränsfallen där pengar verkligen försvinner.
Välj metoderna din marknad använder#
Betalpreferenser är starkt regionala. Att erbjuda fel metoder tappar försäljning i kassan, vilket är det dyraste stället att tappa någon på.
| Metod | Var det räknas | Att tänka på |
|---|---|---|
| Swish | Nödvändigt i Sverige | Omedelbar bekräftelse, mycket använt |
| Kort | Internationellt och företag | Högre kostnad, återkravsrisk |
| Faktura | Vanligt i Norden | Leverantören bär risken, mot en procentsats |
| Delbetalning | Växande i flera segment | Samma modell som faktura |
| PayPal | Internationellt, känt varumärke | Högre kostnad, egen tvistprocess |
| Apple Pay och Google Pay | Mobilt, höjer konverteringen märkbart | Kräver HTTPS och domänverifiering |
| Banköverföring | B2B och höga belopp | Långsam bekräftelse; ordrar blir liggande |
Börja med två till tre metoder din marknad faktiskt använder. Varje ytterligare metod är ett val till i kassan och, mer subtilt, ett flöde till att testa efter varje uppdatering.
Hur integrationen fungerar#
Formen är i stort sett densamma hos alla moderna leverantörer, och den är värd att förstå eftersom felmoderna följer av den.
- Din server skapar en betalavsikt med belopp, valuta och orderreferens.
- Kunden skickas till leverantörens betalsida, eller fyller i ett inbäddat formulär.
- Kunden godkänner hos sin bank eller kortutgivare, ofta med stark autentisering.
- Leverantören skickar tillbaka kunden till din retur-URL — som du aldrig får använda som betalningsbevis.
- Leverantören skickar en webhook till din server med slutgiltig status. Detta är sanningen.
- Din server verifierar webhookens signatur, uppdaterar ordern och skickar bekräftelsen.
- Kortuppgifter rör aldrig din server — vilket håller dig utanför den tyngsta delen av PCI.
Steg fyra och fem rymmer flest buggar. Kunden kan stänga webbläsaren innan hen kommer tillbaka; webhooken kommer ändå. Bygg på webhooken, inte på returen.
Gränsfallen där pengar försvinner#
De dyker inte upp i tester och dyker upp under första riktigt intensiva veckan.
| Situation | Vad som går fel | Hantering |
|---|---|---|
| Webhook kommer två gånger | Ordern behandlas dubbelt | Idempotens: behandla varje händelse-id en gång |
| Webhook före returen | Kapplöpning som skriver över orderstatus | Explicita statusövergångar, aldrig bakåt |
| Kunden stänger fliken efter betalning | Betalt, ingen order | Skapa ordern på webhooken, inte på returen |
| Betalning misslyckas efter lagerreservation | Lager låst utan försäljning | Låt reservationen förfalla efter ett fast fönster |
| Delåterbetalning | Bokföringen stämmer inte | Modellera återbetalningar som förstklassig händelse |
| Återkrav | Pengar borta, vara skickad | Spara bevis; riskregler vid höga belopp |
| Leverantören nere | Noll försäljning, inte mindre försäljning | En andra metod som reserv |
Regelverk och tester#
En kort lista som täcker det som blir dyrt när det saknas.
- Använd värdbaserade fält eller omdirigering så att kortuppgifter aldrig rör din server — det minskar din PCI-omfattning kraftigt.
- Stark kundautentisering är obligatorisk i Europa; testa flödet med ett kort som framtvingar den.
- Verifiera varje webhooks signatur. En overifierad webhook är en publik slutpunkt som kan markera ordrar som betalda.
- Visa priser inklusive moms för konsumenter och gör fraktkostnader synliga före sista steget.
- Spara order- och betaldata under den skattemässiga bevarandetiden, och inte längre än nödvändigt för personuppgifter.
- Testa återbetalningar och delåterbetalningar före lansering, inte när första kunden ber om det.
- Gör en riktig transaktion i produktion med ett riktigt kort och återbetala den till dig själv. Testläget täcker inte allt.
Vanliga frågor
Vilken betalleverantör ska jag välja?
Välj utifrån vilka metoder de stödjer på din marknad, vilka avgifter de tar vid din omsättning, och hur väl de integrerar med din plattform. För en svensk butik är Swish-stöd det första filtret. Prisskillnaderna mellan de stora leverantörerna är vid blygsam omsättning små nog att inte vara avgörande.
Behöver jag PCI-efterlevnad?
Ja, men omfattningen beror helt på hur du integrerar. Använder du värdbaserade betalfält eller omdirigering så att kortuppgifter aldrig rör din server faller din skyldighet tillbaka på den enklaste självutvärderingen. Behandlar du kortuppgifter själv hamnar du i ett helt annat regelverk — nästan ingen butik bör göra det.
Varför behöver jag webhooks när det finns en retur-URL?
För att returen beror på kundens webbläsare. Stänger hen fliken, tappar uppkopplingen eller fastnar på banksidan kommer returen aldrig — men pengarna är ändå dragna. Webhooken kommer från leverantörens server och kommer fram oavsett. Bygg ordern på webhooken och använd returen bara för att visa något för kunden.
Hur undviker jag dubblerade ordrar?
Gör webhookhanteringen idempotent: spara händelse-id för varje behandlad webhook och ignorera upprepningar. Leverantörer skickar om webhooks när bekräftelse uteblir, så dubbla leveranser är normalt beteende, inte ett fel. Utan den kontrollen skickar du två bekräftelsemejl och drar lagersaldot två gånger.
integrera betallösningswish webbutikbetalleverantörwebhook betalningpci-efterlevnadonlinebetalningar
