BankID i en app är mer än en inloggningsknapp. Det korta svaret är: ja, det går att bygga in BankID i en iOS- och Android-app, men det påverkar både scope, tid och totalkostnad. Ni behöver en väg som Relying Party (eget avtal eller via en BankID-as-a-Service-leverantör), test- och produktionsmiljö, tydliga flöden för samma enhet respektive annan enhet, och en plan för hur personnummer och syften hanteras. Utan det blir "vi lägger till BankID" lätt ett projekt i projektet.
Det längre svaret handlar om när BankID faktiskt behövs, skillnaden mellan inloggning och underskrift, vad som måste vara klart innan någon skriver kod, hur UX ska se ut i dagens Secure Start-era, och hur integrationen landar i ScriptSectors publicerade kostnads- och tidsspann. Den här guiden är skriven för dig som köper apputveckling - inte som en prislista för BankID-licenser.
På ScriptSector är BankID en erbjuden integration inom apputveckling. Vi bygger flödet in i appen och backend, men själva BankID-avtal, certifikat och eventuella tredjepartsavgifter hör till er sida (eller till er valda tjänsteleverantör).
När behöver appen egentligen BankID?
Alla appar behöver inte BankID. Många klarar sig med e-post och lösenord, magisk länk, social login eller en enklare företagsinloggning. BankID blir relevant när ni behöver stark svensk e-legitimation - typiskt när användaren måste kunna bevisa vem hen är på ett sätt som räcker för avtal, känsliga uppgifter eller reglerade flöden.
Vanliga fall där BankID är rätt verktyg:
- Inloggning till tjänster där fel identitet får affärsmässiga eller juridiska konsekvenser
- Underskrift av avtal, fullmakter eller samtycken i appen
- Hälsodata, ekonomi, försäkring, medlemskap eller andra flöden med höga krav på spårbarhet
- B2B- eller myndighetsnära appar där mottagaren kräver BankID
- Onboarding där ni behöver koppla ett konto till en verifierad person - inte bara till en e-postadress
BankID är fel verktyg när ni egentligen bara vill ha "enkel inloggning", när målgruppen inte har BankID, eller när ni bygger för en internationell marknad där svensk e-legitimation inte hjälper. Då är det bättre att välja en lättare auth-lösning och spara BankID till det flöde som faktiskt kräver det.
Inloggning är inte samma sak som underskrift
En vanlig miss i kravställningen är att säga "BankID" och mena tre olika saker.
| Behov | Vad användaren gör | Vad ni behöver tänka på |
|---|---|---|
| Stark inloggning | Identifierar sig för att komma in i appen eller ett konto | Session, återkommande inloggning, eventuellt "kom ihåg enhet", koppling till ert användarregister |
| Underskrift / signering | Bekräftar ett konkret dokument eller beslut | Tydlig text om vad som signeras, lagring av bevis, flöde om signeringen avbryts |
| Engångsverifiering | Bekräftar identitet en gång (t.ex. vid onboarding) | Vad som sparas efteråt, hur ni undviker att begära om i onödan |
Om "inloggning" i praktiken betyder BankID plus roller, koppling till befintligt kundregister och signering av villkor, är det inte samma uppgift som ett enkelt konto. Det är samma typ av scope-fälla som i guiden Hur lång tid tar det att utveckla en app?: otydliga ord blir dyrare projekt.
Vad måste vara på plats innan någon kodar?
BankID-integration i appen börjar sällan i Xcode eller Android Studio. Den börjar i avtal, miljöer och ansvar.
Eget avtal eller BankID-as-a-Service?
Som Relying Party (den part som begär identifiering eller underskrift) finns i praktiken två huvudvägar:
- Eget avtal mot BankID / bankerna. Ni blir Relying Party själva, hanterar certifikat, miljöer och uppföljning mer direkt. Passar när volym, kontrollkrav eller befintlig bankrelation gör det naturligt.
- BankID-as-a-Service / förmedlare. En leverantör ger er API, sandbox och ofta snabbare start. Passar många appar och MVP:er där ni vill komma igång utan att bygga hela avtalsspåret själva först.
Båda vägarna fungerar. Välj utifrån tid till produktion, intern kompetens, volym och hur kritisk kontrollen är - inte utifrån vilken som låter "mest enterprise" i en pitch. På ScriptSector utgår vi från den väg ni redan valt eller hjälper er att välja kategori innan integrationen låses i scope.
Certifikat, test och produktion
Oavsett väg behöver ni räkna med:
- Tillgång till testmiljö (sandbox) innan produktion
- Certifikat eller nycklar för rätt miljö
- Separata konfigurationer för utveckling, test och live
- En tydlig ägare hos er för avtal, fakturering och supportärenden mot BankID-sidan
- Backend som kan starta och följa upp en identifiering eller signering säkert - BankID ska inte "gömmas" bara i klienten
Utan testmiljö och dokumentation står utvecklingen still även om appen i övrigt är redo. Det är samma integrationsregel som gäller för betalningar och CRM.
UX: samma enhet, annan enhet och Secure Start
I nyare BankID-integration (API v6 / Secure Start) är same-device kopplat till autostarttoken och other-device till animerad QR - inte till att skicka personnummer in i auth-anropet som äldre flöden. BankID i mobilapp handlar lika mycket om flöde som om API. Användaren förväntar sig något som känns bekant från bank- och myndighetsappar.
Samma enhet (autostart)
När användaren redan är i er app på telefonen där BankID-appen finns, är målet ofta att starta BankID på samma enhet utan onödiga mellansteg. Bra UX här betyder tydlig status ("Öppnar BankID..."), hantering om BankID saknas eller är utloggat, och en trygg återkomst till er app när identifieringen är klar eller avbruten.
Annan enhet (QR / Secure Start)
När användaren sitter vid dator, surfplatta eller en annan telefon behöver flödet fungera med QR och dagens krav kring Secure Start: animerad QR och tydlig vägledning så att användaren förstår vilken enhet som ska scanna. Statiska genvägar och halvfärdiga "öppna BankID manuellt"-hack skapar support och avhopp.
Det ni bör designa innan utvecklingsstarten
- Var i appen BankID behövs (inloggning, en specifik handling, eller båda)
- Vad som händer om användaren avbryter
- Hur ni visar fel (timeout, avbrott, saknad BankID-app)
- Om ni behöver både samma-enhet och annan-enhet från dag ett
- Hur återkommande besökare loggar in utan att känna att varje öppning är en ny byråkrati
Bra BankID-UX är tråkig på rätt sätt: förutsägbar, kort och tydlig. Spektakulära genvägar som bryter mot BankID:s rekommenderade mönster kostar mer i support än de sparar i klick.
Så påverkar BankID kostnad och tid
BankID i sig är sällan hela appbudgeten. Det som kostar är att integrationen drar med sig kravställning, backend, UX-varianter, test och ofta mer än "en login-skärm".
ScriptSectors publicerade nivåer ger en realistisk ram (samma spann som i Vad kostar det att utveckla en app?):
| Typ av app | Ungefärlig nivå | BankID i praktiken |
|---|---|---|
| Enkel app | Från ca 40 000 kr | Ofta utan BankID; om det krävs växer scopet snabbt bortom "enkel" |
| MVP Sprint | 6 veckor, fast pris 60 000 kr exkl. moms | Kan inkludera nödvändiga integrationer, t.ex. BankID, om de ryms i överenskommet scope |
| Komplett företagsapp | Ca 200 000-500 000 kr | Vanlig nivå när inloggning, backend, admin och integrationer (ibland BankID) ingår |
| Avancerad lösning | Från ca 500 000 kr | Flera flöden, roller, signering, systemkopplingar och högre krav på drift |
Utöver utveckling kan tredjepartskostnader tillkomma för BankID, hosting, SMS, betalningar med mera - samma princip som i kostnadsguiden. Exakta BankID-avgifter beror på er avtalade väg (eget avtal eller tjänsteleverantör) och anges inte här som påhittade spann.
Publicering kräver fortfarande developer-konton: Apple Developer 149 USD/år och Google Play 25 USD engångsavgift. Det är oberoende av om appen har BankID eller inte.
Tidmässigt är BankID en klassisk "det tar längre om underlaget saknas"-integration. Med avtal, sandbox och klara UX-flöden kan det rymmas i en avgränsad MVP. Utan dem förlängs projektet även om själva kodningen är enkel. En MVP Sprint fungerar när BankID är prioriterat och inräknat - inte när det smygs in i vecka fem.
Personnummer och integritet (på hög nivå)
BankID innebär att ni hanterar starkt identifierande uppgifter. Det är inte juridiskt rådgivning, men som köpare bör ni tidigt svara på:
- Varför ni behöver personnummer eller annat identifierande resultat - syftebegränsning
- Vad som sparas efter en lyckad identifiering eller signering
- Vem som får se uppgifterna (support, adminpanel, underleverantörer)
- Hur länge ni behöver behålla bevis eller loggar
- Vad användaren får veta i appen och i integritetstexten
Bygg inte en app som "samlar personnummer för att det kan vara bra senare". Begär det ni behöver för det flöde ni faktiskt kör, och se till att backend, loggar och adminpanel inte läcker mer än nödvändigt.
Vanliga misstag när BankID ska in i appen
Att likställa BankID med "vanlig login". Då underskattas avtal, UX-varianter, felhantering och test.
Att börja koda innan Relying Party-vägen är vald. Utan sandbox och tydlig API-väg blir varje sprint gissningslek.
Att bara bygga samma-enhet-flödet. Många användare startar på webben eller en annan enhet. Saknas QR/Secure Start-flöde tappar ni dem.
Att glömma avbrott och fel. Timeout, avbruten identifiering och saknad BankID-app är normala fall - inte edge cases.
Att blanda ihop appstore-konton med BankID-avtal. Apple- och Google-konton behövs för publicering. BankID är en separat spår med egna krav.
Att lägga till signering "senare" utan att rita flödet. Signering påverkar copy, lagring och support. Planera det som ett eget användarflöde.
Om ni tar över en befintlig app där BankID redan finns (eller saknas) börjar rätt steg ofta med en teknisk granskning - samma logik som i Ta över en befintlig app.
React Native eller native?
BankID fungerar med både native (Swift/Kotlin) och React Native. Skillnaden ligger sällan i "går det?" utan i hur ni öppnar BankID-appen, hanterar återkomst till er app, och håller certifikat på servern. Teknikvalet för hela appen bör ni fortfarande göra utifrån produkt och förvaltning - se Apputveckling för iOS och Android: teknikval.
WebView - kort verifiering
Själva identifieringen sker i BankID-appen. Officiella svenska Relying Party Guidelines beskriver hur ni *startar* BankID-appen från webbläsare eller native app (bl.a. via https://app.bankid.com/... eller bankid://...), inte hur ni bäddar in BankID-gränssnittet i en egen WebView. Bygg inte ett eget "BankID-UI" i WebView. (Norsk BankID på bankid.no har egna, striktare WebView-regler - det är en annan produkt.)
Marknadsjämförelse av integrationskostnad (inte ScriptSectors offert)
ScriptSector publicerar inte ett fristående fastpris enbart för "BankID-modulen". För marknads kontext: Swivrr anger i sin prisguide för BankID-integration (2026) bland annat implementationskostnad 20 000-100 000 kr, enkel inloggning via BankID-as-a-Service på befintlig webbapp 20 000-35 000 kr, inloggning plus signering / ny webb eller mobil 35 000-60 000 kr, samt att mobilapp kan lägga till ungefär 20 000-40 000 kr. Löpande anges typiskt 300-2 500 kr/mån plus ca 0,50-2,50 kr per autentisering via mellanhand. Källa: swivrr.se/priser/vad-kostar-bankid-integration. Det är Swivrrs marknadsjämförelse - inte ScriptSectors offert.
Checklista innan ni ber om offert
- Behöver vi BankID i version ett, eller räcker enklare login först?
- Är det bara inloggning, eller även signering?
- Same-device, other-device/QR (Secure Start), eller båda?
- iOS, Android, webb - vilka ytor ska dela samma identitet?
- Eget avtal via bank eller BankID-as-a-Service?
- Finns beslutad hantering av personnummer och syfte?
- Finns testmiljö/testanvändare och någon som kan godkänna avtal snabbt?
- App Store-demokonto: hur loggar granskaren in utan er produktions-BankID?
- Ska BankID kopplas till befintligt användarregister eller CRM?
- Vem äger certifikat, leverantörskonto och produktionsnycklar efter leverans?
Vanliga frågor
Kan BankID ingå i en MVP?
Ja, om det är nödvändigt för kärnflödet och ryms i överenskommet scope. I ScriptSectors MVP Sprint kan nödvändiga integrationer, till exempel BankID, ingå när de prioriteras och avgränsas från början. Det som inte ryms får vänta till nästa iteration.
Behöver vi eget BankID-avtal för att bygga appen?
Inte alltid från dag ett, men ni behöver en klar Relying Party-väg: eget avtal eller en BankID-as-a-Service-leverantör. Utan någon av dem kommer ni inte till produktion på riktigt.
Tar BankID längre tid än vanlig inloggning?
Oftast ja, framför allt på grund av avtal, miljöer, fler UX-vägar och mer noggrann testning - inte för att själva knapptrycket är magiskt komplicerat. Se mer om hur scope styr tid i Hur lång tid tar det att utveckla en app?.
Vad kostar BankID utöver apputvecklingen?
Tredjepartskostnader kan tillkomma beroende på avtalad väg och volym. ScriptSector inventerar dem i projektet men publicerar inte generella BankID-prislistor här. Utvecklingskostnaden följer appens övriga omfattning enligt nivåerna ovan. För marknadsjämförelse, se Swivrr-avsnittet ovan.
Fungerar BankID med React Native?
Ja. React Native kan öppna BankID-appen och hantera återkomst, förutsatt att native-länkar sätts upp korrekt och att backend sköter det känsliga. Det är etablerat, men inte plug and play.
Så tar ni nästa steg med ScriptSector
Om ni vet att appen behöver stark svensk e-legitimation: börja med syfte (login, signering eller båda), Relying Party-väg, och vilka enheter användaren faktiskt sitter vid. Därefter går det att uppskatta om BankID ryms i en MVP, i en komplett företagsapp eller i ett större uppdrag.
På ScriptSector ingår BankID bland integrationerna vi bygger i apputveckling. Hör av dig via kontakt så går vi igenom behov, scope och vilken nivå som är rimlig innan ni låser budgeten.
---