Monitore o uso da sua chave antes de atingir um limite
Acompanhar seus cabeçalhos de cota ao longo do caminho mostra quando um limite está se aproximando, bem antes de uma requisição ser realmente rejeitada.
Detecte o país do visitante para definir imposto e moeda padrão
Pedir a um novo visitante que escolha o próprio país em uma longa lista suspensa antes de mostrar um preço é uma etapa extra que um bom valor padrão pode eliminar por completo.
Obtendo o código do país
Uma única chamada para /v1/ip com o endereço do visitante retorna um campo country_code no formato padrão ISO 3166-1 alfa-2, que é o formato que a maioria das tabelas de impostos e moedas já usa como chave.
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"
}Do código do país ao imposto e à moeda
Associe o country_code à sua própria tabela de alíquotas e à sua tabela de moedas, da mesma forma que faria com um país escolhido manualmente pelo cliente. Trate o país obtido pelo IP como um valor padrão, e não como resposta final, e deixe o visitante alterá-lo, já que um cliente em viagem ou atrás de uma VPN nem sempre vai corresponder ao país de cobrança de que ele realmente precisa.
Quando a consulta não encontra resultado
Uma requisição para um endereço sem dados de localização cadastrados retorna found como false, e não um erro, e vale a pena planejar isso explicitamente. Nesse caso, recorra a um único país e a uma única moeda padrão sensatos, em vez de deixar o campo em branco ou permitir que um country_code vazio chegue ao seu cálculo de impostos sem ser notado.
Onde a própria My Geocode é diferente
Os preços da própria My Geocode são apenas em EUR, no mundo todo, independentemente de onde o cliente é cobrado. Isso é uma questão separada do que você mostra aos seus próprios visitantes, para quem localizar a moeda exibida de acordo com o país detectado é totalmente razoável, mesmo que o seu backend liquide tudo em uma única moeda, como o nosso faz.
Um erro que vale a pena evitar
Prender um visitante ao país detectado, sem nenhuma forma de alterá-lo, é um problema maior do que errar o valor padrão de vez em quando. Um cliente comprando de um hotel no exterior, ou atrás de uma VPN corporativa com saída em um país diferente daquele em que ele realmente está, vai encontrar um padrão errado mais cedo ou mais tarde. Sempre mostre o país detectado como um campo editável, e não como um valor fixo embutido no pedido.
Custo das requisições
Uma consulta por nova sessão de visitante, armazenada em cache durante essa sessão, é o padrão sensato. Isso significa uma requisição da sua cota diária por sessão, e não por visualização de página, o que mantém até um site movimentado bem dentro das 2.500 requisições gratuitas por dia incluídas em cada chave ou disponíveis sem nenhuma chave a partir de um único endereço.
Um uso relacionado
A mesma resposta também inclui um campo timezone, então um fluxo de checkout que queira tanto uma moeda padrão quanto uma exibição sensata do horário local nas confirmações de pedido pode obter os dois em uma única chamada, em vez de duas consultas separadas.
Acertar a moeda padrão na primeira visualização de página evita uma troca de preço desconcertante mais adiante no checkout. A documentação da consulta de IPv4 lista todos os campos que o endpoint retorna.