iDIN erbjuder sitt eget anpassade användargränssnitt. Detta innebär att när du integrerar detta eID i din tjänst kommer slutanvändaren att omdirigeras till eID-leverantörens webbsida – som underhålls på leverantörens sida. Leverantörens webbsida kan inte bäddas in i en iframe på grund av säkerhetsskäl som beslutats av leverantörerna själva.

Eftersom slutanvändaren endast behöver interagera med leverantörens webbsida, rekommenderar vi att använda ett "API-only" flöde, vilket innebär att du inte kommer att använda Scrive's eID Hub frontend. Detta kan dock bero på om du också planerar att integrera fler eID-lösningar som kanske inte erbjuder sitt eget anpassade användargränssnitt.

När du använder API-only-flödet skapar och startar du en transaktion från din backend-applikation och omdirigerar sedan din slutanvändare till authUrl eller signUrl. Därefter omdirigeras slutanvändaren tillbaka till dig. Du behöver sedan samla in slutförande data om den genomförda transaktionen.

Om du väljer att arbeta med vår eID Hub frontend kan du använda samma flöde som med andra leverantörer och använda accessUrl som returneras när en ny transaktion skapas. I detta fall behöver du inte starta transaktionen, eftersom det görs av vår eID Hub frontend.

iDIN-prismodell

iDIN erbjuder två prissättningsalternativ:

Fullständig identifiering: Slutanvändarens uppgifter returneras (namn, födelsedatum, kön, adress, etc.).
Upprepad identifiering: Endast ett internt userID returneras.

För att använda alternativet för upprepad identifiering måste man säkerställa att ingen användardata efterfrågas genom att ställa in alla request*-flaggor på false när en ny transaktion skapas.