3D Secure bei Krypto-Zahlungskarten fehlgeschlagen? Ursachen und Lösungen

Beim Online-Einkauf oder beim Bezahlen von Abonnements mit einer Krypto-Zahlungskarte kann eine unerwartete Situation auftreten: Die Karte verfügt über ausreichend Guthaben, Kartennummer und Ablaufdatum wurden korrekt eingegeben, doch auf der Zahlungsseite erscheint „3D Secure authentication failed“ oder „Authentication unsuccessful“. Mitunter hat der Karteninhaber seine Identität bereits bestätigt, aber die Zahlung schlägt trotzdem fehl.

Diese Meldungen weisen nicht zwangsläufig auf dasselbe Problem hin. Eine Transaktion kann während der 3D-Secure-Authentifizierung abgebrochen worden sein. Ebenso ist es möglich, dass die Authentifizierung erfolgreich abgeschlossen wurde, die Zahlung aber anschließend bei der Autorisierung abgelehnt wurde.

Für die Fehlersuche sollte deshalb zunächst geklärt werden, in welcher Phase der Fehler aufgetreten ist. Erst dann lässt sich entscheiden, ob die Karteneinstellungen überprüft, der Händler kontaktiert oder der Kartenherausgeber eingeschaltet werden sollte.

Was bedeutet eine fehlgeschlagene 3D-Secure-Authentifizierung?

3D Secure (3DS) ist ein Authentifizierungsprotokoll für Online-Kartenzahlungen, das heute überwiegend auf dem Standard EMV 3-D Secure basiert. Es ermöglicht Händlern, Zahlungsdienstleistern, Kartennetzwerken und Kartenherausgebern den Austausch von Authentifizierungsinformationen. Dadurch lässt sich besser feststellen, ob die zahlende Person zur Nutzung der Karte berechtigt ist.

Der entsprechende Dienst von Visa heißt Visa Secure, bei Mastercard trägt er den Namen Mastercard Identity Check.

Eine reguläre 3DS-Authentifizierung erfolgt üblicherweise auf einem von zwei Wegen:

• Reibungslose Authentifizierung (Frictionless Flow): Der Kartenherausgeber bewertet die Transaktion anhand von Risikosignalen wie Transaktionsbetrag, Geräteinformationen und Händlerdaten. Eine zusätzliche Handlung des Karteninhabers ist nicht erforderlich.

• Authentifizierung mit zusätzlicher Prüfung (Challenge Flow): Der Karteninhaber muss seine Identität durch einen weiteren Schritt bestätigen, etwa durch Eingabe eines Einmalpassworts (OTP), Freigabe der Transaktion in der App des Kartenherausgebers oder eine andere unterstützte Authentifizierungsmethode.

Erscheint kein Fenster zur Eingabe eines Codes, bedeutet das daher nicht, dass der Händler kein 3DS verwendet hat. Die Authentifizierung kann im Hintergrund abgeschlossen worden sein oder möglicherweise noch gar nicht erfolgreich begonnen haben. Entscheidend ist das vom Zahlungsdienstleister zurückgemeldete Authentifizierungsergebnis.

Die technischen Grundlagen beider Abläufe erläutert das Whitepaper von EMVCo zu EMV 3-D Secure.

Authentifizierung und Zahlungsautorisierung sind unterschiedliche Schritte

3DS dient der Authentifizierung (Authentication). Die Zahlungsautorisierung (Authorization) entscheidet dagegen, ob eine Transaktion genehmigt wird.

Selbst wenn der Karteninhaber ein OTP korrekt eingibt oder seine Identität in einer App bestätigt, kann der Kartenherausgeber die Zahlung aufgrund unzureichender Deckung, geltender Transaktionslimits, des Kartenstatus oder seiner Risikokontrollen ablehnen.

Bei Krypto-Zahlungskarten ist diese Unterscheidung besonders wichtig. Einige Produkte nutzen ein zuvor aufgeladenes Guthaben. Andere setzen voraus, dass Krypto-Vermögenswerte beim Bezahlen umgetauscht werden, oder bestimmen den verfügbaren Betrag anhand anderer Finanzierungsmechanismen. Ein in der Kontoübersicht angezeigter Bestand an USDT oder USDC bedeutet nicht automatisch, dass diese Vermögenswerte unmittelbar für die Autorisierung der aktuellen Transaktion genutzt werden können.

