Nettoyage et validation des numéros de téléphone pour le commerce électronique

Introduction

La qualité et la validité des numéros de téléphone constituent des problèmes discrets mais persistants dans le commerce électronique. Les numéros recueillis lors du paiement sont souvent incorrects, présentés dans des formats incohérents ou appartiennent à des lignes qui ne peuvent pas recevoir de SMS, et on ne s'en rend généralement compte que lorsqu'une notification de livraison est renvoyée.

Cet article explique comment nettoyer les données relatives aux numéros de téléphone à l'aide de la fonctionnalité « Format Insight » (en normalisant chaque numéro au format E.164), puis de les valider à l’aide de l’ current_carrier « insight » (vérifier que le numéro correspond à un mobile capable de recevoir normalement un SMS). L’ API Vonage Identity Insights renvoie à la fois un numéro nettoyé et la confirmation qu’il est compatible avec les SMS en un seul appel API. L’utilisation conjointe des informations de format et d’opérateur fournies par l’API Identity Insights vous permet de nettoyer chaque numéro au format E.164 avant qu’il n’atteigne votre base de données et de confirmer qu’il s’agit bien d’un numéro de mobile avant de l’utiliser pour l’envoi de communications.

Échecs de désinfection et de validation

Un scénario courant côté serveur se présente lorsqu'un client, en remplissant le formulaire de paiement, saisit son numéro de téléphone dans le format qui lui semble le plus naturel, puis valide pour passer la commande. Le champ de saisie HTML5 de type « téléphone » accepte cette saisie. L'expression régulière côté serveur vérifie qu'il comporte bien dix chiffres. La commande est enregistrée dans la base de données, un e-mail de confirmation est envoyé et un SMS de livraison est transmis.

Il ne se passe alors rien : aucune erreur n'est enregistrée, aucune nouvelle tentative n'est lancée, aucune alerte n'est déclenchée. Quelques jours plus tard, le client ouvre un ticket d'assistance pour demander où en est sa commande. Une demande de type « WISMO » (Where Is My Order) qui coûte à votre équipe du temps et de l'argent, alors qu'elle aurait pu être entièrement évitée. Cette défaillance a deux causes cachées :

• Erreur de validation : le numéro a été enregistré au format national (4155551234) au lieu du format E.164 (+14155551234).

• Échec de la validation : même si le format était correct, le numéro correspond à une ligne fixe ou à un numéro qui était auparavant un numéro de mobile et qui a été transféré vers un opérateur de téléphonie fixe le mois dernier. Votre expression régulière détecte dix chiffres et valide le numéro. Une table de correspondance statique identifie l'attribution d'origine de l'opérateur et indique « mobile ». Le SMS est mis en file d'attente, puis rejeté, sans jamais parvenir au téléphone du client.

Validation du numéro de téléphone

La validation d'un numéro de téléphone consiste à vérifier qu'une suite de chiffres correspond bien à un numéro de téléphone réel et joignable, sur lequel un SMS ou un appel vocal pourra être reçu. En savoir plus sur la validité des numéros de téléphone.

L'expression régulière détecte les longueurs de chiffres incorrectes, les caractères non numériques et les indicatifs régionaux manquants. Elle ne permet toutefois pas de distinguer les numéros de mobile des numéros fixes, ni les numéros virtuels ou VoIP.

Résultats de l'API « Recherche d'opérateur et informations d'identité »

Une recherche d'opérateur est une requête adressée au graphe de routage en temps réel du réseau mobile : quel opérateur détient actuellement ce numéro, et de quel type de ligne s'agit-il ? Vous pouvez consulter la la documentation de l'API Identity Insights pour en savoir plus sur les champs clés renvoyés par les appels à l’API Identity Insights. Une réponse réussie se présente comme suit :

{

  "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" }

    }

  }

}

Remarque : contrairement aux informations issues du réseau, telles que le « SIM Swap » ou la « vérification de localisation », le format et current_carrier informations ne nécessitent pas l’approbation du registre du réseau. Elles sont disponibles dans le monde entier sans intégration supplémentaire auprès des opérateurs.

Premiers pas avec l'API Identity Insights

