Controla el uso de tu clave antes de alcanzar un límite
Vigilar las cabeceras de cuota sobre la marcha te indica cuándo te acercas a un límite, mucho antes de que se rechace realmente una solicitud.
Añade autocompletado de direcciones a un formulario de pago
Los formularios de pago fallan más a menudo en los campos de dirección que en cualquier otro campo, normalmente porque el cliente escribe mal el nombre de una calle u omite el número de piso o puerta. Sugerir direcciones reales mientras escribe corrige la mayor parte de eso antes de que se convierta en una entrega fallida.
La solicitud de autocompletado
El endpoint /v1/autocomplete recibe texto parcial y un límite de cuántas sugerencias devolver. Llámalo mientras el cliente escribe, una vez que haya introducido algunos caracteres.
GET /v1/autocomplete?q=221B Baker&limit=5{
"status": "ok",
"query": "221B Baker",
"suggestions": [
{"text": "221B Baker Street, London, UK", "place_id": "abc123"},
{"text": "221B Baker Avenue, Springfield", "place_id": "abc124"}
]
}De la sugerencia a la dirección completa
Una sugerencia es una etiqueta corta y un place_id, no un registro de dirección completo. Cuando el cliente elija una, resuélvela a una dirección completa con componentes y coordenadas pasando el texto de la sugerencia a /v1/forward. Esa segunda llamada es la que rellena los campos de calle, ciudad, región y código postal de tu formulario.
GET /v1/forward?q=221B Baker Street, London, UK&limit=1Esa segunda solicitud es donde aparece realmente el objeto components, ya que /v1/autocomplete solo devuelve una etiqueta de texto y un place_id, nunca un desglose de calle, ciudad y código postal. Saltarse este paso e intentar analizar tú mismo el texto de la sugerencia es más frágil de lo que parece, porque el formato varía según el país.
Mantener razonable el número de solicitudes
Lanzar una solicitud con cada pulsación de tecla se acumula rápido en una página de pago con mucho tráfico. Aplica debounce al campo para que la solicitud solo salga cuando el cliente deje de escribir un momento, y omite las solicitudes para textos de menos de tres o cuatro caracteres, donde las sugerencias no son útiles de todos modos. Cada llamada de autocompletado y cada llamada posterior de geocodificación directa cuentan como una solicitud dentro de tu cuota diaria, así que un campo con debounce en una tienda con mucho tráfico puede seguir funcionando muy por debajo de las 2.500 solicitudes gratuitas al día incluidas con cada clave.
Gestionar la falta de coincidencias
Un array de sugerencias vacío es una respuesta normal, no un error. Deja que el cliente siga escribiendo y recurre a un campo de dirección de texto simple si no aparece nada útil tras unos cuantos caracteres, en lugar de bloquear el envío del formulario hasta que se elija una sugerencia.
Un error que conviene evitar
Tratar una sugerencia seleccionada como una dirección terminada y validada es un atajo habitual que da problemas más adelante. Un cliente puede seleccionar una sugerencia y después seguir editando el campo, cambiando el número de la casa o añadiendo un número de apartamento que la sugerencia original nunca tuvo. Resuelve siempre el texto final del campo con /v1/forward en el momento del envío, no solo en el momento en que se hizo clic en una sugerencia, para que la dirección que guardes refleje lo que realmente quedó en el campo.
Una comprobación relacionada que vale la pena añadir
Si tu formulario de pago también recoge el código postal por separado, una llamada rápida a /v1/postcode una vez resuelta la dirección es una forma barata de detectar un código postal que no coincide con el resto de la dirección, antes de que ambos se envíen juntos y provoquen más adelante un error en el envío.
El autocompletado no sustituye a la validación, solo reduce las probabilidades de que una dirección incorrecta llegue a tu sistema de pedidos. Consulta la documentación de autocompletado de direcciones para ver la lista completa de parámetros antes de integrarlo en tu proceso de pago.