My Geocode

ガイド

税金と通貨のデフォルト設定のために訪問者の国を検出する

· 3分で読めます · My Geocode · #IP検索#国の検出#税金#通貨

価格を表示する前に、新しい訪問者に長いドロップダウンから国を選ばせるのは余分な手順であり、適切な既定値があればそれを完全になくせます。

国コードを取得する

訪問者のアドレスで/v1/ipを1回呼び出すと、標準のISO 3166-1 alpha-2形式のcountry_codeフィールドが返されます。これは、ほとんどの税率表や通貨表がすでにキーとして使っている形式です。

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"
}

国コードから税金と通貨へ

顧客が手動で選択した国を対応づけるのと同じように、country_codeを自社の税率表と通貨表に対応づけます。IPから割り出した国は最終的な答えではなく既定値として扱い、訪問者が変更できるようにしてください。旅行中の顧客やVPNを使っている顧客は、実際に必要な請求先の国と必ずしも一致しないからです。

検索で解決できない場合

位置データが登録されていないアドレスに対するリクエストは、エラーではなくfoundがfalseに設定された結果を返します。これは明示的に想定しておく価値があります。その場合は、フィールドを空欄のままにしたり、空のcountry_codeが気づかれないまま税金の計算に渡ったりしないよう、適切な既定の国と通貨を1つ決めてそれにフォールバックしてください。

My Geocode自体の違い

My Geocode自体の料金は、顧客がどこから請求を受けるかにかかわらず、世界中でEURのみです。これは、自社の訪問者に何を表示するかとは別の問題です。当社と同じように自社のバックエンドですべてを1つの通貨で決済していても、検出した国に応じて表示通貨をローカライズするのはまったく妥当なことです。

避けるべき間違い

検出した国に訪問者を固定して変更できないようにすることは、ときどき既定値を誤ることよりも大きな問題です。海外のホテルから買い物をする顧客や、実際にいる国とは別の国に出口がある企業のVPNを使っている顧客は、遅かれ早かれ誤った既定値に遭遇します。検出した国は、注文に組み込まれた固定の値ではなく、必ず編集可能なフィールドとして表示してください。

リクエストのコスト

新しい訪問者のセッションごとに1回検索し、そのセッションの間キャッシュするのが適切なパターンです。これならページビューごとではなくセッションごとに1日の割り当てから1リクエストを使うだけなので、アクセスの多いサイトでも、すべてのキーに含まれる、あるいはキーなしでも1つのアドレスから利用できる1日あたり2,500回の無料リクエストに十分収まります。

同じレスポンスにはtimezoneフィールドも含まれているため、通貨の既定値と、注文確認での適切な現地時刻の表示の両方を必要とするチェックアウトフローでは、2回の別々の検索ではなく1回の呼び出しで両方を取得できます。

最初のページビューで通貨の既定値を正しく設定しておけば、チェックアウトの途中で価格が急に切り替わる不快な体験を避けられます。IPv4検索のドキュメントには、エンドポイントが返すすべてのフィールドが記載されています。

ガイドのその他の記事

· 4分で読めます

住所と郵便番号を照合する

住所と郵便番号をそれぞれ個別に解決して実際に示す内容を比較することで、注文の発送前に番地と郵便番号の不一致を見つけます。