Le moyen le plus rapide de voir cela en action est d'utiliser le tutoriel « Premiers pas avec Identity Insights » dans le tableau de bord Vonage. Saisissez n'importe quel numéro de téléphone, sélectionnez format et current_carrier, puis observez la réponse en temps réel. Un mode Démo avec des Numbers prédéfinis est également disponible si vous souhaitez explorer la fonctionnalité sans utiliser de numéro réel et voir la réponse en temps réel. Un mode Démo avec des Numbers prédéfinis est également disponible si vous souhaitez explorer la fonctionnalité sans utiliser de numéro réel.

Getting Started with Identity Insights

Configurer Identity Insights dans un projet Node.js

Vous pourriez mettre en pratique la théorie apprise aujourd’hui et normaliser le numéro au format E.164, vérifier qu’il s’agit bien d’un numéro de mobile avant de mettre en file d’attente l’envoi du SMS et d’intégrer l’étape de validation dans un parcours de paiement express. Nous proposons un SDK Vonage Identity Insights pour Node.js. Consultez la documentation de l'API Vonage Identity Insights et le SDK Identity Insights pour Node.js pour consulter la référence complète du SDK.

Questions fréquemment posées

Q1. Comment puis-je m'authentifier auprès de l'API Identity Insights ?

L'API Identity Insights utilise l'authentification JWT via une application Vonage. Créez une application dans le tableau de bord Vonage, téléchargez la clé privée, puis initialisez le SDK avec votre applicationId et le chemin d’accès à votre private.key fichier. Ce modèle diffère de celui basé sur une clé API et un secret utilisé par les anciennes API Vonage.

Q2. Pourquoi l'API Identity Insights renvoie-t-elle un opérateur différent de celui indiqué par ma bibliothèque de validation de numéro de téléphone actuelle ?

L'API Number Insight interroge les données de routage en temps réel des opérateurs, et non un tableau statique d'attribution de plages de numéros. Si un client a transféré son numéro d'un opérateur de téléphonie fixe vers un opérateur mobile depuis la dernière mise à jour de votre bibliothèque statique, l'API Number Insight renvoie l'opérateur actuel, tandis que la bibliothèque statique renvoie l'opérateur d'origine. Pour les numéros transférés, current_carrier c'est toujours la réponse qui fait autorité.

Q3. Puis-je utiliser l'API Number Insight pour valider des numéros de téléphone internationaux lors du paiement ?

Oui. La Number Insight API prend en charge les numéros du monde entier. Pour obtenir les meilleurs résultats, transmettez le numéro au format E.164 (avec le + préfixe et l'indicatif du pays) pour obtenir les meilleurs résultats. Le format.number_international champ de la réponse vous fournit la version E.164 normalisée, quelle que soit la manière dont le client a saisi le numéro lors du paiement.

Q4. L'appel de l'API Identity Insights lors du paiement ralentit-il l'envoi du formulaire de paiement ?

Un appel type dure entre 200 et 500 ms. Exécutez-le côté serveur après que le client a cliqué sur « Valider » et avant d'effectuer l'écriture dans la base de données. Mettez le résultat en cache dans la session afin de ne pas effectuer deux appels si le client consulte à nouveau le même numéro de téléphone au cours de la même session. Prévoyez un délai d'expiration progressif et une solution de secours permettant de finaliser le paiement même si le service est temporairement inaccessible.

Conclusion

Les équipes chargées du commerce électronique peuvent être confrontées à de nombreux problèmes si les numéros de téléphone ne sont pas correctement nettoyés et validés. Les appels au service client liés aux demandes « Où en est ma commande ? » (WISMO) peuvent exploser, et les rétrofacturations augmenter lorsque les numéros de téléphone enregistrés lors du paiement sont incorrects ou que des numéros fixes sont présentés comme des numéros de portable.  

Lorsque vous utilisez les API Vonage, assurez-vous que votre pipeline de paiement normalise le numéro de téléphone au format E.164 et valide l'opérateur en utilisant l'opérateur actuel avant de le transmettre à l' Messages API en vue de l'envoi d'un SMS. Si vous devez recourir à une vérification par mot de passe à usage unique (OTP) pour les commandes à haut risque, l’ Verify API s'intègre naturellement à ce même processus de paiement.