Un acheteur qui remplit automatiquement un formulaire de paiement à partir d'une entrée enregistrée dans son navigateur, ou qui copie une adresse depuis un ancien e-mail, se retrouve parfois avec le code postal d'un lieu associé au nom de ville d'un autre, une erreur facile à commettre et facile à manquer en relisant rapidement un formulaire rempli avant de cliquer sur Envoyer. Une boutique en ligne expédiant des produits physiques a découvert que cette incohérence précise était à l'origine d'un filet discret mais constant de livraisons mal acheminées ou retardées, chacune minime prise isolément, mais représentant ensemble un vrai coût en réexpéditions et en frustration des clients.
La solution a été une vérification croisée exécutée automatiquement au moment du paiement, avant la confirmation de la commande. Le code postal saisi dans le formulaire était envoyé à /v1/postcode, qui détermine à quel lieu ce code correspond réellement. La boutique comparait ce lieu résolu à la ville et à la région que l'acheteur avait également saisies dans le même formulaire et, lorsqu'ils ne concordaient manifestement pas, au lieu de laisser passer la commande et de ne découvrir l'incohérence qu'une fois la livraison partie au mauvais endroit, le parcours de paiement faisait une pause avec un message simple invitant l'acheteur à revérifier le code postal et la ville avant de continuer.
La boutique faisait aussi passer l'adresse complète saisie par /v1/forward, comme seconde couche, car une adresse peut réussir la vérification croisée entre code postal et ville tout en présentant un vrai problème ailleurs, une rue qui n'existe pas sous ce nom ou un numéro hors de la plage plausible pour cette rue. La confiance de la correspondance renvoyée par l'appel de géocodage direct donnait au parcours de paiement un second signal à prendre en compte en plus de la comparaison du code postal, et les correspondances manifestement mauvaises déclenchaient le même rapide message de confirmation.
La boutique a veillé délibérément à limiter la friction ajoutée. La plupart des commandes passaient les deux vérifications instantanément et traversaient le paiement sans aucun changement visible, puisque l'immense majorité des acheteurs saisissent correctement leur propre adresse du premier coup. Seul le plus petit nombre de commandes présentant une réelle incohérence voyait apparaître le message de confirmation, et même dans ce cas, il ne fallait à l'acheteur que quelques secondes pour vérifier et corriger, ou confirmer que l'adresse était bien correcte telle que saisie, car une adresse légitime mais inhabituelle pouvait encore occasionnellement déclencher la vérification sans être réellement fausse.
Ce type de vérification se rentabilise précisément parce que le coût de repérer une incohérence avant l'expédition est bien plus faible que celui d'une commande déjà partie au mauvais endroit : une réexpédition, plus une livraison initiale retardée ou perdue, plus, souvent, un client frustré désormais moins enclin à commander de nouveau. Corriger le problème dans les quelques secondes qui précèdent la commande, au lieu des jours nécessaires pour découvrir et corriger un problème d'expédition après coup, a fait passer ce coût d'important à presque rien.
Chaque commande déclenchait une vérification du code postal et une vérification de l'adresse, une charge qui évoluait directement avec le volume des ventes et restait dans le quota quotidien gratuit pour une boutique de taille moyenne la plus grande partie de l'année, le crédit prépayé couvrant les périodes plus chargées sans nécessiter de planification particulière à l'avance.
La documentation des deux endpoints se trouve sur /docs/postal-code-lookup/ et /docs/forward-geocoding/, et le comportement général de gestion des erreurs pour les deux est décrit sur /docs/errors/.