Biometrische Authentifizierung ($0.10) plus Geräte- & IP-Analyse ($0.03) liefern zwei PSD3-konforme SCA-Faktoren in einer einzigen Abfrage. Phishing-resistent. Drop-in-Ersatz für SMS-Einmalpasswörter.
SIM-Swap-sicher. Phishing-sicher. $0.13 pro Authentifizierung.
Die PSD3 löst SMS-Einmalpasswörter als Faktor für die starke Kundenauthentifizierung ab.
Didits gerätegebundene biometrische SCA blockiert SIM-Swaps, Echtzeit-Phishing
und SS7-Abfangen, für $0.13 pro Authentifizierung, mit einem Ergebnis in unter zwei Sekunden
und bereit für Dynamic Linking. 500 Verifizierungen pro Monat sind kostenlos.
So funktioniert's
In vier Schritten vom Sign-up zum verifizierten Nutzer.
Schritt 01
Workflow erstellen
Wähle die gewünschten Prüfungen aus, ID, Liveness, Face Match, Sanktionen, Adresse, Alter, Telefon, E-Mail, benutzerdefinierte Fragen. Ziehe sie im Dashboard in einen Flow oder poste denselben Flow an unsere API. Verzweige nach Bedingungen, führe A/B-Tests durch, kein Code erforderlich.
Schritt 02
Integrieren
Bette nativ mit unserem Web-, iOS-, Android-, React Native- oder Flutter-SDK ein. Leite auf eine gehostete Seite weiter. Oder sende deinem Nutzer einfach einen Link, per E-Mail, SMS, WhatsApp, überall. Wähle, was zu deinem Stack passt.
Schritt 03
Nutzer durchläuft den Flow
Didit hostet die Kamera, die Lichtsignale, die mobile Übergabe und die Barrierefreiheit. Während der Nutzer den Flow durchläuft, bewerten wir über 200 Betrugssignale in Echtzeit und verifizieren jedes Feld anhand autoritativer Datenquellen. Das Ergebnis liegt in unter zwei Sekunden vor.
Schritt 04
Du erhältst die Ergebnisse
Echtzeit-signierte Webhooks halten deine Datenbank synchron, sobald ein Nutzer genehmigt, abgelehnt oder zur Überprüfung gesendet wird. Frage die API bei Bedarf ab. Oder öffne die Konsole, um jede Session, jedes Signal zu prüfen und Fälle nach deinen Vorstellungen zu verwalten.
Für SCA entwickelt · Preis wie Infrastruktur
Zwei Faktoren. Eine Aufforderung. $0.13 pro Authentifizierung.
Echte starke Kundenauthentifizierung ist keine einzelne Prüfung, sie ist ein Rezept. Schalte Ausnahmen pro Workflow um. Eskaliere bei Risikosignalen auf einen Hardware-Schlüssel. Kein erneutes Deployment nötig.
Inhärenz (Passive Liveness + Face Match 1:1) plus Besitz (das gebundene Gerät des Nutzers). Standardmäßig PSD3-konform. Wissensfaktor (PIN, Passwort) optional und pro Workflow konfigurierbar.
Inherence (Passive Liveness + Face Match) plus possession (device-bound biometric approval).
PSD3-grade SCA in one prompt.
02 · Dynamic Linking
Eine Genehmigung. Gebunden an Betrag + Empfänger.
Bei Zahlungen bettet die Authentifizierungsanfrage den genauen Betrag und den Empfänger ein. Der Nutzer sieht diese direkt in der biometrischen Aufforderung. Jede Manipulation macht die Genehmigung ungültig, im PSR integriert.
The user sees this amount + payee in the biometric prompt itself.
03 · Warum SMS-OTP ausgedient hat
Phishing-resistent von Haus aus.
SIM-Swap-Betrug, Echtzeit-Phishing-Kits, SS7-Abfangen, all das untergräbt SMS-Einmalpasswörter. Gerätegebundene Biometrie mit Origin Binding blockiert jeden gängigen Angriff, den die Europäische Bankenaufsichtsbehörde in ihrer SCA-Stellungnahme 2024 genannt hat.
Edit thresholds in the no-code Workflow Builder. No redeploy.
05 · Über 200 Signale pro Authentifizierung
Über 200 Signale bei jeder Authentifizierung.
Geräte-Fingerprint, IP-Geolokalisierung, VPN-/Proxy-/Datacenter-Erkennung, New-Device-Flag, Verhaltensabweichungen. Eskaliere automatisch auf einen Hardware-Schlüssel, wenn das Risiko deinen Schwellenwert überschreitet.
$0.10 Biometrische Authentifizierung + $0.03 Geräte- & IP-Analyse = $0.13 pro starker Kundenauthentifizierung. SMS-Einmalpasswörter kosten $0.04-$0.07 plus Zustellfehler, Wiederholungsversuche und SIM-Swap-Verlustrisiko, das die Regulierungsbehörden in die PSD3 einpreisen.
201ErstelltWebhook spiegelt Betrag + Empfänger zur Verifizierung wider
Der Nutzer sieht Betrag + Empfänger direkt in der biometrischen Aufforderung. Dynamische Verknüpfung.Doku →
Agenten-fertige Integration
PSD3 SCA Flow in einem Prompt implementieren.
Füge dies in Claude Code, Cursor, Codex, Devin, Aider oder Replit Agent ein. Ergänze deinen Stack. Der Agent erstellt den Workflow, verbindet die dynamische Verknüpfung, bindet das SDK ein und liefert eine funktionierende Starke Kundenauthentifizierung in fünf Minuten.
didit-integration-prompt.md
You are integrating Didit's Strong Customer Authentication into a payment service provider, bank, EMI, or wallet to satisfy PSD3 / the Payment Services Regulation (PSR). Two factors in one prompt:
1. Inherence — Biometric Authentication: Passive Liveness + Face Match 1:1 against the user's previously-enrolled KYC selfie.
2. Possession — Device & IP Analysis: 200+ real-time fraud signals binding the auth to the user's known device.
Pricing (verified live 2026-05-16):
- Biometric Authentication: $0.10 per auth
- Device & IP Analysis: $0.03 per auth
- Total: $0.13 per Strong Customer Authentication
- First 500 verifications free every month, forever
- Re-uses the enrolled selfie from the original KYC — no re-enrolment
PRE-REQUISITES
- Production API key from https://business.didit.me (sandbox key in 60 seconds, no credit card).
- Webhook endpoint with HMAC SHA-256 verification of the X-Signature-V2 header.
- A workflow_id from the no-code Workflow Builder configured as a Biometric Authentication workflow (Passive Liveness + Face Match 1:1 + Device & IP Analysis).
- The user has previously completed a Didit KYC (the same enrolled selfie backs every subsequent auth).
STEP 1 — Open an authentication session
POST https://verification.didit.me/v3/session/
Headers:
x-api-key: <your api key>
Content-Type: application/json
Body (for login auth):
{
"workflow_id": "<wf id for SCA biometric auth>",
"vendor_data": "<your user id>",
"callback": "https://<your-app>/auth/callback",
"metadata": {
"purpose": "login",
"session_id": "<your front-end session id>"
},
"portrait_image": "<base64 JPEG of the user's KYC enrolment selfie, ≤ 1 MB — REQUIRED for SCA's inherence factor; OMIT only if the workflow is liveness-only>"
}
Body (for payment with dynamic linking):
{
"workflow_id": "<wf id for SCA biometric auth>",
"vendor_data": "<your user id>",
"callback": "https://<your-app>/payment/callback",
"metadata": {
"purpose": "payment",
"amount": "247.50",
"currency": "EUR",
"payee_account": "ES9121000418450200051332",
"payee_name": "<merchant or recipient>",
"transaction_reference": "<your internal transaction id>"
},
"portrait_image": "<base64 JPEG of the user's KYC enrolment selfie, ≤ 1 MB — REQUIRED for SCA's inherence factor>"
}
Response: 201 Created with the hosted session URL. Push the URL to the user via deep-link / push notification / in-app sheet.
STEP 2 — User completes the biometric auth
The user sees one prompt on their phone (or via the Didit SDK in your native app). Three things happen on the same screen:
1. The amount + payee are displayed (dynamic linking — the user explicitly approves THIS amount to THIS payee for payments).
2. Passive Liveness defeats screen replay, printed photo, mask, deepfake.
3. Face Match 1:1 matches the new selfie against the enrolled KYC selfie.
Device & IP Analysis runs server-side on the session. Sub-2-second median verdict.
STEP 3 — Read the signed webhook on the auth verdict
Didit POSTs to your callback. Session statuses (Title Case With Spaces):
Body (excerpted):
{
"session_id": "<uuid>",
"vendor_data": "<your user id>",
"status": "Approved",
"liveness": { "status": "Approved" },
"face": { "status": "Approved", "similarity_score": 0.94 },
"ip_analysis": { "status": "Approved", "vpn_detected": false, "datacenter_ip": false },
"metadata_echo": {
"amount": "247.50",
"payee_account": "ES9121000418450200051332"
}
}
Status enum (exact case): Approved | Declined | In Review | Resubmitted | Expired | Not Finished | Kyc Expired | Abandoned.
Verify the X-Signature-V2 header BEFORE reading the body — HMAC SHA-256 of the raw bytes with your webhook secret.
For payments, verify that metadata_echo.amount and metadata_echo.payee_account match the values you passed in. If they do not, REJECT the payment — it's a dynamic-linking violation.
STEP 4 — Branch on verdict
Approved → unlock the action (login, payment, account change).
In Review → hold the action, route to manual review queue.
Declined → block, log the attempt, surface a friendly "try again" to the user.
Resubmitted → the user re-submitted after a soft fail (poor lighting, occlusion); proceed if the latest status is Approved.
STEP 5 — Retrieve the full decision later
GET https://verification.didit.me/v3/session/{sessionId}/decision/
Headers:
x-api-key: <your api key>
Returns the full payload: liveness verdict (iBeta Level 1 anti-spoof certified), Face Match similarity score, device fingerprint, IP geolocation, VPN / proxy / datacenter flags, 200+ fraud-signal score, dynamic-linking echo, HMAC signature.
Use this for the audit-trail surface a regulator examines on Strong Customer Authentication coverage.
STEP 6 — Step up on risk
When Device & IP Analysis surfaces a high-risk signal (new device + high-value payment, VPN/proxy on a login, geolocation jump), your workflow can step up to:
- A separate hardware-key challenge (FIDO2 / WebAuthn)
- A trusted-beneficiary whitelist confirmation
- A manual-review hold
Encode the step-up policy in the no-code Workflow Builder — no redeploy required.
WEBHOOK EVENT NAMES
- Sessions: status changes flow through the standard session webhook.
Verify X-Signature-V2 on every payload.
CONSTRAINTS
- Session statuses use Title Case With Spaces. Never UPPER_SNAKE_CASE on a session.
- Dynamic linking is REQUIRED for payments — pass amount + payee in metadata, verify the echo on the webhook.
- The enrolled selfie that backs every SCA is the one captured during the user's original KYC — no separate enrolment step.
- PSD3 / PSR exemptions (low-value remote < EUR 30, contactless point-of-sale < EUR 50, recurring identical, trusted beneficiary, Transaction Risk Analysis tiers) are configured per workflow in the Business Console.
- Default record retention is 5 years per the EU AML and payments rules.
Read the docs:
- https://docs.didit.me/sessions-api/create-session
- https://docs.didit.me/sessions-api/retrieve-session
- https://docs.didit.me/integration/webhooks
Start free at https://business.didit.me — sandbox key in 60 seconds, 500 verifications free every month, no credit card.
Brauchst du mehr Kontext? Siehe die vollständige Moduldokumentation.docs.didit.me →
Compliant by Design
Ein neues Land mit einem Klick erschließen. Wir machen die Arbeit.
Wir gründen lokale Tochtergesellschaften, sichern Lizenzen, führen Penetrationstests durch, erhalten Zertifizierungen und passen uns jeder neuen Regulierung an. Um Verifizierungen in einem neuen Land zu starten, legst du einfach einen Schalter um. Über 220 Länder live, vierteljährlich auditiert und Pen-getestet, der einzige Identitätsanbieter, den eine EU-Mitgliedsregierung offiziell als sicherer als die persönliche Verifizierung eingestuft hat.
Pro starker Kundenauthentifizierung, Biometrische Authentifizierung + Geräte- & IP-Analyse.
<0s
End-to-End-Authentifizierungs-Ergebnis pro Session, auf Einsteiger-Android-Geräten.
0+
Echtzeit-Betrugssignale bei jeder Authentifizierung ausgewertet, VPN, Rechenzentrum, Geolocation-Drift, Geräte-Drift.
0
Kostenlose Verifizierungen jeden Monat, für jedes Konto.
Drei Stufen, eine Preisliste
Kostenlos starten. Nach Nutzung zahlen. Bis zum Enterprise-Level skalieren.
500 kostenlose Verifizierungen jeden Monat, für immer. Pay-as-you-go für die Produktion. Individuelle Verträge, Datenresidenz und SLAs (Service Level Agreements) für Enterprise.
Kostenlos starten → nur zahlen, wenn eine Prüfung läuft → Enterprise für einen individuellen Vertrag, SLA oder Datenresidenz freischalten.
FAQ
Häufige Fragen
What is Didit?
Didit is infrastructure for identity and fraud, the platform we wished existed when we were building products ourselves: open, flexible, and developer-friendly, so it works as a real part of your stack instead of a black box you integrate around.
One API covers verifying people (KYC, know your customer), verifying businesses (KYB, know your business), screening crypto wallets (KYT, know your transaction), and monitoring transactions in real time, on a stack built to be:
Fast, sub-2-second p99 on every session
Reliable, in production with 1,500+ companies across 220+ countries
Secure, SOC 2 Type 1, ISO 27001, GDPR-native, and formally attested by Spain's financial regulator as safer than verifying someone in person
The footprint underneath: 14,000+ document types in 48+ languages, 1,000+ data sources, and 200+ fraud signals on every session. The Didit infrastructure dynamically learns from every session and gets better every day.
What is Strong Customer Authentication, in plain English?
Strong Customer Authentication (SCA) is a rule from the EU's payment-services regulation that says: when a customer logs in to their account or initiates a payment, you must verify them using at least two of three independent factor categories.
The three categories:
Knowledge, something only the user knows (password, PIN, secret answer)
Possession, something only the user has (phone, hardware key, SIM-bound device)
Inherence, something only the user is (fingerprint, face, behavioural pattern)
The two factors must come from different categories, a password plus a security question is not SCA, because both are knowledge. A password plus a fingerprint is, because they cross categories.
A third requirement, dynamic linking, says the second factor for a payment must be tied uniquely to the transaction amount and payee, so a stolen code cannot be replayed against a different transaction.
What is PSD3, and how is it different from PSD2?
PSD3, short for Payment Services Directive 3, is the EU's 2026 rewrite of the rulebook PSD2 introduced in 2018. Alongside it sits the Payment Services Regulation (PSR) which is directly applicable across member states without national transposition.
Key changes over PSD2:
Fewer exemptions, the corporate-payments and trusted-beneficiary exemptions are tightened
Phishing-resistant SCA mandated, SMS one-time-password is being phased out as the sole second factor; FIDO2, device-bound biometrics, or app-based push become the new default
Open-banking access strengthened, banks must offer a clean, unified API; permissioned third-party providers get better technical terms
Fraud-liability clarified, payment service providers (PSPs) carry more of the fraud loss when their SCA was weak
Wider scope, wallet providers, electronic-money institutions (EMIs), and some crypto providers come into the regime
Transition is rolling, most SCA changes are expected to take effect 18 to 24 months after final adoption.
How fast is the verification for my end user?
The full flow normally takes under 30 seconds end-to-end, pick up the ID, snap the document, snap the selfie, done. That is the fastest in the market. Legacy KYC providers usually take more than 90 seconds for the same flow.
On the back end, Didit returns the result in under two seconds at p99, measured from the moment the user finishes the selfie to the moment your webhook fires. Mobile capture is tuned for slow phones and slow networks: progressive image compression, lazy software development kit load, and a one-tap hand-off from desktop to phone via QR code if the user starts on web.
Which transactions need SCA, and which are exempt?
Need SCA by default:
Customer login to a payment account
Initiating an electronic payment
Any action that could be exploited to commit payment fraud
Exempt (PSD3 keeps most PSD2 exemptions but tightens the thresholds):
Low-value remote transactions, under €30 single, with cumulative caps per customer
Contactless point-of-sale payments, under €50 single, with cumulative caps
Recurring transactions of identical amount and payee, SCA on first, exempt after
Trusted beneficiaries, user explicitly whitelists, but PSD3 tightens approval flow
Transaction Risk Analysis (TRA), under thresholds linked to your overall fraud rate (1, 5, 10, 25 basis points)
Corporate dedicated channels, when both ends are corporate users on a closed system
Getting the exemption math right is the highest-leverage SCA optimisation work most teams do, applied well it drops auth friction without raising fraud.
What happens if a user fails, abandons, or expires?
Every session lands on one of seven clear statuses, so your code always knows what to do:
Approved, every check passed. Move the user forward.
Declined, one or more checks failed. You can allow the user to resubmit the specific failed step (for example, re-take the selfie) without re-running the whole flow.
In Review, flagged for compliance review. Open the case in the console, see every signal, decide approve or decline.
In Progress, user is mid-flow.
Not Started, link sent, user has not opened it yet. Send a reminder if it sits too long.
Abandoned, user opened the link but did not finish in time. Re-engage or expire.
Expired, the session link aged out. Create a new session.
A signed webhook fires on every status change, so your database always stays in sync. Abandoned and declined sessions are free.
Where does my customer data live and how is it protected?
Production data is processed and stored in the European Union by default, on Amazon Web Services. Enterprise contracts can request alternative regions for jurisdictions whose regulators require it.
Encryption everywhere. AES-256 at rest across every database, object store, and backup. Transport Layer Security 1.3 in transit on every API call, webhook, and Business Console session. Biometric data is encrypted under a separate Customer Master Key.
Retention is yours to control. Default retention is indefinite (unlimited) unless you configure shorter, between 30 days and 10 years per application, and you can delete any individual session at any time from the dashboard or the API.
Certifications: SOC 2 Type 1 (Type 2 audit in progress), ISO/IEC 27001:2022, iBeta Level 1 PAD, and a public attestation from Spain''s Tesoro / SEPBLAC / CNMV that Didit''s remote identity verification is safer than verifying someone in person. Full report at /security-compliance.
Is Didit compliant for my industry?
Didit ships compliant by default for the regulators that matter to identity infrastructure:
GDPR + UK GDPR, controller / processor split, full Data Processing Agreement published, lead supervisory authority named (Spain''s AEPD).
AMLD6 + EU AML Single Rulebook, 1,300+ sanctions, politically exposed person, and adverse-media lists screened in real time.
eIDAS 2.0, EU Digital Identity Wallet aligned; reusable-identity ready.
MiCA (Markets in Crypto-Assets), ready for crypto on-ramps, exchanges, and custodians.
DORA, Digital Operational Resilience Act, EU financial-services operational resilience.
BIPA, CUBI, Washington HB 1493, CCPA / CPRA, US biometric privacy (Illinois, Texas, Washington) and California consumer privacy.
UK Online Safety Act, age-gating and child-safety obligations.
FATF Travel Rule, originator and beneficiary data on crypto transfers, IVMS-101 interoperable.
Same POST /v3/session/ API on every surface, the user-facing capture differs:
Web (desktop browser), Didit launches the auth flow in a popup; the user's phone receives a push notification, completes the biometric on the phone, and the popup closes with the approved verdict. Universal-link handoff if the user is on mobile web.
Native iOS / Android, drop in the Didit iOS or Android SDK, call the auth method, the OS-native biometric prompt appears (Face ID, Touch ID, fingerprint) backed by the secure enclave
React Native / Flutter / Cordova, official SDKs wrap the native modules; identical API surface
MCP server, if the auth lives behind an AI agent, the agent calls the auth tool, the user receives a push on their phone, approves, and the verdict returns
The same biometric template the user enrolled at KYC time backs every auth, no re-enrolment, no separate flow.
Does this work outside PSD3 / the EU?
Yes, the same auth bundle satisfies most equivalent global rules:
United Kingdom, the FCA's Strong Customer Authentication rules mirror PSD2/PSD3 in substance; Didit's auth bundle qualifies
United States, no nationwide SCA mandate, but bank regulators (OCC, Federal Reserve) and the Federal Financial Institutions Examination Council (FFIEC) recommend multi-factor authentication for high-value transactions; Didit drops in
Singapore, Monetary Authority of Singapore (MAS) Notice 644 mandates SCA on Internet banking
India, Reserve Bank of India two-factor authentication is mandatory on every domestic card transaction
Brazil, Banco Central rules align with PSD2-style SCA on instant payments
Australia, Japan, South Korea, equivalent multi-factor authentication requirements for banking and high-value e-commerce
One API, one auth bundle, every jurisdiction. The exemption math changes; the technical contract does not.
What does the auth event evidence look like for an examiner?
Every authentication produces a signed evidence record exportable from the Business Console:
The auth challenge, timestamp, session ID, requested factors
The biometric verdict, Passive Liveness pass/fail, Face Match similarity score (linked to the user's KYC reference selfie), iBeta Level 1 anti-spoof claim
The device verdict, device fingerprint, IP geolocation, VPN/proxy/datacenter flags, 200+ fraud-signal score
The dynamic-linking payload, amount, payee, timestamp, signed end-to-end
The full audit trail, every step state-machined from Pending to Approved or Declined, with reviewer notes if escalated
HMAC SHA-256 signature on the payload so chain-of-custody is provable
All records stored in the European Union (EU data centres), retained indefinitely while your subscription is active. Default record retention is 5 years per the EU AML and payments rules, extensible per your supervisor's guidance.