Ce document décrit un processus permettant de créer un système de vérification des adresses pour gérer diverses réponses de l'API Address Validation. Il explique comment interpréter la réponse de l'API afin de déterminer quand et comment demander plus d'informations à vos clients.
En général, la réponse de l'API détermine les méthodes suivantes que votre système doit utiliser pour gérer une adresse:
-
Corriger : l'adresse peut contenir des problèmes importants.
Demandez à votre client de vous fournir plus d'informations. -
Ajouter des sous-locaux : il se peut qu'un sous-local ne figure pas dans l'adresse.
Demandez à votre client d'ajouter un numéro d'unité. -
Confirmer : l'adresse peut contenir des problèmes mineurs.
Demandez au client de confirmer que l'adresse est correcte. -
Accepter : l'adresse peut ne pas présenter de problème.
Envisagez d'utiliser l'adresse sans autre invite, à vos risques et périls.
Objectif principal
Ce document vous aide à modifier votre système pour mieux analyser la réponse de l'API et déterminer les prochaines actions à effectuer avec les adresses fournies. Le pseudocode suivant illustre un flux possible.
if (verdict.possibleNextAction == FIX)
Prompt the user to fix the address.
else if (verdict.possibleNextAction == CONFIRM_ADD_SUBPREMISES)
Prompt the user to add a unit number.
else if (verdict.possibleNextAction == CONFIRM)
Confirm with the user that the address is correct.
else
Continue with the address returned by the API.
La logique exacte dépend de votre situation. Pour en savoir plus, consultez la section Personnaliser votre logique de validation.
Workflows possibles
Le tableau ci-dessous récapitule les workflows possibles que vous pouvez implémenter pour inviter votre client en fonction de la réponse de l'API.
| Comportement de votre système | ||
|---|---|---|
| Corriger l'adresse |
La réponse de
|
|
| Ajouter des sous-établissements |
La réponse de
|
|
| Confirmer l'adresse |
La réponse de
|
|
| Accepter l'adresse |
La réponse de
|
|
Personnaliser votre logique de validation
Bien que vous puissiez utiliser les résultats du champ verdict.possibleNextAction pour déterminer comment votre système traite la réponse de l'API, vous pouvez également envisager de créer une logique personnalisée, par exemple pour gérer les besoins spécifiques à votre entreprise.
L'objectif de cette section est d'illustrer comment développer votre propre logique personnalisée pour interpréter la réponse de l'API afin de déterminer si vous souhaitez inviter votre client et comment le faire. Cette section présente les niveaux de risque et les signaux de réponse d'API supplémentaires à prendre en compte pour votre personnalisation.
Toutefois, même si vous vous appuyez uniquement sur verdict.possibleNextAction pour décider de la marche à suivre, les signaux supplémentaires décrits ci-dessous peuvent toujours vous aider à comprendre les détails des problèmes potentiels liés à l'adresse.
Tolérance au risque
Lorsque vous concevez la façon dont votre système répond aux signaux de l'API Address Validation, les recommandations suivantes peuvent vous aider à créer un modèle de réponse plus efficace. Toutefois, il ne s'agit que de recommandations. N'oubliez pas que votre implémentation doit correspondre à votre modèle commercial.
| Conseils | Détails | |
|---|---|---|
| Niveau de risque |
Tenez compte du niveau de tolérance dans votre situation pour trouver le juste équilibre entre demander des corrections et accepter l'adresse telle qu'elle a été saisie. |
L'API Address Validation renvoie divers signaux que vous pouvez intégrer à votre niveau de risque pour optimiser votre processus de validation. Par exemple, si le numéro de rue d'une adresse n'est pas confirmé, vous pouvez quand même l'accepter. En revanche, si votre activité nécessite une adresse plus précise, vous pouvez inviter l'utilisateur à la fournir. Pour un exemple pouvant relever de l'une ou l'autre catégorie, consultez Numéro de rue non confirmé en dehors des États-Unis dans Accepter l'adresse : exemples. |
| Accepter les adresses |
Il est recommandé d'autoriser votre système à accepter la saisie d'origine si le client ne répond pas aux requêtes. |
Dans ce cas, le client a peut-être saisi une adresse qui ne figure pas dans le système, par exemple pour une nouvelle construction. |
Exemple de parcours de paiement axé sur la réduction des risques
Si vous souhaitez réduire le risque d'échec des envois, vous pouvez personnaliser votre logique pour inviter vos clients plus souvent. Par exemple, au lieu d'utiliser la logique décrite dans la section Objectif de la clé, vous pouvez utiliser la logique suivante.
if (verdict.possibleNextAction == FIX or verdict.validationGranularity
== OTHER or verdict.validationGranularity == ROUTE)
Prompt customer to fix their address.
else if (verdict.possibleNextAction == CONFIRM_ADD_SUBPREMISES)
Prompt customer to add a unit number.
else if (verdict.possibleNextAction == CONFIRM or verdict.validationGranularity
== PREMISE_PROXIMITY or verdict.hasSpellCorrectedComponents or
verdict.hasReplacedComponents or verdict.hasInferredComponents)
Prompt customer to confirm their address.
else
Proceed with the returned address.
Exemple de parcours de paiement fluide
Si vous souhaitez réduire les frictions dans votre parcours de paiement, vous pouvez personnaliser votre logique pour demander moins souvent aux clients de fournir des informations. Par exemple, au lieu d'utiliser la logique décrite dans la section Objectif de la clé, vous pouvez utiliser la logique suivante.
if (verdict.possibleNextAction == FIX)
Prompt customer to fix their address.
else if (verdict.hasReplacedComponents)
Prompt customer to confirm their address.
else
Proceed with the returned address.
Signaux FIX
Corrigez une adresse lorsque les résultats indiquent clairement qu'elle ne peut pas être livrée. Votre système peut ensuite inviter le client à fournir les informations nécessaires, après quoi vous réémettez votre workflow pour obtenir une adresse de livraison.
En plus de verdict.possibleNextAction, vous pouvez utiliser les champs suivants de la réponse de l'API Address Validation pour déterminer si une adresse présente des problèmes majeurs et quels sont ces problèmes.
| Niveau de précision de la validation | Lorsque l'énumération de la granularité de validation d'une adresse est OTHER, il est probable que l'adresse soit incorrecte.
|
|---|---|
| Composants manquants | Lorsque le address.missingComponentTypes n'est pas vide, il est probable que des informations clés manquent à l'adresse.
|
| Composants suspects | Lorsque l'énumération du niveau de confirmation d'un composant est UNCONFIRMED_AND_SUSPICIOUS, il est probable que le composant soit incorrect.
|
| Composants non résolus | Un unresolvedToken est une partie de la saisie qui n'est pas reconnue comme faisant partie d'une adresse valide. |
| Confirmation de la livraison par envoi postal des États-Unis | Lorsque uspsData.dpvConfirmation est défini sur N ou vide, il est possible qu'un problème soit lié à l'adresse. Ce champ n'est disponible que pour les adresses situées aux États-Unis. Pour en savoir plus sur uspsData.dpvConfirmation, consultez Gérer les adresses aux États-Unis.
|
Corriger les exemples d'adresses
Signaux CONFIRM_ADD_SUBPREMISES (adresses aux États-Unis uniquement)
Vous invitez votre client à vérifier l'adresse et à envisager d'ajouter un numéro d'unité lorsque la réponse de l'API Address Validation indique qu'un sous-locataire peut être manquant. Dans ce cas, l'adresse du bâtiment est probablement valide, mais vous souhaitez être plus sûr que l'adresse obtenue est bien celle souhaitée par le client.
Les champs suivants de la réponse de l'API de validation des adresses peuvent être utilisés en plus de verdict.possibleNextAction pour déterminer si une adresse manque probablement d'une sous-adresse.
Missing subpremise component
|
Lorsque le champ address.missingComponentTypes contient la valeur subpremise, cela signifie qu'un numéro d'appartement est manquant dans l'adresse.
|
|---|---|
| Confirmation de la livraison par envoi postal des États-Unis | Lorsque uspsData.dpvConfirmation est S, cela signifie que le numéro principal de l'adresse a été mis en correspondance avec une adresse dans la base de données USPS. Toutefois, l'adresse devait également contenir un numéro secondaire. Ce champ n'est disponible que pour les adresses situées aux États-Unis. Pour en savoir plus sur uspsData.dpvConfirmation, consultez la section Gérer les adresses aux États-Unis.
|
Ajouter des exemples d'adresses de sous-locaux
Signaux CONFIRM
Vous confirmez une adresse lorsque l'évaluation indique que l'API Address Validation a inféré ou modifié des composants d'adresse afin de générer une adresse validée. Dans ce cas, vous disposez d'une adresse de livraison, mais vous préférez avoir plus de certitude que l'adresse obtenue est celle souhaitée par le client.
Les champs suivants de la réponse de l'API Address Validation peuvent être utilisés en plus de verdict.possibleNextAction pour déterminer si une adresse présente des problèmes mineurs et quels sont ces problèmes.
| Niveau de précision de la validation | Lorsque validationGranularity pour une adresse est ROUTE ou PREMISE_PROXIMITY, l'adresse peut être incorrecte.
|
|---|---|
| Données inférées | Lorsque le champ hasInferredComponents est true, vous savez que l'API a renseigné les informations qu'elle a recueillies auprès d'autres composants d'adresse.
|
| Données remplacées | Lorsque le champ hasReplacedComponents est true, l'API a remplacé les données saisies par celles qu'elle a jugées nécessaires pour rendre l'adresse valide.
|
| Corrections orthographiques | Lorsque le champ hasSpellCorrectedComponents est true, l'API corrige l'orthographe de certains composants mal orthographiés.
|
Confirmer des exemples d'adresses
Signaux ACCEPTER
Vous pouvez accepter une adresse lorsque la réponse de l'API Address Validation API indique avec un degré de confiance élevé que l'adresse peut être livrée et utilisée sans autre interaction avec le client dans le processus en aval.
Les champs suivants de la réponse de l'API de validation des adresses peuvent être utilisés en plus de verdict.possibleNextAction pour déterminer si une adresse est de qualité acceptable.
| Niveau de précision de la validation | Une valeur validationGranularity de PREMISE est souvent acceptable, bien qu'une valeur de ROUTE puisse toujours indiquer une adresse de livraison.
|
|---|---|
| Aucune donnée inférée | Lorsque le champ hasInferredComponents est false, vous savez qu'aucun composant de la sortie n'a été inféré.
|
| Aucune donnée remplacée | Lorsque le champ hasReplacedComponents est false, vous savez qu'aucune donnée d'entrée n'a été remplacée.
|
| Aucune correction orthographique | Lorsque le champ hasSpellCorrectedComponents est false, vous savez qu'aucune correction orthographique n'a été apportée.
|
| Confirmation de la livraison par envoi postal des États-Unis | Lorsque uspsData.dpvConfirmation est Y, cela signifie que l'adresse a été mise en correspondance avec une adresse de la base de données USPS. Ce champ n'est disponible que pour les adresses situées aux États-Unis. Pour en savoir plus sur uspsData.dpvConfirmation, consultez Gérer les adresses aux États-Unis.
|