開発者用チェックリスト

このチェックリストを使用して、クレジットカードのエラーを減少させ、クレジットカードのルールとポリシーのすべてのコンプライアンスを遵守してください。

クレジットカード エラーの防止と解決 :

  1. 次のガイドラインにしたがってデフォルト通貨を設定する。
  2. 正しいクレジットカード タイプ コードを送信する。たとえば、Mastercard の場合は CA を送信します。
  3. カード番号、セキュリティ コードおよび有効期限のサフィックス、形式、および文字長が正しいかどうかを検証する。
  4. 支払いタイプのリクエストを使用して、有効なカード タイプを取得する。
  5. 旅程 ID を使用して、クレジットカードが拒否されて失敗した予約を再送信し、失敗した旅程を正常に処理された旅程に変換する。
  6. ローカライズされた presentationMessage フィールドを使用して、お客様にクレジットカードの処理が失敗した理由を知らせる。詳細については、クレジットカードのエラーを参照してください。

契約上の義務

アフィリエイト契約により、すべてのパートナーは、PCI、クレジットカード会社、および電子セキュリティのすべてのポリシーに従う義務があり、それぞれの分野において課せられた法的義務を負うものとします。

ID の盗難と不正は、小売りサプライチェーンに含まれるすべての当事者 (支払いクレジットカード会社、銀行、小売業者、および個人情報や銀行口座が危険にさらされるお客様個人) に影響を及ぼします。年を追うごとに問題は増大しています。特に、ワイヤレス テクノロジを利用する小売業者がますます増えているため、新たな課題に対処することが必要になっています。技術が進歩して消費者と業者の双方にとっての利便性が向上するなかで、支払いクレジットカードのセキュリティ基準の重要性が増しています。

開発者には担当する Web サイトのユーザーのプライバシーと消費者データを保護する責任があります。この重大な責任を果たすために、クレジットカード会社は共同で Payment Card Industry (PCI) Council を設立しました。これは、取り扱いに慎重さが求められる消費者データを扱う当事者すべてに適用する、共通の認可されたセキュリティ ガイドラインを策定するためです。これらのガイドラインは、小売業者とそのお客様が個人情報盗用の犠牲にならないようにすること、およびクレジットカード データを確実に保護し適切に処理することを目的としています。

PCI ベスト プラクティスの概略 :

  • セキュアなネットワークを構築し維持する :これには、ファイアウォールの導入とセキュアなパスワード ポリシーが含まれます。
  • カード保有者の個人データを保護する :公共ネットワークでのデータ暗号化の実装も含まれます。
  • ネットワーク脆弱性管理プログラムを維持する :ウィルス対策ソフトおよび他のセキュリティ ソフトウェア アプリケーションの定期的な更新も含まれます。
  • 強力なアクセス制御手段を講じる :ネットワークにアクセスする各従業員に固有の ID を割り当てる必要があります。
  • 定期的にネットワークを監視しテストする :カード保有者データへのすべてのアクセスを監視および追跡することを意味します。
  • 情報セキュリティ ポリシーを堅持する :上記すべてを遵守し、IT の標準的な運用手順の一部としてポリシーを文書化します。
  • PCI 証明書のないクレジットカード情報は保存しない。
  • PCI Security Standards および PCI 認定を受ける方法については、http://www.pcisecuritystandards.org/ を参照してください。

EAN は PCI に準拠し認定されていますか?

もちろんです。EAN のすべての管理システムは、構築、実装、監視、点検、保守、および改良に関するコンプライアンスおよび認定基準を、どれも満たしているだけでなく、それより高い基準を維持しています。また、厳格な年次監査を実施して、毎年認定を更新しています。

すべての予約リクエストに必要なクレジットカードのセキュリティ コード

API 予約リクエストを行うときに、クレジットカードのセキュリティコード (CSV、CVV2、CVN、CID、CVC2 と呼ばれることもある) は creditCardIdentifier と表記されます。図に示されているように、このコードはクレジットカードの裏面に記載されています。

  • 予約リクエストで CSV 値が送信されないと、クレジットカードの処理で、購入は拒否され、事前支払いの予約は失敗します。

PCI コンプライアンスで要求されているように、必要な取引および支払いプロセスの完了後は CSV 値を保存しないでください。

お客様のクレジットカード情報の一部非表示に関する必須要件

