Architecture Overview

How the Integration Fits Together · Version 1.5 · October 2026

This page gives you a high-level, end-to-end view of a Mubeen integration before you dive into the code. It shows the two independent channels that make up the integration and how requests travel from your customers and your servers to Mubeen — and back.

Two Channels, One Decision

A Mubeen integration is built from two independent data channels that come together to produce a single risk decision:

Channel	Who sends it	Where it goes	What comes back
Fingerprint collection	Your customer's device, via the Mubeen SDK	Directly to Mubeen's collection endpoint (fp.*.mubeen.ai)	A stable device ID
Risk validation	Your backend	Mubeen's validation API (api.*.mubeen.ai)	A risk decision (score, level, recommended action)

The key idea: the device fingerprint never passes through your servers. Your customer's browser or mobile app sends it straight to Mubeen and receives a device ID in return. Your systems only ever handle that lightweight device ID, which you then attach to the risk-context payload your backend sends for scoring.

Why the fingerprint goes direct

Sending the fingerprint straight from the device to Mubeen keeps the signal accurate (it isn't reshaped by a proxy hop), keeps raw fingerprint data out of your infrastructure, and means your backend only deals with a single opaque device_id value.

High-Level Data Flow

The diagram below shows the full picture: your customers on the left, your own systems in the middle, and Mubeen on the right. Notice the fingerprint path (steps 1–2) is a direct round trip between the device and Mubeen that never touches your backend.

Direct channel — device ⇄ MubeenValidation channel — backend ⇄ MubeenResponse / optional feedback

The fingerprint never passes through your servers — your backend only ever handles the device ID it returns.

Step-by-Step Round Trip

The numbered steps below trace a single user action — say, a sign-in or checkout — from the moment the page loads to the final decision your backend acts on. Each number matches an arrow in the diagram above.

1. Fingerprint collected — When your page or app loads, the Mubeen SDK collects device and browser signals and sends them directly to Mubeen's collection endpoint.
2. Device ID returned — Mubeen returns a stable device_id to the SDK on the device.
3. Device ID handed to your frontend — Your frontend reads the device_id from the SDK.
4. Device ID reaches your backend — Your frontend passes the device_id to your backend alongside the user's action (via form field, API call, etc.).
5. Risk-context payload sent — Your backend assembles a payload from your own systems — user, transaction, payment, and network data — plus the device_id, and POSTs it to Mubeen's validation API.
6. Decision returned — Mubeen scores the request and returns a request ID, risk score, risk level, and a recommended action (log, allow, challenge, review, block).
7. Feedback (optional) — Once the real outcome is known (e.g. chargeback, confirmed-good), your backend can report it back to Mubeen to improve future accuracy.

Where to Go Next

• Client-Side Integration (HTML) — drop the JavaScript SDK into a web page (steps 1–3).
• Client-Side Integration (React) — the same, for a React SPA.
• Android Device Intelligence / iOS Device Intelligence — collect the device ID from a mobile app.
• Server-Side Integration — send the risk-context payload and handle the decision (steps 5–7).
• Self-Hosted Deployment — run both Mubeen's data plane and control plane on your own infrastructure instead of using the hosted API above.