War die Authentifizierung bereits erfolgreich, sollte die weitere Prüfung dem Autorisierungsergebnis gelten, statt immer wieder neue Bestätigungscodes anzufordern.

Zunächst prüfen, was beim Bezahlvorgang passiert ist

Die Meldung „Payment Failed“ beschreibt häufig nur das endgültige Zahlungsergebnis, nicht unbedingt die zugrunde liegende Ursache. Selbst bei der Anzeige „3DS Failed“ kann eine weitere Prüfung der Authentifizierungs- und Autorisierungsdaten notwendig sein.

Diese Tabelle hilft bei der Eingrenzung des Problems, ersetzt aber keine Transaktionsprotokolle. Wenn die Zahlungsseite des Händlers keinen konkreten Fehlercode anzeigt, können Nutzer in der Regel nicht selbst feststellen, ob die Störung bei der Authentifizierung oder der Autorisierung aufgetreten ist.

OTP nicht erhalten? Entscheidend ist das Karteninhaberkonto, nicht nur das Plattformprofil

Einmalpasswörter sind eine verbreitete Methode für eine zusätzliche 3DS-Authentifizierung. Über welchen Kanal sie zugestellt werden, hängt jedoch vom jeweiligen Kartenherausgabedienst ab.

Das Unternehmen hinter der Marke einer Krypto-Zahlungskarte muss nicht mit dem tatsächlichen Kartenherausgeber identisch sein. Auch die Telefonnummer, die bei der Registrierung auf einer Krypto-Plattform angegeben wurde, muss nicht der Nummer entsprechen, die im Karteninhaberkonto für den Empfang von 3DS-Codes hinterlegt ist.

Kommt kein OTP an, sollte zuerst die offizielle Kartenverwaltung geöffnet werden. Dort ist zu prüfen, ob die für die Transaktionsauthentifizierung hinterlegte Telefonnummer oder E-Mail-Adresse korrekt ist und ob das Produkt SMS, E-Mail oder eine App verwendet.

Bleibt eine SMS aus, können unter anderem Probleme mit internationalen Nachrichten, Filtermechanismen des Mobilfunkanbieters, ein Nummernwechsel oder eine Störung des Versanddienstes dahinterstecken. Allein aus dem fehlenden Nachrichteneingang lässt sich nicht ableiten, bei wem der Fehler liegt.

Nutzt die Karte Push-Benachrichtigungen in einer App, sollte geprüft werden, ob die Anmeldung in der offiziellen App besteht, die Netzwerkverbindung funktioniert und möglicherweise noch Transaktionen zur Freigabe ausstehen. Manche Authentifizierungsabläufe sehen überhaupt keine SMS vor.

Wer mehrere Codes erhält, sollte beachten, dass sie zu unterschiedlichen Authentifizierungssitzungen gehören können. Wiederholtes Anfordern neuer Codes kann vorherige Codes ungültig machen. Auch nach dem Schließen der Zahlungsseite kann die ursprüngliche Sitzung bereits abgelaufen sein.

In diesem Fall sollte zunächst geklärt werden, ob die Händlerbestellung noch bearbeitet wird und ob auf der Karte ausstehende Autorisierungen vorliegen. Erst danach sollte ein neuer Bezahlvorgang gestartet werden. Auf einer Seite mit abgelaufener Sitzung sind weitere Versuche nicht sinnvoll.

Sind die Kontaktdaten korrekt, kommen aber dauerhaft keine Authentifizierungsanforderungen an, sollte der Kartendienstleister oder Herausgeber den Versandstatus und den Authentifizierungsdienst prüfen. Wiederholte Änderungen der Rechnungsdaten auf der Händlerwebsite helfen hierbei nicht.

Die Authentifizierungsseite öffnet sich nicht oder kehrt nicht zum Händler zurück

Eine zusätzliche 3DS-Authentifizierung hängt nicht allein vom Kartenherausgeber ab. Sie setzt auch eine korrekte Integration der Händler-Zahlungsseite mit dem Zahlungsdienstleister voraus.

