Surveillez l'utilisation de votre clé avant d'atteindre une limite
Surveiller vos en-têtes de quota au fil de l'eau vous indique quand une limite approche, bien avant qu'une requête ne soit effectivement refusée.
Détecter le pays d'un visiteur pour les taxes et la devise par défaut
Demander à un nouveau visiteur de choisir son pays dans une longue liste déroulante avant de lui afficher un prix est une étape de plus qu'une bonne valeur par défaut peut supprimer complètement.
Obtenir le code pays
Un seul appel à /v1/ip avec l'adresse du visiteur renvoie un champ country_code au format standard ISO 3166-1 alpha-2, le format que la plupart des tables de taxes et de devises utilisent déjà comme clé.
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"
}Du code pays à la taxe et à la devise
Associez le country_code à votre propre table de taux de taxe et à votre table de devises, de la même manière que vous le feriez pour un pays choisi manuellement par un client. Considérez le pays déduit de l'IP comme une valeur par défaut, et non comme une réponse définitive, et laissez le visiteur le modifier, car un client en voyage ou derrière un VPN ne correspondra pas toujours au pays de facturation dont il a réellement besoin.
Quand la recherche n'aboutit pas
Une requête portant sur une adresse sans données de localisation renvoie found à false plutôt qu'une erreur, un cas qu'il vaut la peine de prévoir explicitement. Dans ce cas, rabattez-vous sur un pays et une devise par défaut uniques et pertinents plutôt que de laisser le champ vide ou de laisser un country_code vide atteindre votre calcul de taxe sans que personne ne s'en aperçoive.
Ce qui diffère chez My Geocode
La tarification de My Geocode elle-même est uniquement en EUR, dans le monde entier, quel que soit le pays de facturation du client. C'est une question distincte de ce que vous affichez à vos propres visiteurs : localiser la devise affichée selon le pays détecté est tout à fait raisonnable, même si votre propre backend règle tout dans une seule devise, comme le nôtre.
Une erreur à éviter
Bloquer un visiteur sur le pays détecté sans possibilité de le modifier pose un problème plus grave que de se tromper de valeur par défaut de temps en temps. Un client qui fait ses achats depuis un hôtel à l'étranger, ou derrière un VPN d'entreprise dont la sortie se trouve dans un autre pays que celui où il se trouve réellement, tombera tôt ou tard sur une mauvaise valeur par défaut. Affichez toujours le pays détecté dans un champ modifiable plutôt que comme une valeur figée intégrée à la commande.
Le coût en requêtes
Une recherche par nouvelle session de visiteur, mise en cache pendant la durée de cette session, est l'approche la plus sensée. Cela représente une requête décomptée de votre quota quotidien par session plutôt que par page vue, ce qui permet même à un site très fréquenté de rester largement dans les 2 500 requêtes gratuites par jour incluses avec chaque clé, ou disponibles sans aucune clé depuis une même adresse.
Un usage connexe
La même réponse comprend aussi un champ timezone : un parcours de paiement qui a besoin à la fois d'une devise par défaut et d'un affichage de l'heure locale pertinent pour les confirmations de commande peut obtenir les deux en un seul appel plutôt qu'en deux recherches distinctes.
Définir la bonne devise par défaut dès la première page vue évite un changement de prix déroutant plus tard lors du paiement. La documentation de la recherche IPv4 liste tous les champs renvoyés par l'endpoint.