Który tryb integracji Shufti jest odpowiedni dla Twojego stosu? Wyjaśnienie API, SDK i klienta internetowego

Według raportu Postman's State of the API 2024, 43% programistów uważa integrację API za najbardziej czasochłonne zadanie programistyczne. W przypadku zespołów dodających weryfikację tożsamości do produktu objętego regulacjami, niewłaściwa integracja nie tylko opóźnia dostawę, ale także tworzy luki w zgodności, których późniejsze usunięcie jest kosztowne.

Shufti oferuje pięć różnych trybów integracji, każdy zaprojektowany z myślą o innej kombinacji wymagań technicznych, ograniczeń wdrożenia i harmonogramów uruchomienia. Niniejszy przewodnik opisuje każdy tryb w scenariuszu, w którym najlepiej się sprawdza, dzięki czemu Twój zespół może podjąć decyzję raz i wdrożyć produkt.

Dlaczego plik binarny SDK lub API nie spełnia oczekiwań?

Większość treści dotyczących weryfikacji tożsamości skierowanych do programistów ujmuje decyzję o integracji jako kwestię binarną: SDK czy API. Takie ujęcie pomija trzy inne tryby, które istnieją właśnie dlatego, że nie każdy produkt jest usługą zaplecza, a nie każdy zespół dysponuje tygodniami pracy inżynierskiej.

Architektura integracyjna Shufti opiera się na rzeczywistej dystrybucji produktów wymagających weryfikacji: natywnych aplikacji mobilnych, internetowych przepływów wdrażania, stosów zgodności bez kodu oraz wdrożeń korporacyjnych z wymogami suwerenności danych. Każdy tryb obsługuje jeden z tych kontekstów. Interfejs API RESTful nie jest z natury lepszy od klienta internetowego; jest lepszy dla konkretnego rodzaju zespołu budującego konkretny rodzaj produktu.

Pięć trybów integracji Shuftiego

1. Interfejs API RESTful

Interfejs API RESTful firmy Shufti zapewnia pełną kontrolę nad procesem weryfikacji. Serwer wysyła żądanie weryfikacji, Shufti je przetwarza, a wyniki są zwracane asynchronicznie za pośrednictwem webhooków (danych HTTP POST dostarczanych do punktu końcowego po zakończeniu weryfikacji). Ten sam punkt końcowy API obejmuje wszystkie produkty Shufti: weryfikację dokumentów, dopasowywanie twarzy, AML screening, KYB i inne.

Użyj tej opcji, gdy: potrzebujesz weryfikacji serwer-serwer, przetwarzania wsadowego lub ścisłego powiązania z istniejącą warstwą orkiestracji. Inżynierowie back-end w firmach z branży technologii finansowych i usług finansowych zazwyczaj wybierają tę ścieżkę, gdy logika weryfikacji musi być osadzona w ich własnym systemie zarządzania cyklem życia użytkownika, a nie po stronie klienta. Wsparcie techniczne jest najwyższym z pięciu trybów, ale równie wysoki jest stopień kontroli. Ponad 83% obciążeń przedsiębiorstw opiera się na interfejsach API do komunikacji danych i automatyzacji, a API Shufti zostało zaprojektowane tak, aby od samego początku działać w ramach tej infrastruktury.

2. Zestawy SDK dla urządzeń mobilnych

Mobilne zestawy SDK firmy Shufti Są dostępne na systemy Android, iOS, Flutter, React Native i Cordova. Zarządzają przechwytywaniem dokumentów, wykrywaniem żywotności i biometrią twarzy bezpośrednio na urządzeniu, przekazując przetworzone wyniki do procesu weryfikacji Shufti.

Użyj tego, gdy: tworzysz natywną aplikację mobilną, a jakość przechwytywania danych biometrycznych jest priorytetem. Mobilne zestawy SDK uzyskują bezpośredni dostęp do potoku kamer urządzenia, co oznacza, że ​​mogą wykrywać ataki polegające na wstrzyknięciu kamery i prezentacjach na poziomie, którego nie są w stanie dorównać kanały oparte na przeglądarce. Jest to zgodne z zasadami zapewnienia uwierzytelniania w NIST SP 800-63B, które rozpoznają natywny dostęp do urządzenia jako najsilniejszy kanał weryfikacji biometrycznej. SDK obsługuje interfejs użytkownika przechwytywania; Twoja aplikacja zarządza przepływem sesji.

3. Klient internetowy (dostosowana strona weryfikacyjna/iFrame)

Hostowany klient internetowy Shufti to gotowy proces weryfikacji, który można osadzić w sesji przeglądarki za pośrednictwem ramki iFrame. Szufti Obsługuje interfejs użytkownika, pobieranie dokumentów i danych biometrycznych oraz dostarczanie wyników. Po zakończeniu weryfikacji otrzymujesz webhook, bez konieczności samodzielnego tworzenia i utrzymywania interfejsu użytkownika weryfikacji.

