Welke Shufti-integratiemodus is geschikt voor jouw stack? API, SDK en webclient uitgelegd.

Volgens het State of the API 2024-rapport van Postman beschouwt 43% van de ontwikkelaars API-integratie als hun meest tijdrovende ontwikkeltaak. Voor teams die identiteitsverificatie toevoegen aan een gereguleerd product, leidt een verkeerde integratiekeuze niet alleen tot een vertraging van de levering, maar ook tot compliance-lacunes die later kostbaar zijn om te dichten.

Shufti biedt vijf verschillende integratiemodi, elk ontworpen voor een andere combinatie van technische vereisten, implementatiebeperkingen en implementatietijdlijnen. Deze handleiding koppelt elke modus aan het scenario waarin deze het beste past, zodat uw team in één keer de juiste beslissing kan nemen en direct kan lanceren.

Waarom de SDK- of API-binary de kern van de zaak mist?

De meeste content over identiteitsverificatie gericht op ontwikkelaars presenteert de integratiebeslissing als een binaire keuze: SDK of API. Deze benadering negeert drie andere mogelijkheden die juist bestaan ​​omdat niet elk product een backend-service is en niet elk team weken de tijd heeft om te ontwikkelen.

De integratiearchitectuur van Shufti is gebouwd rond de daadwerkelijke distributie van producten die verificatie vereisen: native mobiele apps, webgebaseerde onboardingprocessen, no-code compliance-stacks en bedrijfsbrede implementaties met vereisten voor gegevenssoevereiniteit. Elke modus is geschikt voor een van deze contexten. De RESTful API is niet inherent beter dan de webclient; hij is beter geschikt voor een specifiek type team dat een specifiek type product ontwikkelt.

De vijf integratiemodi van Shufti

1. RESTful API

De RESTful API van Shufti geeft uw backend volledige controle over de verificatieworkflow. Uw server dient een verificatieverzoek in, Shufti verwerkt dit en de resultaten worden asynchroon teruggestuurd via webhooks (HTTP POST-payloads die naar uw endpoint worden verzonden zodra de controle is voltooid). Hetzelfde API-endpoint is beschikbaar voor alle Shufti-producten: documentverificatie, gezichtsherkenning, AML screeningKYB en meer.

Gebruik deze optie wanneer: u server-naar-server verificatie, batchverwerking of een nauwe koppeling met uw bestaande orchestratielaag nodig hebt. Backend-engineers bij fintech- en financiële dienstverleners kiezen doorgaans voor deze aanpak wanneer de verificatielogica binnen hun eigen gebruikerslevenscyclusbeheer moet worden ondergebracht in plaats van aan de clientzijde. De technische inspanning is het grootst van de vijf modi, maar dat geldt ook voor de mate van controle. Meer dan 83% van de bedrijfsworkloads is afhankelijk van API's voor datacommunicatie en automatisering.En de API van Shufti is vanaf dag één ontworpen om naadloos in die infrastructuur te passen.

2. Mobiele SDK's

Shufti's mobiele SDK's Ze zijn beschikbaar voor Android, iOS, Flutter, React Native en Cordova. Ze beheren documentvastlegging, levendigheidsdetectie en gezichtsbiometrie direct op het apparaat en sturen de verwerkte resultaten door naar de verificatiepipeline van Shufti.

Gebruik dit wanneer: u een native mobiele applicatie bouwt en de kwaliteit van biometrische gegevensregistratie prioriteit heeft. Mobiele SDK's hebben rechtstreeks toegang tot de camerapipeline van het apparaat, wat betekent dat ze camera-injectie- en presentatieaanvallen kunnen detecteren op een niveau dat browsergebaseerde kanalen niet kunnen evenaren. Dit sluit aan bij de authenticatieborgingsprincipes in NIST SP 800-63Bdie native apparaattoegang beschouwen als het sterkste kanaal voor biometrische verificatie. De SDK verzorgt de gebruikerservaring bij het vastleggen van gegevens; uw applicatie beheert het sessieproces.

3. Webclient (aangepaste verificatiepagina / iFrame)

