Warum OTP-Nachrichten fehlschlagen – und wie man Zustellungsprobleme behebt.

Wenn ein Einmalpasswort nicht ankommt, bleibt der Benutzer auf der Anmelde- oder Bezahlseite hängen und steht kurz davor, den Vorgang abzubrechen. Besonders frustrierend für das Entwicklerteam ist, dass die Nachricht oft problemlos gesendet wurde – die API lieferte den Statuscode 202 zurück, die SMPP-Übermittlung wurde akzeptiert, und die Plattform zeigt eine Nachricht in der Warteschlange an. Der Fehler trat irgendwo im nachgelagerten Netzwerk auf, das für das Anwendungsteam nicht direkt einsehbar ist. Dieser Artikel beschreibt die wenigen Gründe für das Fehlschlagen von Einmalpasswörtern im Produktivbetrieb, wie man diese von vorhandenen Belegen unterscheidet und welche Lösungsansätze es jeweils gibt.

Die Bruchfläche ist kleiner als sie aussieht.

OTP-Übertragungen schlagen aus einem von sieben Gründen fehl, ungefähr in dieser Reihenfolge ihrer Häufigkeit: Ablehnung der Sender-ID beim Zielnetzbetreiber, ein sogenannter „Grey-Route Hop“, der die Nachricht verwirft oder verzögert, Drosselung durch das SMSC oder die Firewall, Auslösung von Inhaltsfiltern aufgrund einer Vorlage, Kodierungsfehler zwischen UCS-2-Inhalten und einer GSM-7-Vorlage, Netzwerküberlastung beim Zielnetzbetreiber und das Endgerät selbst ist nicht erreichbar (ausgeschaltet, außerhalb des Empfangsbereichs, Portierung mit veralteter Routing-Nummer). Alle anderen Fälle – beschädigte MSISDN, abgelaufene Anmeldeinformationen, Routing-Ausfälle – sind selten. Beheben Sie zunächst die häufigsten Fehler.

Lesen Sie die Lieferbestätigungen, nicht die Antwortkarte.

Der größte Fehler, den Teams begehen, ist, eine erfolgreiche Übermittlung (HTTP-Statuscode 202, ESME_ROK bei submit_sm) als Beweis für die Zustellung der Nachricht zu werten. Das ist nicht der Fall. Übermittlung bedeutet, dass die Plattform die Nachricht akzeptiert hat; Zustellung bedeutet, dass das Endgerät sie empfangen hat. Jedes OTP-System muss mit der Zustellbestätigung (Delivery Receipt, DLR) verknüpft sein, die später als Webhook oder deliver_sm-PDU eintrifft und einen von wenigen Statuscodes enthält: DELIVRD, UNDELIV, REJECTD, EXPIRED, UNKNOWN. Der erste Hinweis für jede OTP-Untersuchung ist die Verteilung des DLR-Status nach Route, Absender-ID, Zielbetreiber und Zeitfenster – nicht die Übermittlungserfolgsrate.

Die Fehlerursache lässt sich durch die Unterscheidung der Fehlerorte ermitteln.

Eine gründliche OTP-Untersuchung unterteilt den Fehler in vier Segmente und arbeitet sich vom letzten Signal rückwärts vor. Segment 1: Fehler bei der Übermittlung – die Plattform hat den Anruf abgelehnt, bevor er überhaupt das Ziel erreichte, meist aufgrund einer fehlerhaften Absenderkennung, einer nicht registrierten Vorlagenkategorie, eines nicht unterstützten Landes oder eines fehlenden Pflichtfelds. Segment 2: Akzeptiert bei der Übermittlung, aber nie an das Ziel-SMSC zugestellt – in der Regel ein Problem mit der Routenqualität oder eine Firewall-Blockierung. Segment 3: An das SMSC zugestellt und negatives DLR zurückgegeben – Inhaltsfilterung, Absenderkennung beim Betreiber gesperrt, Empfänger blockiert. Segment 4: Positives DLR, aber der Nutzer meldet keine Nachricht – Mobiltelefon ausgeschaltet, Portierung zu einem anderen Betreiber mit veralteter Routenführung, Spamfilter auf Betriebssystemebene oder unterdrückte Benachrichtigung. Die Behebungsmaßnahmen unterscheiden sich in jedem Segment; eine Vermischung der Segmente führt die Teams in die Irre.