Im Browser kann die Authentifizierung in einem eingebetteten Fenster oder über eine Weiterleitung erfolgen. Nach Abschluss der Identitätsprüfung muss das System des Händlers das Ergebnis korrekt verarbeiten, damit die Zahlung fortgesetzt werden kann.

Bei einem leeren Fenster, einer endlos ladenden Seite oder einer fehlgeschlagenen Rückkehr zum Händler sollten folgende Punkte überprüft werden:

• Wurde die Zahlungsseite im integrierten Browser einer Social-Media-App oder eines E-Mail-Programms geöffnet?

• Beeinträchtigen Browsererweiterungen, Skriptblocker oder Datenschutzeinstellungen die Authentifizierungsseite?

• Wurde die Netzwerkverbindung während der Weiterleitung oder Authentifizierung unterbrochen?

• War die ursprüngliche Zahlungsseite nach der Bestätigung in der App noch aktiv?

Der einfachste Test besteht darin, die offizielle Händlerwebsite erneut in einem regulären Browser des Geräts aufzurufen und nach Prüfung des ursprünglichen Transaktionsstatus einen neuen Zahlungsversuch zu unternehmen.

Bei Bedarf können störende Browsererweiterungen vorübergehend ausgeschlossen werden. Zertifikatsfehler, Sicherheitswarnungen oder verdächtige Weiterleitungen dürfen dabei jedoch nicht ignoriert werden.

Funktioniert 3DS mit derselben Karte bei anderen Händlern problemlos, während auf einer bestimmten Website wiederholt Seitenfehler auftreten, sollte vorrangig deren Zahlungsintegration und Authentifizierungsablauf untersucht werden.

Treten dagegen bei mehreren voneinander unabhängigen Händlern ähnliche Fehler auf, sollte der Kartendienstleister den Authentifizierungsdienst auf Herausgeberseite prüfen. Ein Browserwechsel kann Kompatibilitätsprobleme der Benutzeroberfläche beheben, nicht aber einen fehlenden 3DS-Zugang, falsch konfigurierte Authentifizierungskanäle oder Systemstörungen beim Herausgeber.

Nach der technischen Architektur von EMV 3DS muss das händlerseitige 3DS-System mit dem Access Control Server (ACS) des Kartenherausgebers zusammenarbeiten, um die Authentifizierung durchzuführen. Der ACS kann auch von einem beauftragten Dienstleister betrieben werden. Karteninhaber können diese technische Kommunikation normalerweise nicht einsehen. Eine weitere Untersuchung erfordert deshalb meist die Unterstützung des Händlers, seines Zahlungsdienstleisters oder des Kartenherausgebers.

Warum verlangen manche Händler eine Authentifizierung und andere nicht?

Es ist nicht ungewöhnlich, dass dieselbe Krypto-Zahlungskarte bei verschiedenen Händlern unterschiedliche 3DS-Abläufe durchläuft.

Ob 3DS eingeleitet wird und ob der Karteninhaber eine zusätzliche Prüfung durchlaufen muss, hängt unter anderem von den Zahlungseinstellungen des Händlers, der Risikobewertung des Herausgebers, den Regeln der Kartennetzwerke und den geltenden regulatorischen Anforderungen ab.

Eine Transaktion kann ohne zusätzlichen Schritt authentifiziert werden, während eine andere die Eingabe eines OTP erfordert. Bei bestimmten Online-Zahlungen kann der Herausgeber die Autorisierung auch deshalb ablehnen und eine weitere Identitätsprüfung verlangen, weil der Händler die erforderliche Authentifizierung nicht durchgeführt hat.

Stripe kennzeichnet einen solchen authentifizierungsbezogenen Ablehnungsgrund mit authentication_required. Laut der offiziellen Dokumentation zu Ablehnungscodes müssen Zahlungsintegrationen diese Authentifizierungsanforderung normalerweise verarbeiten und den Karteninhaber gegebenenfalls erneut am Bezahlvorgang beteiligen.

Wurde die Transaktion jedoch bereits erfolgreich authentifiziert und meldet der Herausgeber weiterhin authentication_required, empfiehlt Stripe, den Kartenherausgeber zu kontaktieren. Daraus sollte nicht pauschal geschlossen werden, dass der Nutzer die Authentifizierung einfach immer wiederholen muss.