Shufti's gehoste webclient is een vooraf gebouwde verificatiestroom die u via een iFrame in een browsersessie kunt integreren. Sjoefti Het systeem verzorgt de gebruikersinterface, het vastleggen van documenten en biometrische gegevens, en de levering van de resultaten. U ontvangt een webhook zodra de controle is voltooid, zonder dat u zelf de verificatie-UI hoeft te bouwen of te onderhouden.

Gebruik dit wanneer: u een webgebaseerd onboardingproces nodig hebt en het bouwen en onderhouden van een verificatie-UI wilt vermijden. Dit is doorgaans de snelste route voor webproducten: integratie duurt dagen in plaats van weken, en de verplichtingen met betrekking tot gegevensverwerking vallen hieronder. AVG Artikel 32 worden beheerd door Shufti en er is geen mobiele SDK-build nodig. De technische belasting is laag tot gemiddeld.

4. Reisplanner

Reisbouwer Dit is Shufti's no-code verificatieworkflowconfigurator. Compliance-teams en operationele leiders kunnen meerstaps verificatieworkflows samenstellen (documentcontrole, gezichtsherkenning, enz.). AML screening(adresverificatie) via een visuele interface, zonder een regel code te schrijven.

Gebruik dit wanneer: u snel een verificatieproces moet implementeren of verbeteren en de beperkende factor de technische capaciteit is, en niet de technische haalbaarheid. Het is ook de juiste keuze voor teams die meerdere marktspecifieke processen nodig hebben: verschillende landen, verschillende documenttypen, verschillende AML-watchlistlijsten, die allemaal onafhankelijk van elkaar configureerbaar zijn. Journey Builder-bibliotheek Inclusief vooraf geconfigureerde workflows voor meer dan 30 markten. Doorlooptijd: enkele uren tot een dag voor een eerste implementatie.

5. Op locatie

De on-premises implementatie van Shufti voert de volledige verificatiestack uit binnen uw eigen infrastructuur. Er verlaten geen verificatiegegevens uw omgeving. Dezelfde RESTful API-interface is van toepassing en u behoudt volledige controle over de rekenlaag, de gegevensopslag en het auditspoor.

Gebruik deze optie wanneer: datasoevereiniteit een absolute vereiste is. Banken en financiële instellingen in rechtsgebieden met strenge regels voor dataopslaglocatie, of bedrijven die onder sectorspecifieke kaders vallen die de overdracht van data naar de cloud beperken, kiezen hiervoor. De implementatietijd is het langst van de vijf opties, maar de beveiliging is ook het hoogst: blootstelling van data aan de cloud wordt volledig geëlimineerd.

De juiste modus kiezen: een praktisch kader

Twee vragen beperken de keuze snel.

• Ten eerste, waar bevindt uw product zich? Native mobiele apps verwijzen naar de Mobile SDK. Webgebaseerde producten gebruiken standaard de Web Client of RESTful API. Teams zonder ontwikkeltijd beginnen bij Journey Builder. Gereguleerde ondernemingen met vereisten voor gegevensopslag hebben een on-premises oplossing nodig.
• Ten tweede, hoeveel ontwikkeltijd is er beschikbaar? Als de planning in uren wordt gemeten, is Journey Builder de meest realistische optie. Dagen tot een week: Webclient of API. Een tot twee weken: API of mobiele SDK. Implementatie voor een grote onderneming zonder vaste einddatum: On-premises.

Teams die KYC in een financieel product integreren, beginnen vaak met de webclient voor een zo snel mogelijke, conforme implementatie en migreren vervolgens naar de API zodra de kernworkflow bewezen effectief is. Een uitgebreidere handleiding voor het plannen van deze levenscyclus is beschikbaar in [link]. KYC-integratie Strategieën voor een soepel en wettelijk conform onboardingproces.

Meerdere modi tegelijk gebruiken

Het gebruik van meer dan één Shufti-integratiemodus in één product is gebruikelijk en architectonisch beoogd. Een applicatie voor financiële diensten kan bijvoorbeeld de webclient gebruiken voor onboarding via de browser, de mobiele SDK in de native app en de RESTful API voor AML-hercontrole op de achtergrond, waarbij alle drie verbinding maken met hetzelfde platform, dashboard en compliancegegevens. Voor een dieper inzicht in hoe de API-laag functioneert binnen een bredere context, identiteitsverificatiediensten stapel, zie KYC-APIWat het is, hoe het werkt, integratie en gebruiksscenario's.