Die sieben häufigsten Ursachen und was man dagegen tun kann

1. Ablehnung der Absender-ID

Viele regulierte Märkte – die VAE unter TDRA, Saudi-Arabien unter CST, Ägypten unter NTRA und Indien unter TRAIs DLT – verlangen, dass jede alphanumerische Absenderkennung vorab bei einer verifizierten juristischen Person registriert wird. Datenverkehr mit einer nicht registrierten Absenderkennung wird an der Betreibergrenze abgewiesen und führt zu einem negativen DLR-Wert (keine Zustellung der Nachricht), obwohl die Antwort auf die Übermittlung den Statuscode 202 lautete. Die Lösung ist die Registrierung. Zur Diagnose muss der Status UNDELIV/REJECTD mit der Absenderkennung und dem Zielland korreliert werden: Tritt bei allen Fehlern dieselbe Absenderkennung in einem Land auf, liegt das Problem an der Registrierung. Die erforderlichen Unterlagen finden Sie im Leitfaden zur Absenderkennungsregistrierung für GCC-Märkte.

2. Graue-Route-Hops

Günstige internationale SMS-Routen beinhalten oft einen oder mehrere Zwischenstationen über Partneraggregatoren oder SIM-Farm-Terminierungen. Jede dieser Zwischenstationen erhöht die Latenz, die Wahrscheinlichkeit stiller Paketverluste und die Wahrscheinlichkeit, dass die Firewall des Zielnetzbetreibers den Datenverkehr als unautorisierte A2P-SMS einstuft und blockiert. Typische Merkmale sind eine hohe Rate nicht zugestellter SMS (UNDELIV-Rate), hohe Latenzschwankungen und eine Zustellrate, die stark abfällt, sobald der Zielnetzbetreiber eine SMS-Firewall einsetzt oder aktualisiert. Die Lösung besteht darin, OTP über eine direkte Betreiberroute zu versenden; die damit verbundenen Vor- und Nachteile werden im Artikel „Direkte Routen versus Graue Routen“ (bzw. „Direct Routes vs. Grey Routes“) erläutert.

3. Drosselung am SMSC oder an der Firewall

Jeder Netzbetreiber und jede Firewall legt ein Limit für Transaktionen pro Sekunde (TPS) pro Absender-ID und Route fest. Wird dieses Limit überschritten, werden Nachrichten entweder sofort abgewiesen (im besten Fall – der Fehler ist sichtbar) oder in eine Warteschlange gestellt und verspätet zugestellt (im schlimmsten Fall – sie treffen ein, nachdem das Einmalpasswort (OTP) abgelaufen ist und der Benutzer bereits aufgegeben hat). Zur Diagnose werden die Spitzenwerte der Übermittlungen mit der Latenz-p95-Kurve verglichen: Eine stabile Latenzkurve unter konstanter Last, die bei Lastspitzen ansteigt, deutet auf eine Drosselung hin. Die Lösung besteht in der Ratenbegrenzung auf Anwendungsebene, um Lastspitzen abzufedern, und in der Aushandlung eines höheren TPS-Limits speziell für OTP-Verkehr.

4. Inhaltsfilter

Die Inhaltsklassifizierung von Mobilfunkbetreibern und Firewalls kann OTP-Vorlagen kennzeichnen, die Triggerwörter, URLs (die meisten Betreiber gehen streng gegen unbestätigte Kurzlinks in Transaktionsnachrichten vor), ungewöhnliche Absendernamen oder Layouts enthalten, die bekannten Phishing-Mustern ähneln. Typisch ist eine einzelne Vorlage, bei der plötzlich erhöhte Ablehnungsraten auftreten, während alle anderen Nachrichten problemlos zugestellt werden. Die Lösung liegt in der Optimierung der Vorlagen: kurze, standardisierte OTP-Texte, keine Kurzlinks und keine dringlichkeitsähnliche Formulierung. Falls die Vorlage reguliert ist (in einigen Märkten müssen Transaktionsvorlagen vorregistriert werden), muss sichergestellt werden, dass die registrierte Version mit der versendeten Version übereinstimmt – selbst kleine Abweichungen werden erkannt.