In Märkten wie dem Europäischen Wirtschaftsraum, in denen die Vorgaben zur starken Kundenauthentifizierung (Strong Customer Authentication, SCA) gelten, unterliegen Online-Kartenzahlungen zusätzlichen regulatorischen Anforderungen. SCA bedeutet nicht, dass bei jeder Transaktion ein Fenster zur Codeeingabe erscheinen muss. Zulässige Ausnahmen und die konkrete Ausgestaltung der Authentifizierung können den sichtbaren Ablauf beeinflussen.

Das gilt auch für Abonnementzahlungen. Beim erstmaligen Abschluss eines Abonnements kann eine Authentifizierung des Karteninhabers erforderlich sein. Spätere, die Voraussetzungen erfüllende, vom Händler initiierte Transaktionen können dagegen ohne erneute Beteiligung des Karteninhabers durchgeführt werden.

Bedeutet „Card not enrolled“, dass die Karte kein 3DS unterstützt?

Nein, nicht zwangsläufig.

„Card not enrolled“ kann darauf hinweisen, dass die 3DS-Registrierung des Karteninhaberkontos nicht abgeschlossen wurde, eine besondere Konfiguration des Kartenprogramms vorliegt oder der zuständige Authentifizierungsdienst die Karte nicht erkennt. Die genaue Ursache muss anhand der tatsächlichen Fehlerdaten geklärt werden.

Eine aktivierte Karte, eine abgeschlossene KYC-Prüfung oder ein Visa- beziehungsweise Mastercard-Logo beweisen für sich genommen nicht, dass die Karte die vom jeweiligen Händler geforderte 3DS-Authentifizierung unterstützt.

Krypto-Zahlungskarten können unterschiedliche Herausgeber und Authentifizierungsdienste nutzen. Selbst innerhalb derselben Marke kann sich die Konfiguration je nach Ausgaberegion, Kartenprogramm oder Produktversion unterscheiden.

Meldet der Händler ausdrücklich „3D Secure not supported“ oder „Card not enrolled“, sollten beim Kartendienstleister folgende Fragen geklärt werden:

• Ist die Karte für den jeweiligen 3DS-Authentifizierungsdienst freigeschaltet und dort registriert?

• Welche Authentifizierungsmethoden unterstützt das Kartenprogramm, und bestehen regionale oder produktspezifische Einschränkungen?

• Über welchen Weg lassen sich gegebenenfalls eine Registrierung abschließen, Authentifizierungsdaten aktualisieren oder der Dienst erneut aktivieren?

Außerdem muss zwischen der technischen 3DS-Fähigkeit und den Kartenakzeptanzregeln des Händlers unterschieden werden. Manche Händler schließen Prepaidkarten, virtuelle Karten oder Karten aus bestimmten Ausgaberegionen aus. Selbst ein vollständig funktionierendes 3DS-Verfahren garantiert daher nicht, dass der Händler die Karte akzeptiert.

Die Authentifizierung war erfolgreich. Warum wurde die Zahlung trotzdem abgelehnt?

Bestätigen die Daten des Händlers oder Herausgebers eine erfolgreiche 3DS-Authentifizierung, während die Zahlung anschließend abgelehnt wurde, sollte die weitere Prüfung auf die Autorisierung ausgerichtet werden.

Bei Krypto-Zahlungskarten mit vorab aufgeladenem Guthaben sind das verfügbare Kartenguthaben, Transaktionslimits und der Kontostatus wichtige Prüfpunkte. Bei Produkten, die Krypto-Vermögenswerte in Echtzeit umtauschen oder andere Finanzierungsmechanismen verwenden, müssen zusätzlich der tatsächlich verfügbare Ausgabenrahmen und die Bedingungen für den Mitteleinsatz geprüft werden.

Einige Händler übermitteln zudem Vorautorisierungen oder fordern eine Autorisierung über einen Betrag an, der vom angezeigten Kaufpreis abweicht. Das sind jedoch Fragen der Zahlungsautorisierung und keine 3DS-Authentifizierungsfehler.

