サードパーティの処理を使用する場合のPCIコンプライアンス
私の会社は、新しいeコマースサイトの開発をサードパーティのWeb開発会社にアウトソーシングしています。トランザクションを処理するためにサイトを設定する方法は、ユーザーに必要な支払い情報を入力してから、そのデータを支払いを処理するサードパーティのマーチャントに渡し、すべてが問題なければトランザクションを完了することです。
PCI/DSSコンプライアンスの問題が提起されたとき、彼らは次のように述べました。
トランザクションが処理されると、クライアントのブラウザが機密情報をサードパーティのマーチャントに直接送信するため、PCI認証は必要ありません。ただし、すべてのインターフェイスと表示は当社によって制御されているため、プロセスはユーザーに対して透過的です。機密性の高いカードデータがサーバーまたはWebアプリに接触することはないため、準拠する必要があるサーバーはサードパーティのマーチャントのみです。
私はWeb開発者の知識を非常に信頼し、尊敬していますが、彼らが言っているのは、私にとって深刻な危険信号です。
サイトの説明方法として、PaypalやGoogle Checkoutのようなホスト型の支払いページを使用しないことは間違いありません（もし私たちがUIの制御を維持するにはどうすればよいでしょうか？） 、XMLを直接使用して処理のためにサードパーティの販売者と通信することが、他の唯一のオプションのように思われます。
私の2つの質問は次のとおりです。
- あなたが読んだすべてに基づいて、「XML Direct」はおそらく彼らが使用できる唯一のオプションですか、それとも私がそれらを実装できるかわからない別の方法がありますか？
- 最も重要なことは、サイトがPCI認証を必要としないのは本当ですか？私が理解しているように、XMLダイレクトメソッドを使用することはdo PCI/DSS認定を受ける必要があることを意味します。
あなたが読んだすべてに基づいて、「XML Direct」はおそらく彼らが使用できる唯一のオプションですか、それとも私がそれらを実装できるかわからない別の方法がありますか？
XML Directが支払いにサードパーティを使用する方法は他にもあります。この例は、 Authorize.netのダイレクトポストメソッド （DPM）です。 DPMでは、支払いフォームをホストできるため、そのページのルックアンドフィールを完全に制御できます。フォームが送信されると、処理のためにAuthorize.Netに直接送信されます。トランザクションが完了すると、ユーザーはWebサイトに戻されます。クレジットカード情報に触れることはありませんが、プロセス全体のルックアンドフィールを完全に制御できます。
最も重要なことは、私たちのサイトがPCI認証を必要としないということですか？私が理解しているように、XMLダイレクトメソッドを使用することは、PCI/DSSの認定を受ける必要があることを意味します。
何らかの方法でサイトを介して支払いを受け入れる場合、注意すべきPCIコンプライアンスがあります。ただし、困難なもののほとんどは支払い処理者に渡されます。対処すべき問題が少なくなります。そのため、開発者が言うように、PCIコンプライアンスを完全に免除されているわけではありませんが、そのほとんどは手作業で行われ、残っているものは実装が容易です。