| Multiexcerpt include | ||||||
|---|---|---|---|---|---|---|
|
Wir haben darauf geachtet, die Optimierungsansätze des neuen Protokolls messbar zu machen.
Value Proposition | |
|---|---|
Für Endkunden |
|
Für Händler |
|
Für Banken |
|
Wie setzen sich meine Zahlungen zusammen?
Die ersten beiden Dashboards geben einen Überblick über die Anteile der verschiedenen Protokolle und deren Performance.
Anteil der Zahlungen nach Protokoll
| Version | Beschreibung |
|---|---|
| non-3DS | Zahlungen ohne 3DS |
| 1.x | Zahlungen über das "alte" 3DS Protokoll |
| 2.x | Zahlungen über das neue 3DS Protokoll |
Sie können über einen Click auf die Icons im Tabellenbereich unterschiedliche Protokolle im Diagramm ausblenden, sodass Sie beispielsweise nur den Vergleich zwischen 3DS 1.x und 3DS 2.x sehen:
Performance der Versionen
Das Diagramm zeigt die Transaktionsanzahl nach Protokollen und listet als Balkendiagramm die Ergebnisse der Authentifizierungen. Per mouseover können Sie eine kleine Tabellenansicht der Aufteilung sehen.
Der untere Bereich zeigt Ihnen tabellarisch nach Protokollversion:
- Fehlgeschlagene Authentifizierungen
- Erfolgreiche Authentifizierungen
- Successful Attempts: 3DS wurde gestartet, aber Karteninhaber ist nicht für 3DS angemeldet
Neben der Gesamtanzahl sehen Sie auch die Anzahl der Transaktionen sowie die Antwort-Codes je nach Protokollversion.
Einfache Authentisierung: Frictionless
Der größte Mehrwert für Kunden und Händler, nämlich eine einfache Abwicklung, kommt über die Einführung der sogenannten "frictionless" Zahlungen. Hierbei erspart der Kartenausgeber seinem Endkunden die Authentisierung. Wie dieses Feature performt zeigt Ihnen das Diagramm "Authentication Type".
Auf der rechten Seite sehen Sie auf einen Blick die Ergebnisse der Karteninhaber-Authentisierung.
Bitte beachten Sie, dass die Nachrichten "Frictionless" und "Dynamic" neue Bestandteile von 3DS 2 sind: möchten Sie also diesen Aspekt beleuchten, wählen Sie bitte in den Filtern die Protokoll-Version 3D 2.x aus.
Beschreibung der Werte:
Authentication Type Code | Authentication Type | Beschreibung |
|---|---|---|
| 00 | Frictionless | Issuer hat den Karteninhaber nicht aufgefordert, den Authentifizierungsprozess zu durchlaufen |
| 01 | Static | Issuer fordert Authentifizierung mit statischem Passwort |
| 02 | Dynamic | Issuer fordert Authentifizierung mit einem dynamischen Passwort, üblicherweise SMS oder TAN oder OTP |
| 03 | Out of Band | Die Authentifizierung wird auf einem anderen Gerät durchgeführt, z. B. der Benutzer kauft am Desktop/Laptop ein und die Authentifizierung erfolgt über die Banking-App auf dem Mobiltelefon |
| 04 | Decoupled | Üblicherweise bei MOTO-Transaktionen: die Authentifizierung wird getrennt von der Anfrage durchgeführt |
| Not mapped | Zahlungen für die der Authentication Type aufgrund unterschiedlicher Parameter nicht ermittelt werden konnte. |
Fallback
Fallback bedeutet, dass eine 3-D Secure-Authentifizierung über das neue EMV 3-D Secure 2.x nicht möglich war (z. B. Issuer ist nicht bereit, Karteninhaber hat sich noch nicht angemeldet). Um Ihren Checkout zu retten, schaltet unsere Plattform auf das ältere 3-D Secure 1.x um. In der Tabelle werden die Summen der Zahlungen angezeigt, die mit der eingehenden 3-D Secure-Version ("Gestartet") und der zur Authentifizierung verwendeten 3-D Secure-Version ("Verarbeitet") verarbeitet wurden.
Da diese Funktion nur im neuen Protokoll verfügbar ist, wählen Sie bitte als Filter „3DS Verion Started 2.x“
Analyse auf Länderebene
Um Details bis hin zu betroffenen Ländern und Zahlungen einzusehen, haben wir folgende Auswertung vorbereitet. Neben den Kartenländern sehen Sie in einem Zeitstrahl die Entwicklung der Protokoll-Verteilung.
Wenn Sie die Kennzahlen eines Landes interessieren, clicken Sie dieses einfach in der Liste an und schon sehen sie sämtliche Kennzahlen für das betreffende Land.
SCA Excemptions
Die Entwicklung dieses Features zeigen wir Ihnen in der Entwicklung der Soft Declines. Dabei handelt es sich um Kreditkartenzahlungen, die automatisiert wiederholt worden sind, nachdem diese vom Issuer mit „Soft Decline“ abgelehnt worden sind. D.h.: der Issuer lehnt eine Autorisierung ohne Kundenauthentifizierung ab und besteht auf einer 3-D Secure Transaktion. Neben der Anzahl sehen Sie über die unterschiedlichen Ansichten auch erfolgreiche Autorisierungen.
Details zum Ablauf bei einem Zahlungsvorgang, welcher mit "Soft Decline" abgelehnt worden sind, finden Sie auf dieser Seite im Abschnitt: Handhabung von Soft Decline.
