https://a.storyblok.com/f/270183/1368x665/95fb939938/26sep-sanitize_and_validate_phone_numbers-blog_r2.jpg

Bereinigung und Validierung von Telefonnummern für den E-Commerce

Zuletzt aktualisiert am September 24, 2026

Lesedauer: 6 Minuten

Einführung

Die Qualität und Gültigkeit von Telefonnummern sind zwar kaum wahrnehmbare, aber dennoch hartnäckige Probleme im E-Commerce. Die beim Bezahlvorgang erfassten Numbers sind oft fehlerhaft, uneinheitlich formatiert oder gehören zu Anschlüssen, , die keine SMS empfangen können – und das merkt man in der Regel erst, wenn eine Zustellbenachrichtigung zurückkommt.

In diesem Artikel wird erläutert, wie man Telefonnummerndaten mithilfe des „Format Insight“ bereinigt (jede Nummer wird auf das E.164-Format) bereinigen und anschließend mit dem current_carrier Insight-Funktion validiert werden (Überprüfung, ob es sich um eine Mobilfunknummer handelt, die normalerweise SMS empfangen kann). Die Vonage Identity Insights API liefert in einem einzigen API-Aufruf sowohl eine bereinigte Nummer als auch die Bestätigung, dass diese SMS-fähig ist. Durch die kombinierte Nutzung der Formatierungsfunktion der Identity Insights-API und der aktuellen Netzbetreiber-Informationen können Sie jede Nummer vor der Speicherung in Ihrer Datenbank auf das E.164-Format bereinigen und sicherstellen, dass es sich um eine Mobilfunknummer handelt, bevor Sie diese für die Zustellung von Nachrichten verwenden.

Fehler bei der Desinfektion und Validierung

Ein gängiges Backend-Szenario ist folgendes: Ein Kunde füllt das Bestellformular aus, gibt seine Telefonnummer in einem beliebigen, für ihn natürlichen Format ein und bestätigt die Bestellung. Das HTML5-Eingabefeld vom Typ „Telefon“ akzeptiert die Eingabe. Der serverseitige reguläre Ausdruck überprüft, ob die Nummer zehn Ziffern enthält. Die Bestellung wird in die Datenbank geschrieben, eine Bestätigungs-E-Mail wird versendet und eine SMS mit den Lieferinformationen wird verschickt.

Dann passiert nichts: Es wird kein Fehler protokolliert, kein erneuter Versuch ausgelöst und keine Warnmeldung generiert. Einige Tage später eröffnet der Kunde ein Support-Ticket und fragt, wo seine Bestellung bleibt. Eine WISMO-Anfrage („Where Is My Order“), die Ihr Team Zeit und Geld kostet – und die sich vollständig hätte vermeiden lassen. Der Fehler hat zwei verborgene Ursachen:

  • Ein Fehler bei der Datenbereinigung: Die Nummer wurde im nationalen Format (4155551234) statt im E.164-Format (+14155551234) gespeichert.

  • Ein Validierungsfehler: Selbst wenn das Format korrekt wäre, handelt es sich bei der Nummer um eine Festnetznummer oder um eine Nummer, die früher eine Mobilfunknummer war und im letzten Monat zu einem Festnetzanbieter portiert wurde. Ihr regulärer Ausdruck erkennt zehn Ziffern und lässt die Nummer durch. Eine statische Nachschlagetabelle erkennt die ursprüngliche Netzbetreiberzuordnung und stuft die Nummer als „Mobilfunknummer“ ein. Die SMS wird in die Warteschlange gestellt und schließlich zurückgewiesen, sodass sie das Telefon des Kunden nie erreicht.

Überprüfung der Telefonnummer

Unter der Validierung einer Telefonnummer versteht man die Überprüfung, ob es sich bei einer Ziffernfolge um eine echte, erreichbare Telefonnummer handelt, an die eine SMS oder ein Voice-Anruf gesendet werden kann. Erfahren Sie mehr über die Gültigkeit von Telefonnummern.

Der Regex-Ausdruck erkennt falsche Ziffernlänge, nicht-ziffernmäßige Zeichen und fehlende Vorwahl. Der Regex-Ausdruck erkennt jedoch nicht, ob es sich um Mobilfunk- oder Festnetznummern sowie um virtuelle/VoIP-Nummern handelt.

Ergebnisse der API zur Netzbetreiberabfrage und Identitätsanalyse

Eine Betreiberabfrage ist eine Anfrage an den Echtzeit-Routing-Graphen des Mobilfunknetzes: Welcher Betreiber ist derzeit Inhaber dieser Nummer und um welche Art von Anschluss handelt es sich? Sie können die Identity Insights-API-Referenz , um mehr über die wichtigsten Felder zu erfahren, die von Identity Insights-API-Aufrufen zurückgegeben werden. Eine erfolgreiche Antwort sieht wie folgt aus:

{

  "request_id": "aaaaaaaa-bbbb-cccc-dddd-0123456789ab",

  "insights": {

    "format": {

      "country_code_iso2": "GB",

      "country_name": "United Kingdom",

      "number_international": "+447700900000",

      "number_national": "07700 900000",

      "is_format_valid": true,

      "status": { "code": "OK", "message": "Success" }

    },

    "current_carrier": {

      "name": "EE",

      "network_type": "MOBILE",

      "country_code": "GB",

      "network_code": "23430",

      "status": { "code": "OK", "message": "Success" }

    }

  }

}

Hinweis: Im Gegensatz zu netzwerkgestützten Informationen wie „SIM-Swap“ oder „Standortüberprüfung“ ist die format und current_carrier erfordern keine Genehmigung durch die Network Registry. Sie sind weltweit ohne zusätzliche Einbindung durch Netzbetreiber verfügbar.