Wenn im Kartenkonto ein ausstehender Betrag erscheint, die Händlerseite aber eine fehlgeschlagene Zahlung meldet, sollten zuerst der Bestellstatus und die Autorisierung überprüft werden. Mehrfaches erneutes Bezahlen kann in dieser Situation zu doppelten Autorisierungen oder zur vorübergehenden Blockierung mehrerer Beträge führen.

Weitere Hinweise zu Guthabenproblemen, Händlerbeschränkungen und gewöhnlichen Autorisierungsablehnungen enthält der UCard-Radar-Leitfaden zu abgelehnten Krypto-Kartenzahlungen.

Bei wiederholten Authentifizierungsfehlern nicht ständig neu versuchen

Schlägt dieselbe Zahlung mehrfach fehl, werden wiederholte Codeeingaben oder erneute Transaktionsversuche Probleme bei der Authentifizierungskonfiguration oder Systemverbindung meist nicht beheben. Sie können außerdem Beschränkungen für Authentifizierungsversuche auslösen.

In seiner Dokumentation zur Fehlerbehebung bei 3D Secure im Issuing-Geschäft erläutert Adyen, dass bei Karten, die über seinen Dienst ausgegeben werden, nach fünf aufeinanderfolgenden fehlgeschlagenen Authentifizierungen weitere 3DS-Versuche vorübergehend blockiert werden. Die Sperre wird gewöhnlich nach einer Stunde automatisch aufgehoben. Alternativ kann das Supportteam kontaktiert werden.

Adyen stellt diesen Kontrollmechanismus in Zusammenhang mit den regulatorischen Anforderungen der PSD2. Die Grenze von fünf Fehlversuchen und die einstündige Sperrdauer sind jedoch konkrete Implementierungsregeln dieses Dienstleisters. Sie dürfen nicht ohne Weiteres auf andere Kartenherausgeber übertragen werden.

Wenn derselbe Fehler zweimal hintereinander auftritt, insbesondere bei abgelehnten OTPs, nicht verfügbaren Authentifizierungsdiensten oder Hinweisen auf eine vorübergehende Kontobeschränkung, sollten die Versuche unterbrochen und die genaue Fehlermeldung sowie der Kartenstatus geprüft werden.

Häufig wechselnde IP-Adressen, falsche Angaben zur Kontoregion oder unzutreffende Rechnungsdaten lösen keine zugrunde liegenden Konfigurationsprobleme. Stattdessen können sie zusätzliche Sicherheitsprüfungen auslösen.

Händler oder Kartenherausgeber: Wer verfügt über die entscheidenden Fehlerdaten?

Die Fehlersuche bei Krypto-Zahlungskarten ist oft komplexer, als es die Benutzeroberfläche des Produkts vermuten lässt.

Eine Krypto-Plattform kann für Marke und Kundenservice zuständig sein, während ein lizenzierter Kartenherausgeber die Verantwortung für die Kartenausgabe trägt. Ein unabhängiger Prozessor kann Autorisierungen verarbeiten und ein spezialisierter ACS-Dienstleister die 3DS-Authentifizierung übernehmen.

Die App der Kartenmarke zeigt deshalb nicht unbedingt sämtliche Authentifizierungsversuche an.

Adyen Issuing liefert hierfür ein konkretes Beispiel. In der offiziellen Dokumentation zur Fehlerbehebung wird erläutert: Scheitert die 3DS-Authentifizierung und wird die Transaktion dadurch bereits in der Authentifizierungsphase gestoppt, wird keine Autorisierungsanfrage an Adyen gesendet. Folglich entstehen weder eine weitergeleitete Autorisierungsanfrage noch ein zugehöriger Webhook, und die Transaktion erscheint auch nicht in der Payments-Liste der Adyen Customer Area. Dies beschreibt einen bestimmten Verarbeitungsfall von Adyen Issuing. Daraus lässt sich nicht ableiten, dass alle Krypto-Zahlungskarten oder andere Kartenherausgeber dieselben Aufzeichnungsmechanismen verwenden.

Daher gilt: Fehlt ein Vorgang in der Transaktionsübersicht der Karte, beweist das nicht, dass der Händler keine 3DS-Authentifizierung versucht hat.