5. Kodierungsfehler

OTP-Vorlagen mit Nicht-ASCII-Zeichen (z. B. Akzentvokale, spezielle Anführungszeichen aus Designdokumenten, arabische Ziffern) führen zu einer stillen Aktualisierung der Nachricht von GSM-7 auf UCS-2. Dadurch verringert sich das Zeichenbudget pro Segment von 160 auf 70 Zeichen, was zu verketteten Nachrichten führt, die von einigen älteren Mobiltelefonen fehlerhaft zusammengesetzt werden. Zur Diagnose muss die tatsächlich gerenderte Vorlage Byte für Byte geprüft werden, nicht die Vorlage, wie sie vom Entwickler interpretiert wird. Die Lösung besteht in einer kodierungsbewussten Vorlagenprüfung und einer Build-Prüfung, die alle Nicht-GSM-7-Zeichen in einer Transaktionsvorlage kennzeichnet.

6. Netzwerküberlastung

Bei Großereignissen (Eid, Black Friday, Feiertage, größere Störungen) kommt es gelegentlich zu Überlastungen der SMSCs der Zielnetzbetreiber. Die Übermittlungen werden zwar angenommen, die Zustellungszeiten steigen jedoch von unter einer Sekunde auf mehrere Minuten. Eine einfache Lösung seitens des Absenders gibt es nicht. Die Abhilfe besteht darin, den Zustand (einen starken Anstieg der Latenz im 95. Perzentil über alle Routen zu einem Betreiber) zu erkennen und vor Ablauf des OTP-Fensters auf einen alternativen Kanal auszuweichen.

7. Mobilteil nicht erreichbar

Ein kleiner, aber hartnäckiger Anteil der OTP-Fehler ist nicht auf Infrastrukturprobleme zurückzuführen – das Mobiltelefon ist ausgeschaltet, befindet sich außerhalb des Empfangsbereichs, ist im Flugmodus, der Spamfilter des Anbieters blockiert unbekannte Absender oder es wurde zu einem neuen Anbieter portiert, sodass die Routing-Tabellen noch nicht synchronisiert sind. Die Signatur besteht aus abgelaufenen oder unbekannten Absender-IDs (DLRs), die über alle Routen und Absender-IDs verteilt sind, ohne dass ein bestimmter Anbieter identifiziert werden kann. Die Lösung ist die unten beschriebene Ausweichkette.

Erstelle das Diagnose-Dashboard einmal, nutze es für immer

Die meisten OTP-Untersuchungen stocken, weil das Team unter Zeitdruck Rohdaten auswertet. Teams, die schnell wieder auf die Beine kommen, nutzen ein Dashboard mit fünf Widgets: Verteilung des DLR-Status nach Zielbetreiber (das mit Abstand nützlichste Diagramm), End-to-End-Latenz (50/95/99 ms) pro Route, Zustellungsrate auf Sender-ID-Ebene, Zustellungsrate auf Content-Template-Ebene und eine Echtzeit-Zeitreihe von der Übermittlung bis zur Zustellung der letzten Stunde. Diese Dashboards sollten nur einmal eingerichtet werden. Sie entscheiden darüber, ob die Diagnose 40 Minuten oder 4 Stunden dauert.

Sanierungsmuster, die tatsächlich funktionieren

Direkte Bindungen nur für OTP

Marketing- und OTP-Traffic dürfen nicht denselben Knotenpunkt oder dieselbe Route nutzen. Marketing-Traffic ist kostensensibel, latenztolerant und kann Großhandelsrouten verwenden; OTP-Traffic ist latenzkritisch, zustellbarkeitskritisch und benötigt einen direkten Knotenpunkt. Eine gemeinsame Nutzung führt zu einer Überlastung des OTP-Pfads durch einen Marketing-Ansturm und beeinträchtigt die Routenreputation für OTP durch einen Marketing-Template-Trip-Filter.