Użyj tego, gdy: potrzebujesz internetowego procesu wdrażania i chcesz uniknąć tworzenia i utrzymywania interfejsu użytkownika weryfikacji. To zazwyczaj najszybsza ścieżka dla produktów internetowych: integracja trwa dni, a nie tygodnie, a obowiązki związane z przetwarzaniem danych wynikają z… Artykuł 32 RODO Są zarządzane po stronie Shufti i nie wymagają kompilacji mobilnego SDK. Wydajność techniczna jest niska lub średnia.

4. Twórca podróży

Kreator podróży to konfigurator przepływu weryfikacji Shufti bez kodu. Zespoły ds. zgodności i kierownicy operacyjni mogą tworzyć wieloetapowe przepływy weryfikacji (weryfikacja dokumentów, dopasowanie wyglądu, AML screening(weryfikacja adresu) z poziomu interfejsu wizualnego, bez konieczności pisania ani jednej linijki kodu.

Użyj tego, gdy: potrzebujesz szybko wdrożyć lub iterować proces weryfikacji, a ograniczeniem są możliwości inżynieryjne, a nie techniczna wykonalność. To również właściwy wybór dla zespołów, które potrzebują wielu przepływów specyficznych dla danego rynku: różnych krajów, różnych typów dokumentów, różnych list obserwacyjnych AML, z których wszystkie można konfigurować niezależnie. Biblioteka Journey Builder Zawiera gotowe przepływy obejmujące ponad 30 rynków. Czas uruchomienia: od kilku godzin do jednego dnia w przypadku pierwszego wdrożenia.

5. Na miejscu

Wdrożenie lokalne Shufti uruchamia cały stos weryfikacyjny w ramach własnej infrastruktury. Żadne dane weryfikacyjne nie opuszczają Twojego środowiska. Obowiązuje ten sam interfejs API RESTful, a Ty zachowujesz pełną kontrolę nad warstwą obliczeniową, miejscem przechowywania danych i śladem audytu.

Użyj tego, gdy: suwerenność danych jest wymogiem bezwzględnie obowiązującym. Z tej ścieżki korzystają banki i instytucje finansowe w jurysdykcjach o ścisłych wymogach dotyczących rezydencji danych, a także przedsiębiorstwa działające w ramach sektorowych ram ograniczających transfer danych w chmurze. Czas uruchomienia jest najdłuższy spośród pięciu trybów, ale jednocześnie zapewnia najwyższy poziom bezpieczeństwa: ryzyko ujawnienia danych w chmurze jest całkowicie wyeliminowane.

Wybór właściwego trybu: praktyczne ramy

Dwa pytania szybko zawężają wybór.

• Po pierwsze, gdzie znajduje się Twój produkt? Natywne aplikacje mobilne kierują się do Mobile SDK. Produkty internetowe domyślnie korzystają z klienta internetowego lub interfejsu API RESTful. Zespoły bez czasu pracy inżynieryjnej zaczynają od Journey Builder. Przedsiębiorstwa podlegające regulacjom i posiadające wymagania dotyczące rezydencji danych potrzebują rozwiązań lokalnych.
• Po drugie, ile czasu inżynierskiego jest dostępne? Jeśli harmonogram mierzy się w godzinach, Journey Builder jest realistyczną opcją. Dni do tygodnia: klient internetowy lub API. Tydzień do dwóch: API lub mobilny SDK. Otwarte wdrożenie korporacyjne: lokalne.

Zespoły wdrażające KYC w produkcie finansowym często zaczynają od klienta internetowego, aby jak najszybciej wdrożyć go zgodnie z przepisami, a następnie przechodzą do API po potwierdzeniu podstawowego przepływu pracy. Szerszy przewodnik po planowaniu tego cyklu życia jest dostępny w Integracja KYC Strategie zapewniające sprawne i zgodne z przepisami wdrożenie.

Jednoczesne korzystanie z wielu trybów

Korzystanie z więcej niż jednego trybu integracji Shufti w jednym produkcie jest powszechne i celowe architektonicznie. Aplikacja usług finansowych może uruchamiać klienta internetowego do wdrażania w przeglądarce, pakiet Mobile SDK w swojej natywnej aplikacji oraz interfejs API RESTful do ponownego sprawdzania AML w tle, przy czym wszystkie trzy interfejsy łączą się z tą samą platformą, pulpitem nawigacyjnym i danymi dotyczącymi zgodności. Aby dokładniej przyjrzeć się działaniu warstwy API w szerszym kontekście, usługi weryfikacji tożsamości stos, zobacz API KYC:Co to jest, jak działa, integracja i przypadki użycia.