Erste Schritte mit der Identity Insights-API

Am schnellsten können Sie sich davon in der Praxis überzeugen, indem Sie die Tutorial „Erste Schritte mit Identity Insights“ im Vonage-Dashboard. Geben Sie eine beliebige Telefonnummer ein, wählen Sie format und current_carrieraus und sehen Sie die Antwort in Echtzeit. Es gibt auch einen Demo-Modus mit vordefinierten Numbers, falls Sie die Funktion ohne Verwendung einer aktiven Nummer ausprobieren und die Antwort in Echtzeit sehen möchten. Es gibt auch einen Demo-Modus mit vordefinierten Numbers, falls Sie die Funktion ohne Verwendung einer aktiven Nummer ausprobieren möchten.

Screenshot of an Identity Insights app interface showing request payload, response payload, and configuration options for fraud detection.Getting Started with Identity Insights

Identity Insights in einem Node.js-Projekt einrichten

Sie könnten die heute erlernte Theorie in die Praxis umsetzen und die Nummer ins E.164-Format normalisieren, überprüfen, ob es sich um eine Mobilfunknummer handelt, bevor Sie die Zustellung der SMS in die Warteschlange stellen, und den Validierungsschritt in einen Express-Checkout-Prozess integrieren. Wir bieten ein Vonage Identity Insights SDK für Node.js. Weitere Informationen finden Sie in der Dokumentation zur Vonage Identity Insights-API sowie das Identity Insights SDK für Node.js für die vollständige SDK-Referenz.

Häufig gestellte Fragen

Frage 1: Wie kann ich mich bei der Identity Insights-API authentifizieren?

Die Identity Insights-API nutzt die JWT-Authentifizierung über eine Vonage-Anwendung. Erstellen Sie eine Anwendung im Vonage-Dashboard, laden Sie den privaten Schlüssel herunter und initialisieren Sie das SDK mit Ihrem applicationId und dem Pfad zu Ihrer private.key Datei. Dies unterscheidet sich von dem bei älteren Vonage-APIs verwendeten Schema mit API-Schlüssel und API-Geheimnis.

Frage 2: Warum gibt die Identity Insights-API einen anderen Netzbetreiber zurück als meine bestehende Bibliothek zur Telefonüberprüfung?

Die Number Insight API fragt aktuelle Routing-Daten der Netzbetreiber ab und nicht eine statische Tabelle mit Nummernbereichen. Wenn ein Kunde seine Nummer seit der letzten Aktualisierung Ihrer statischen Bibliothek von einem Festnetzbetreiber zu einem Mobilfunkanbieter portiert hat, gibt die Number Insight API den aktuellen Netzbetreiber zurück, während die statische Bibliothek den ursprünglichen Netzbetreiber angibt. Bei portierten Nummern current_carrier ist immer die maßgebliche Antwort.

Frage 3: Kann ich die Number Insight API nutzen, um internationale Telefonnummern beim Bezahlvorgang zu überprüfen?

Ja. Die Number Insight API deckt Telefonnummern weltweit ab. Übergeben Sie die Nummer im E.164-Format (mit dem + Vorwahl und Ländercode), um optimale Ergebnisse zu erzielen. Das format.number_international Feld in der Antwort liefert Ihnen die normalisierte E.164-Version, unabhängig davon, wie der Kunde die Nummer an der Kasse eingegeben hat.

Frage 4: Verlangsamt der Aufruf der Identity Insights-API beim Bezahlvorgang die Übermittlung des Bezahlformulars?

Ein typischer Aufruf dauert 200 bis 500 ms. Führen Sie ihn serverseitig aus, nachdem der Kunde auf „Absenden“ geklickt hat und bevor Sie Daten in die Datenbank schreiben. Speichern Sie das Ergebnis im Cache der Sitzung, damit der Aufruf nicht zweimal erfolgt, falls der Kunde dieselbe Telefonnummer innerhalb derselben Sitzung erneut aufruft. Fügen Sie ein sanftes Timeout und eine Ausweichlösung hinzu, damit der Bezahlvorgang auch dann abgeschlossen werden kann, wenn der Dienst vorübergehend nicht erreichbar ist.

Schlussfolgerung

Wenn Telefonnummern nicht ordnungsgemäß bereinigt und validiert werden, kann dies für E-Commerce-Teams erhebliche Folgen haben. Die Anzahl der „WISMO“-Supportanrufe (Where Is My Order) kann sprunghaft ansteigen, und es kommt zu vermehrten Rückbuchungen, wenn die beim Bezahlvorgang gespeicherten Telefonnummern fehlerhaft sind oder Festnetznummern als Mobilfunknummern ausgegeben werden.  

Achten Sie bei der Arbeit mit Vonage-APIs darauf, dass Ihre Checkout-Pipeline die Telefonnummer in das E.164-Format normalisiert und den Netzbetreiber anhand des aktuellen Netzbetreibers überprüft, bevor sie an die Vonage Messages API zur SMS-Zustellung weiterleitet. Falls Sie bei risikoreichen Bestellungen auf eine OTP-basierte Verifizierung zurückgreifen müssen, steht Ihnen die Vonage Verify API eine naheliegende Ergänzung derselben Checkout-Pipeline.

Haben Sie eine Frage oder möchten Sie uns mitteilen, was Sie gerade bauen?

Bleiben Sie auf dem Laufenden und halten Sie sich über die neuesten Nachrichten, Tipps und Veranstaltungen für Entwickler auf dem Laufenden.

Teilen Sie:

https://a.storyblok.com/f/270183/400x400/3f6b0c045f/amanda-cavallaro.png
Amanda CavallaroAdvokat für Entwickler