領収書、Web ページ、または電子メールでのクレジットカード番号の表示

  1. カード番号は 末尾 4 桁のみ を表示するか、または 全く表示しない
  2. カードの
  3. 有効期限は表示しない
  4. PCI Security Standards ( http://www.pcisecuritystandards.org/) に反する方法でクレジットカード番号、有効期限、氏名または住所を保存しない
  5. PCI Security Standards に関し何らかの疑念がある場合は、クレジットカード データを何も保存しない

クレジットカード情報に関する PCI の必須規定に違反したパートナーには、クレジットカード情報の誤用の被害者側から直接罰金または違約金が科されます。 すべてのパートナー契約において、すべての PCI 規則に完全に準拠することが要求されています。

パートナー Web サイトでのコンテンツの誤用に関して、EAN は何の責任も負いません。パートナー契約に記載されているように、各パートナーは EAN、第三者、および法律が制定するすべての規則および要件に従う責任を負います。

予約、確認、旅程、キャンセルのすべてのページで SSL が必須

電子メール アドレス、氏名、支払い情報、住所、電話番号などの提供に任意の形式の認証を実施して、支払い情報や個人を特定可能なデータの送受信にセキュリティ保護を敷いてください。

このルールには、例外なく従ってください。

  • 予約フォーム、確認、旅程、キャンセルの各ページは、信頼性の高い認証によって保護しなければなりません。
  • ユーザーが入力したキャッシュ カードやクレジットカードの番号は、前記のページのいずれにも再表示してはなりません。
  • キャッシュ カードやクレジットカードの番号は、パートナーのアプリケーション内に一切保存しないでください。これは、キャッシュカードのセキュリティ ポリシーに違反する行為です。
  • 開発者のサーバーとエクスペディアのサーバー間のデータ転送のホストはエクスペディアであり、認証を実施する責任はエクスペディアにあります。開発者のサーバーとエクスペディアのサーバー間のデータ転送では、開発者の認証システムは使用されません。
  • 予約リクエストの HTTPS プロトコルでの送信に失敗すると、次のようなエラー メッセージが表示されます。
verbose message = Reservation requests must be made through HTTPS; 
        
presentation message = Reservation requests must be made through HTTPS

クレジットカードと通貨のマップ

各クレジットカード タイプで処理可能な通貨の値については、通貨とカード タイプのマップを参照してください。

  • クレジットカード会社はいつでも自社データベース システムに値を追加または削除できます。
  • この表は参照専用です。
  • 支払いタイプのリクエストを使用して、送信された現地通貨で請求可能なカード タイプを動的に取得します。

デフォルトの通貨を設定する場合は、「支払いタイプのリクエスト」で返される結果に特に注意してください。

クレジットカード会社のブランド表記の平等性が必須

ヒント : 以下の情報に従って、最終的な公開要件およびクレジットカード ブランド表記の平等性に関するサイト審査に合格するようにします。

現在、クレジット会社によって以下の必須規定が施行されています。

  • お使いの Web サイトが、以下のすべての項目を満たしていない場合、コンプライアンス違反の高額な罰金 (最小で $20,000 ですが、$100,000 に及ぶことも多々あります) が科されるおそれがあります。
  • クレジットカード会社は、無作為に Web サイトを選択して、ブランド表記の平等性を遵守しているかどうかを監査します。


サイトに支払いオプションが表示されるとき、ユーザーがオプションの選択が行わないうちは、「何も選択されていない」状態でなければなりません。さらに、すべての支払い方法が平等に表示されている必要があります。

クレジットカード会社のブランド表記の平等性のアウトラインからの引用

「支払い方法のどのブランド、ロゴ、アクセプタンス マーク、またはシンボルも、他のブランド、ロゴ、アクセプタンス マーク、またはシンボルより...大きいサイズであったり、何らかの形で大きく見えたり、より重要であるように表示されることがあってはなりません。」

  • 取り扱い可能な支払い方法が Web サイトの決済ページで列挙されている必要があります。ドロップダウン メニューそれ自体だけでは不十分です。
  • ドロップダウン メニューおよびラジオ ボタンは、特定の選択肢があらかじめ選択されていることのないようにします。特定の選択肢があらかじめ選択されているなら、特定の支払い方法が優先されていることになります。
  • 利用可能な支払い方法のカード ロゴを同じサイズと配置で表示します。意図せずに特定の支払い方法が優先的に表示されることのないようにするため、それらを横一列にまたは等間隔の表形式で配置することをお勧めします。
  • 意図せずにクレジットカードがデビットカード / チェックカードや他の支払い方法よりも優先されることを避けるため、以下に示すように「クレジットカード」という語ではなく「支払いオプション」という語を使用します。

適切な形式の例 :

どのカード タイプもあらかじめ選択されておらず、すべての例は「何も選択されていない」状態から始まっています。 ユーザーに表示されるページは、必ず最初は選択肢が「何も選択されていない」状態でなければなりません。

サンプル画像 :

支払いタイプ リクエスト メソッド ("getPaymentInfo") は、予約リクエストで送信された通貨で使用可能なカードを返すことに注意してください。

  • 支払いタイプのリクエストに「ロケール」を含めると、支払いタイプのリクエストでロケールを省略した場合よりも多くのオプションが返されます。

支払い入力フォームを読み込む前にこのリクエスト メソッドを作成しておくと、ユーザーはその通貨で使用できる支払い方法から選択できるようになります。

  1. PaymentTypesResult で返されるカード タイプのみを表示します。
  2. 詳細については、予約リクエスト <creditCardType> を参照してください。
 

不適切な表示の例

下の例は、あらかじめ優先的に表示されている、またはあらかじめ選択肢が選択されていると見なされます。これらすべては公開要件を満たしません。

  1. 支払いタイプの画像がないドロップダウン リスト
  2. 支払い方法が 2 つの別個の図に分かれて表示されている
  3. 説明メッセージが図の中で別々の場所に表示されている
  4. クレジットカード部分の記述がデビット カード / チェック カードは取り扱いできないと示唆している
  5. 比較対象のサイズが同じでない
  6. 図が縦一列になっており、優先順位を連想させる