Un comprador que rellena el formulario de pago con el autocompletado de una entrada guardada en el navegador, o que copia una dirección de un correo electrónico antiguo, a veces acaba con el código postal de una ubicación junto al nombre de ciudad de otra, un error fácil de cometer y fácil de pasar por alto al repasar rápidamente un formulario rellenado antes de pulsar enviar. Una tienda online que enviaba productos físicos descubrió que esta discrepancia exacta estaba detrás de un goteo constante y discreto de entregas mal dirigidas o retrasadas, cada una pequeña por sí sola y, en conjunto, un coste real en reenvíos y en frustración de los clientes.
La solución fue una verificación cruzada ejecutada automáticamente en el pago, antes de confirmar el pedido. El código postal introducido en el formulario iba a /v1/postcode, que resuelve a qué ubicación corresponde realmente ese código. La tienda comparaba la ubicación resuelta con la ciudad y la región que el comprador también había introducido en el mismo formulario y, cuando claramente no concordaban, en lugar de dejar pasar el pedido y descubrir la discrepancia solo cuando una entrega llegaba al lugar equivocado, el flujo de pago se detenía con un aviso sencillo que pedía al comprador revisar el código postal y la ciudad antes de continuar.
La tienda también pasaba la dirección completa introducida por /v1/forward como segunda capa, ya que una dirección puede superar la verificación cruzada de código postal y ciudad y aun así tener un problema real en otra parte, una calle que no existe con ese nombre o un número fuera del rango plausible para esa calle, y la confianza de la coincidencia devuelta por la llamada de geocodificación directa daba al flujo de pago una segunda señal que sopesar junto con la comparación del código postal, marcando las coincidencias claramente pobres para el mismo aviso rápido de confirmación.
La tienda pensó bien cuánta fricción añadía esto. La mayoría de los pedidos superaban ambas comprobaciones al instante y avanzaban por el pago sin ningún cambio visible, ya que la inmensa mayoría de los compradores introducen su propia dirección correctamente a la primera. Solo el número menor de pedidos con una discrepancia real veía el aviso de confirmación, e incluso entonces al comprador le bastaban unos segundos para revisarla y corregirla, o para confirmar que la dirección era de hecho correcta tal como se había introducido, ya que alguna dirección legítimamente inusual podía activar la comprobación sin ser realmente errónea.
Este tipo de comprobación se amortiza precisamente porque el coste de detectar una discrepancia antes del envío es mucho menor que el de un pedido que ya se ha enviado al lugar equivocado: un reenvío, más una entrega original retrasada o perdida, más, a menudo, un cliente frustrado que ahora tiene menos probabilidades de volver a comprar. Corregirlo en los pocos segundos antes de hacer el pedido, en lugar de en los días que se tarda en descubrir y corregir un problema de envío a posteriori, llevó ese coste de significativo a casi nada.
Cada pedido activaba una comprobación de código postal y una comprobación de dirección, una carga de trabajo que crecía directamente con el volumen de ventas y se mantenía dentro de la cuota diaria gratuita para una tienda de tamaño medio la mayor parte del año, con crédito prepago para cubrir los periodos de más actividad sin necesidad de ninguna planificación especial por adelantado.
La documentación de ambos endpoints está en /docs/postal-code-lookup/ y /docs/forward-geocoding/, y el comportamiento general de gestión de errores de ambos se explica en /docs/errors/.