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.
Detecta el país del visitante para fijar impuestos y moneda por defecto
Pedir a un visitante nuevo que elija su país en una larga lista desplegable antes de mostrarle un precio es un paso extra que un buen valor predeterminado puede eliminar por completo.
Obtener el código de país
Una sola llamada a /v1/ip con la dirección del visitante devuelve un campo country_code en el formato estándar ISO 3166-1 alfa-2, que es el formato que ya usan como clave la mayoría de las tablas de impuestos y monedas.
GET /v1/ip?ip=198.51.100.7{
"status": "ok",
"ip": "198.51.100.7",
"version": 4,
"found": true,
"country": "Germany",
"country_code": "DE",
"region": "Berlin",
"city": "Berlin",
"postcode": "10115",
"lat": 52.5200,
"lon": 13.4050,
"timezone": "Europe/Berlin",
"asn": 6789,
"org": "Example Telecom"
}Del código de país a los impuestos y la moneda
Asocia el country_code con tu propia tabla de tipos impositivos y tu tabla de monedas, igual que harías con un país que el cliente hubiera seleccionado a mano. Trata el país obtenido de la IP como un valor predeterminado, no como una respuesta definitiva, y deja que el visitante lo cambie, ya que un cliente de viaje o uno que usa una VPN no siempre coincidirá con el país de facturación que realmente necesita.
Cuando la consulta no obtiene resultado
Una solicitud para una dirección sin datos de ubicación registrados devuelve found con el valor false en lugar de un error, y conviene tenerlo previsto explícitamente. En ese caso, recurre a un único país y una única moneda predeterminados razonables en lugar de dejar el campo vacío o permitir que un country_code vacío llegue sin que nadie lo note a tu cálculo de impuestos.
En qué se diferencia My Geocode
Los precios de My Geocode se cobran solo en EUR, en todo el mundo, independientemente de desde dónde facture el cliente. Eso es una cuestión aparte de lo que muestras a tus propios visitantes, donde localizar la moneda mostrada según el país detectado es perfectamente razonable aunque tu backend liquide todo en una sola moneda, igual que el nuestro.
Un error que conviene evitar
Bloquear a un visitante en el país detectado sin posibilidad de cambiarlo es un problema mayor que equivocarse de vez en cuando con el valor predeterminado. Un cliente que compra desde un hotel en el extranjero, o detrás de una VPN corporativa que sale por un país distinto de aquel en el que se encuentra realmente, se topará tarde o temprano con un valor predeterminado incorrecto. Muestra siempre el país detectado como un campo editable, no como un valor fijo incrustado en el pedido.
Coste en solicitudes
El patrón sensato es una consulta por cada nueva sesión de visitante, guardada en caché durante esa sesión. Eso supone una solicitud de tu cuota diaria por sesión y no por página vista, lo que mantiene incluso a un sitio con mucho tráfico holgadamente dentro de las 2.500 solicitudes gratuitas al día incluidas con cada clave o disponibles sin clave desde una sola dirección.
Un uso relacionado
La misma respuesta incluye también un campo timezone, así que un flujo de pago que quiera tanto una moneda predeterminada como una visualización razonable de la hora local en las confirmaciones de pedido puede obtener ambas cosas con una sola llamada en lugar de dos consultas separadas.
Acertar con la moneda predeterminada desde la primera página vista evita un cambio de precio brusco más adelante en el pago. La documentación de consulta IPv4 enumera todos los campos que devuelve el endpoint.