Welche Stelle zuerst kontaktiert werden sollte, hängt vom Fehlerbild ab:

Vor einer Supportanfrage sollten Transaktionsdatum und -uhrzeit einschließlich Zeitzone, Händlername, Betrag und Währung, die letzten vier Kartenziffern, die genaue Fehlermeldung, der erreichte Authentifizierungsschritt sowie der Status der Bestellung und ausstehender Autorisierungen zusammengestellt werden.

Dem Händler kann die Frage direkt so gestellt werden:

Können Sie bestätigen, ob für diese Transaktion eine 3D-Secure-Authentifizierung eingeleitet wurde, wie deren endgültiger Status lautet und ob die Zahlung die Autorisierungsphase erreicht hat? Falls die Authentifizierung fehlgeschlagen ist, können Sie den entsprechenden Fehlercode oder den Grund dafür nennen?

Solche Angaben helfen bei der Eingrenzung des Problems in der Regel wesentlich mehr als eine allgemeine Frage, warum die Zahlung nicht funktioniert.

Wie sind die 3DS-Statuscodes in transStatus zu verstehen?

Wenn der technische Support des Händlers detailliertere Authentifizierungsdaten bereitstellen kann, enthalten diese möglicherweise das Feld transStatus aus EMV 3DS.

Dieses Feld gibt den Status der Authentifizierung oder Kontoverifizierung an. Die Bedeutung im jeweiligen Kontext und die Darstellung können jedoch von der Nachrichtenphase, der Protokollversion und dem Dienstleister abhängen.

Die Codes C und D dürfen nicht automatisch als endgültiges Scheitern der Authentifizierung gewertet werden. Ebenso sind A und I nicht mit Y gleichzusetzen. Ob eine Authentifizierung tatsächlich abgeschlossen wurde, lässt sich nur unter Berücksichtigung der Nachrichtenphase, weiterer Ergebnisse und der Verarbeitung durch den Zahlungsdienstleister beurteilen.

Gemäß der 3DS-Protokollspezifikation von EMVCo steht I für Informational Only und bedeutet, dass die vom 3DS Requestor angegebene Challenge-Präferenz bestätigt wurde. Es ist kein Nachweis dafür, dass der Karteninhaber die Authentifizierung abgeschlossen hat.

In der API-Referenz für 3D Secure 2 von Adyen wird I dagegen mit „Authentication / exemption granted by Issuer“ beschrieben, also als vom Herausgeber genehmigte Authentifizierung beziehungsweise gewährte Ausnahme. Diese Formulierung stammt aus der spezifischen Schnittstellendokumentation von Adyen und darf nicht unmittelbar mit der Definition des EMV-3DS-Protokolls gleichgesetzt werden. Ebenso wenig ist eine Ausnahme von der Authentifizierung mit der erfolgreichen Authentifizierung gemäß Y identisch. Die Dokumentation führt außerdem transStatusReason-Codes auf, die Händlertechnikern eine weitergehende Untersuchung ermöglichen.

Karteninhaber können diese Felder normalerweise nicht unmittelbar einsehen. Sie können den Händler jedoch bitten, das endgültige Authentifizierungsergebnis zu bestätigen. Bei erfolgreicher Authentifizierung muss anschließend geprüft werden, ob eine Autorisierungsanfrage gesendet und gegebenenfalls vom Kartenherausgeber abgelehnt wurde.

Bei der Weitergabe von Screenshots oder Transaktionsinformationen sollten nur notwendige, entsprechend geschwärzte Angaben übermittelt werden. Vollständige Kartennummern, CVV, Kontopasswörter, Einmalcodes und Wallet-Wiederherstellungsphrasen dürfen keinesfalls weitergegeben werden.

Wer Krypto-Zahlungskarten häufig für Abonnements, grenzüberschreitende Online-Einkäufe oder digitale Dienste nutzt, sollte bereits vor der Beantragung einer neuen Karte prüfen, ob 3DS verfügbar ist, welche Authentifizierungskanäle unterstützt werden und wer im Fehlerfall Hilfe leistet. Diese Informationen sagen über die praktische Betreubarkeit einer Karte mehr aus als die pauschale Aussage, dass sie „weltweite Online-Zahlungen unterstützt“.