Varför ett klick blev tjugo sekunder
Första gången jag testade Pay N Play på en sportbok satt jag på pendeln mellan Stockholm och Uppsala. Matchen startade om åtta minuter, jag hade aldrig varit på sajten förut, och jag hann ändå lägga mitt spel innan domaren blåste igång. Det var 2017, och då upplevdes det nästan magiskt. Idag, efter tolv år i branschen och otaliga genomlysta integrationer, vet jag att det inte är magi. Det är ett tämligen brutalt välkoordinerat samspel mellan bank, identitetsleverantör, betaltjänst och operatör — där varje aktör kör sin del på millisekunder.
Den här artikeln plockar isär det samspelet bit för bit. Jag tänker visa exakt vad som händer mellan att du klickar på ”Sätt in” och att pengarna landar på ett spelkonto som tekniskt sett inte fanns för fem sekunder sedan. Vi ska gå igenom rälsen, autentiseringslagret, lagstiftningen som möjliggör allt, samt nya generationen Azura som Trustly rullade ut tidigt 2025 och som halverade login-tiderna ytterligare. Om du läser bara en teknisk genomgång om Pay N Play i år, hoppas jag att det är den här.
En siffra att hålla i bakhuvudet medan du läser: Trustly redovisar en genomförandegrad på 98,8 procent för insättningar i sin gaming-vertikal, en uttagsframgång på 99,7 procent och en bedrägerinivå på 0,008 procent. Det är inte marknadsföringsspråk — det är de bakomliggande siffror som förklarar varför hela den svenska bettingbranschen, från de stora till de nylanserade, byggt om sina onboarding-flöden runt just den här tekniken under det senaste decenniet.
Trustly som betalrälsen — varför det inte är en vanlig betallösning
Det första missförståndet jag stöter på, även hos folk som jobbat länge i branschen, är att Trustly skulle vara ”ungefär som Klarna fast för spel”. Det är fel på en grundläggande nivå. Klarna är en kreditgivare som lägger sig som mellanhand mellan dig och säljaren. Trustly är något annat — en autentiserad pull-pay-mekanism som direktöverför pengar mellan din bank och operatörens bank, utan att vare sig kort, kreditgränser eller mellankonton är inblandade. När jag förklarar det för folk brukar jag säga: Trustly är inte ett betalningsmedel, det är en räls som dina egna pengar åker på.
Den rälsen är imponerande till sin skala. Trustly är anslutet till ungefär 12 000 banker globalt, hanterar drygt 9 000 handelspartners och servar mer än 650 miljoner konsumenter på trettio plus marknader. För spel specifikt är produkten Pay N Play live i Sverige, Finland, Estland, Nederländerna och Storbritannien, med över 250 anslutna varumärken. Volymen i 2023 låg på cirka 600 miljarder kronor i bearbetade transaktioner med en intäkt på cirka 2,75 miljarder kronor — en årlig tillväxt på 14 procent. När en sådan volym går genom ett enda system blir robustheten en egenskap i sig, inte en marknadsföringsfras.
Tekniskt sett bygger Trustly på open banking-API:er och PSD2-mandaten som tvingade europeiska banker att öppna sina kärnsystem för tredjepartsleverantörer från 2018. Innan PSD2 var Trustly tvungna att jobba med mer eller mindre snickrade integrationer per bank — i praktiken byggde de en ”screen scraping”-arkitektur som krävde att användaren lämnade ifrån sig sina internetbanksinloggningar. Det fungerade, men det var skört. Med PSD2 blev allt det formaliserat: banken får en lagstadgad skyldighet att leverera betalningsinitiering på ett standardiserat sätt, vilket Trustly konsumerar via sina API-integrationer mot varje bank.
Det är därför Trustly inte ser likadan ut hos varje bank. Inloggningssidan du möter när du sätter in pengar är inte Trustlys — det är din egen banks autentiseringsflöde, som Trustly bara orchestrar. Du loggar in med BankID, du godkänner överföringen, och Trustly får tillbaka två saker: en bekräftelse att pengarna är på väg och ett paket med verifierad kunddata som banken redan vet om dig (namn, personnummer, adress, ofta även taxering). Det är just det här verifierade datapaketet som gör Pay N Play möjligt — det är vad som skiljer den moderna registreringsprocessen från alla föregångare.
BankID som autentiseringslagret — den svenska anomalin
Om Trustly är rälsen så är BankID lokomotivet, och här blir den svenska situationen verkligen unik. Inget annat europeiskt land har en så hög penetration av en enda elektronisk identitet. BankID hade i 2024 ungefär 8,6 miljoner unika användare i Sverige, vilket motsvarar 99,9 procent av alla svenskar mellan 18 och 67 år. Det betyder i praktiken att den åldersgrupp som har laglig rätt att betta i Sverige redan har den tekniska förutsättningen för Pay N Play installerad i mobilen. Det är en grund som är svår att översätta till andra marknader — i Finland funkar det med vissa förbehåll, men varken Tyskland, Nederländerna eller Storbritannien har något i närheten av samma täckning.
Volymen av användning är minst lika talande. Under 2024 användes BankID ungefär 7,5 miljarder gånger, upp från 7,1 miljarder året innan. Tjänsten är integrerad i runt 7 500 anslutna tjänster i månaden. Av dessa transaktioner går 51 procent till bank- och finanssektorn, 18 procent till mobila betalningar, 26 procent till annan privat sektor och 5 procent till offentlig förvaltning. Spelbranschen är inte stor i den uppdelningen, men eftersom varje Pay N Play-flöde innehåller minst två och ofta tre BankID-signeringar — login, betalningssignering, eventuellt sessionssignering — blir betting och casino tillsammans en synlig konsument av infrastrukturen.
Sedan 1 maj 2024 är funktionen Secure Start obligatorisk för alla företag som använder BankID. Den lägger till ett extra skyddslager mot phishing genom att kräva att användaren startar BankID-flödet på sin egen enhet, och det går inte längre att kringgå med ett uppslaget BankID i bakgrunden. Konkret innebär det att om någon försöker lura dig att öppna BankID med en QR-kod från ett annat fönster, kommer signeringen att misslyckas. För Pay N Play är det här en synlig friktion — flödet kräver fler bekräftelser idag än för två år sedan — men det är också en av anledningarna till att bedrägerinivåerna håller sig under en hundradels procent.
BankID-flödet vid en Pay N Play-insättning kan se ut på tre sätt: med biometrik (ansikte eller fingeravtryck), med PIN-kod, eller med QR-kod om du startar betalningen i en webbläsare på datorn och har BankID i mobilen. Den tredje varianten är tekniskt lite mer omständlig, men den fungerar identiskt — efter signeringen får banken samma typ av godkännande, och dataflödet ut till operatören är detsamma. Det är något jag noterade tidigt: oavsett hur du loggar in är produkten i andra änden identisk.
Open banking och PSD2 — lagstiftningen som möjliggjorde flödet
Något jag alltid tar upp när jag pratar Pay N Play med utländska kollegor är att den tekniska lösningen är en konsekvens av lagstiftning, inte tvärtom. PSD2-direktivet — Payment Services Directive 2 — antogs av EU 2015 och fick obligatoriska tekniska standarder via SCA-RTS i september 2019. Det är därifrån två saker härstammar: kravet på stark kundautentisering (SCA) för i princip alla elektroniska betalningar över ett visst belopp, och rätten för tredjepartsleverantörer som Trustly att initiera betalningar mot bankerna utan att gå via kortsystem.
SCA är vad som tvingar fram BankID-signaturen i Pay N Play-flödet. Direktivet kräver två oberoende faktorer från tre kategorier: något du vet (lösenord, PIN), något du har (mobil, fysisk dosa), något du är (biometrik). En BankID-signering på mobilen uppfyller två av tre i ett enda steg — du har enheten där BankID är installerat, och du verifierar med biometri eller PIN. Det är en av få implementationer i Europa där SCA känns elegant snarare än friktionsskapande.
Den andra halvan, payment initiation, är vad som tillåter Trustly att över huvud taget röra dina pengar. Före PSD2 var det här en gråzon, där banken kunde välja att blockera tredjepartsleverantörer på godtyckliga grunder. Idag har banken en lagstadgad skyldighet att tillhandahålla ett API för betalningsinitiering, och får inte behandla en autentiserad PISP-begäran sämre än en intern överföring. Det här regelverket är en sten i grunden för hela Pay N Play — utan PSD2 hade modellen aldrig skalat över EU.
Det betyder också att jurisdiktion spelar roll. Spelar du på en sajt vars licens ligger utanför EU och EES, är det inte säkert att Trustly kan eller får använda PSD2-rälsen för transaktionen. Just därför funkar Pay N Play praktiskt sett bara mot operatörer med svensk eller annan EU-licens. Försöker du sätta in på en MGA-licensierad sajt från Curaçao via BankID, möts du oftast av att flödet bryts vid bankgränssnittet.
KYC och AML i bakgrunden — den osynliga delen som gör Pay N Play laglig
När jag sitter i tekniska genomgångar med personer som inte jobbat med spel brukar jag märka att den största ”wow”-faktorn är just KYC-aspekten. Hur kan ett spelbolag som lyder under stränga svenska AML-regler tillåta dig att börja spela utan att du har lämnat in en enda ID-handling? Det korta svaret är att du har lämnat in dem — du gjorde det när du skaffade BankID på din bank för flera år sedan, och Trustly hämtar de redan verifierade uppgifterna i samma sekund som du godkänner överföringen.
Vasilije Lekovic, VP of Gaming på Trustly, har beskrivit det här flödet rakt på sak: Pay N Play förenklar registreringen genom att spelaren bara gör en insättning, samtidigt som verifierad KYC-data hämtas i bakgrunden från bankkontot och från externa dataleverantörer, och delas med operatören som sedan skapar ett verifierat spelarkonto. Det är ungefär det jag försöker förmedla till mina kunder: KYC försvinner inte, den blir bara osynlig för spelaren.
I praktiken hämtas tre typer av data: identitetsdata (fullständigt namn, personnummer, folkbokföringsadress) som banken har KYC-verifierat redan när du blev kund där, ekonomiska indikatorer (kontosaldo i grova drag, ibland inkomstuppgifter via Skatteverket-kopplingar), och PEP/sanktionsdata (om du finns på listor över politiskt utsatta personer eller sanktionerade individer) via specialiserade dataleverantörer. Allt det här sammanställs till ett ”verified player package” som Trustly skickar till operatören enligt ett standardiserat schema.
Det finns en gräns för vad som kan automatiseras. Vid större insättningar — den exakta tröskeln varierar mellan operatörer, men 50 000 till 100 000 kronor över en kort period är vanligt — triggas Enhanced Due Diligence (EDD), vilket kan innebära att du blir ombedd att lämna ytterligare dokumentation om pengarnas ursprung. Det här är inte ett brott mot Pay N Play-tanken, det är en kontrollnivå som penningtvättslagen kräver, och som Spelinspektionen kontrollerar i sina tillsyner. Operatörer som missar EDD-kontroller får ofta saftiga viten.
Det finns också scenarier där den automatiserade KYC inte räcker. Om datapaketet från Trustly är ofullständigt — till exempel om banken inte returnerar en uppdaterad adress, eller om ditt namn matchar en sanktionslista — så bryts flödet och du hamnar i en manuell process. Det är ett av få ställen där Pay N Play läcker tillbaka till traditionell hantering, och det är värt att veta att det kan hända även om du gjort allt rätt.
Hela transaktionsflödet — sekund för sekund
Den bästa övning jag känner till för att förstå Pay N Play är att rita upp tidslinjen. Jag har gjort det otaliga gånger på whiteboards inför nya kollegor, och resultatet är alltid samma — folk underskattar grovt hur många kommunikationer som sker under de tjugo sekunder de upplever som ”ett klick”.
Sekund 0: Du landar på operatörens sajt och klickar ”Sätt in”. Operatörens frontend skickar en begäran till Trustlys API med en transaktionsnyckel, ett belopp och eventuella jurisdiktionsparametrar. Trustly returnerar en URL till en betalningssession.
Sekund 1–3: Du dirigeras till Trustlys betalningsgränssnitt, väljer din svenska bank från en lista. Bakom kulisserna laddas integrationsmodulen för just den banken — kod som vet exakt vilken sekvens av API-anrop och fält som krävs för att initiera en betalning där.
Sekund 3–8: Du loggar in med BankID. Banken validerar BankID-signaturen mot Finansiell ID-Teknik AB (företaget bakom BankID) och returnerar en autentiserad session till Trustly. Samtidigt kontrollerar Secure Start att begäran kommer från din enhet och inte är ett phishing-försök.
Sekund 8–12: Du ser betalningsdetaljerna och godkänner. En andra BankID-signering — den faktiska betalningssigneringen — sker. Banken skapar en payment instruction och flaggar pengarna som reserverade.
Sekund 12–15: Trustly får payment confirmation från banken och skickar ett deposit confirmation till operatören tillsammans med det verifierade kunddatapaketet. Operatörens player management system tar emot paketet, skapar (eller hämtar) ett spelarkonto, krediterar saldot och returnerar en sessionstoken.
Sekund 15–20: Operatörens frontend tar emot bekräftelsen, dirigerar dig till sportlobbyn med inloggad session, och saldot är synligt. Du kan placera spel.
De faktiska pengarna som banken senare fysiskt clearar är en helt separat kedja som sker via Riksbankens RIX-system och tar timmar eller dagar. Men för dig och för operatören är pengarna redan gångbara, eftersom Trustly garanterar betalningen — det är därför genomförandegraden ligger på 98,8 procent och inte på 100. De 1,2 procent som faller bort är fall där banken sent säger nej, och Trustly måste rulla tillbaka transaktionen.
Den tekniska elegansen i hela flödet är att de flesta felmöjligheter är fångade. Faller BankID-signaturen på sekund fem, ser du ett felmeddelande och har inte förlorat något. Faller bankgodkännandet på sekund åtta, dras inga pengar. Det är först när Trustly har en verifierad payment confirmation som operatören sätter igång kontoskapandet, och vid det laget är finansieringsrisken redan flyttad till Trustly.
Azura — den nya generationen Pay N Play
I januari 2025 gjorde Trustly en av de större tekniska kungörelserna i sin produkthistoria. Under ICE i London presenterades Azura — en ny generations Pay N Play som ska minska login-tiden från i snitt 48 sekunder till mindre än 10 sekunder, och tiden från första klick till första spel till mindre än 20 sekunder. Det låter som inkrementell förbättring tills man förstår vad det innebär arkitektoniskt: Azura ersätter den klassiska ”rita-upp-betalningssession-i-realtid”-modellen med en nodbaserad nätverksmodell där Trustly kan förhandlat-cacha betalningsinstruktioner och nästan eliminera väntetid mot bankerna.
Jussi Lindberg, Trustlys Chief Revenue Officer, har formulerat det så här när Azura lanserades: som de pålitliga pionjärerna bakom Pay N Play har Trustly konsekvent adresserat utmaningarna i spelindustrin samtidigt som de drivit innovation, och tio år efter att de omformade branschen är de stolta över att presentera nästa utveckling i player engagement, inspirerad av återkoppling från sina kunder. Det är typiskt CRO-prosa, men under formuleringen finns en konkret produktförändring: Azura är inte ett upgrade, det är en omarkitektur.
Effekterna går utöver login-tid. Trustly rapporterar att det nya nätverket fördubblar transaktionshastigheten i genomsnitt och höjer den genomsnittliga transaktionsstorleken med 10 procent — den senare siffran är intressant eftersom den tyder på att friktionsminskningen påverkar inte bara om spelare deponerar, utan hur mycket de deponerar. Den siffran måste läsas mot bakgrund av att Pay N Play redan höjer insättningar per spelare med 44 procent jämfört med operatörer utan tekniken, en intern statistik från Trustly som branschen brukar referera till.
Något som inte alltid kommuniceras tydligt är att Azura rullas ut gradvis. Operatörer behöver explicit migrera till nya integrationen, och under 2025 var det få stora svenska bookmakers som hade gjort fullständig övergång. Du som spelare märker det genom att vissa sajter känns dramatiskt snabbare i deposit-flödet sedan andra halvan av 2025, medan andra fortfarande kör klassiska Pay N Play. Båda fungerar, men skillnaden i upplevd hastighet är märkbar.
Är du tekniskt nyfiken kan jag rekommendera att du går vidare till min separata genomgång av BankID-flödet steg för steg, där jag går djupare in på de tre signeringsmomenten och vad som faktiskt skickas över API-gränssnitten i varje steg.
Var flödet faktiskt brister — tekniska felpunkter
Trots de imponerande siffrorna är Pay N Play inte ofelbart, och som någon som granskat hundratals supportärenden vet jag att felmönstren är rätt förutsägbara. Den vanligaste kategorin är BankID-relaterad: signaturen tar för lång tid och timar ut, mobilen tappar internetanslutning mitt i flödet, eller Secure Start fångar något som ser ut som phishing och blockerar transaktionen. Det här fångas oftast upp och flödet kan startas om utan att pengar dras felaktigt.
Andra felklassen är banksidan. Vissa svenska banker — utan att namnge dem — har historiskt haft sämre PSD2-API:er än andra, vilket märks som lägre framgångsgrad just hos dem. Underhållsfönster, batch-jobb och periodiska systemuppdateringar kan slå ut Trustly-flödet helt under en period. Det är därför du ibland möts av ”Banken är tillfälligt otillgänglig” på en Pay N Play-sajt — det är inte spelbolaget som är nere, det är PSD2-API:et hos din bank som inte svarar.
Tredje kategorin är jurisdiktionsproblem. Reser du utomlands och försöker spela på en svensk sajt med svenskt BankID kan det fungera, men Trustly kan också lägga blockeringar baserat på IP-geografi. Det är inget som är tekniskt nödvändigt — BankID i sig fungerar globalt — utan ett medvetet val från Trustly och operatören för att uppfylla licensvillkor och AML-krav.
Den kanske mest underskattade felkällan är timing kring helger och kvällar. Även om Pay N Play-flödet i sig är dygnetruntfungerande, har vissa svenska banker fortfarande underhållsfönster nattetid när PSD2-API:erna är nere. Det syns som spike i misslyckade depositer mellan ungefär 02:00 och 04:00 vissa veckor. Det är ett problem som Azura adresserar i viss mån genom sin nodarkitektur, men inte ett som försvunnit helt.
Slutligen finns en kategori som inte är tekniskt fel utan kompliansorienterad: när systemen avsiktligt stoppar dig. Spelpaus-registrering är det mest synliga exemplet — om du finns i registret blockeras Pay N Play-flödet i samma sekund som BankID identifierar dig, oavsett om operatören vill ta emot pengarna. Det är inget bug, det är produktens viktigaste skyddsfunktion.