Ausweichkette, automatisch und zeitlich begrenzt

Der Architekt berücksichtigt, dass ein einzelner Kanal gelegentlich ausfallen kann, und entwirft die Fallback-Kette entsprechend: Zuerst die WhatsApp-Authentifizierungsvorlage oder RCS, wenn der Nutzer über einen dieser Kanäle erreichbar ist, SMS als universeller Fallback und Sprach-OTP als letzte Option. Der Fallback muss automatisch (keine manuelle Wiederholung durch den Nutzer), zeitlich begrenzt (die Wartezeit bis zum Failover ist kürzer als die Geduld des Nutzers – typischerweise 8 bis 15 Sekunden) und bedingt sein (kein Failover bei positivem DLR; Failover bei Timeout oder negativem DLR). Der OTP-Code selbst muss einmal generiert und kanalübergreifend wiederverwendet werden, damit dem Nutzer nicht zwei gültige Codes angezeigt werden.

Duplikate bei jedem Wiederholungsversuch vermeiden

Wenn der Nutzer auf „Erneut senden“ tippt oder die Anwendung einen automatischen Wiederholungsversuch unternimmt, prüfen Sie, bevor Sie erneut senden. Die BroadNet-API akzeptiert keinen Idempotenzschlüssel, die Deduplizierung liegt also in Ihrem Code: Protokollieren Sie jeden Versand, bevor Sie ihn ausführen, speichern Sie die von der API zurückgegebene Nachrichten-ID und prüfen Sie vor jedem erneuten Senden den Status dieser Nachricht (siehe Idempotenz und sichere Wiederholungen). Ohne diese Prüfung führen ein langsamer, aber erfolgreicher erster Versand und ein automatischer Wiederholungsversuch dazu, dass zwei OTPs im Posteingang des Nutzers landen. Der Nutzer verwendet das ältere OTP, die Verifizierung schlägt fehl, und das Team gibt dem OTP-Dienst die Schuld, obwohl der Fehler in der Wiederholungslogik lag.

Sprachausgabe als Alternative für den Long Tail

Etwa ein Prozent der Nutzer erhält an einem beliebigen Tag aus den oben genannten Gründen keine SMS. Diese Nutzer wenden sich an den Support. Ein Sprach-OTP – ein Anruf, bei dem der Code vorgelesen wird – behebt dieses Problem in fast allen Fällen. Das ist der entscheidende Unterschied zwischen einem verärgerten Nutzer, der einen anderen Browser ausprobiert, und einem verzweifelten Nutzer, der aufgibt.

Wie Qualität in Zahlen aussieht

Ein gut konfiguriertes OTP-System, das in einem regulierten GCC-Markt über direkte Betreiberrouten mit einer funktionierenden Ausweichkette sendet, sollte Folgendes gewährleisten: eine End-to-End-Erfolgsrate von über 99,0 % (der Nutzer muss die erfolgreiche Bestätigung erhalten haben, nicht nur die Zustellung der Nachricht), eine p95-Latenz von unter fünf Sekunden auf dem primären Kanal und eine messbare, aber geringe Ausweichrate (1–3 %) für den sekundären Kanal. Sollten Ihre Werte deutlich schlechter ausfallen, liegt das Problem mit hoher Wahrscheinlichkeit an einer der sieben oben genannten Ursachen – diagnostizieren Sie die Ursache, anstatt zu raten.

Weiterführende Lektüre

• SMS-API versus SMPP – was ist besser für Unternehmen?
• Wie Banken die Zustellung von Einmalpasswörtern und Betrug überwachen sollten
• Wie sich die Flash-Call-Verifizierung auf die A2P-Einnahmen der Betreiber auswirkt
• Glossar – Was ist OTP?, Was ist ein DLR?, Was ist Flash-Call-Verifizierung?
• Produktseiten – OTP-Dienst und MyOTP Sprach-OTP
• Abdeckung — UAE A2P SMS- und OTP-Routing