個人的な仕事関連の経験から、多くの「予約エンジン」には、予約が行われてからゲストがホテルを出るまでの間に、お客様のクレジットカードのCVV情報が保存されることがわかっています。 1年前に部屋を予約する人は、CVVデータが予約エンジンに完全な1年間あることを意味します。
私の職務では、このサービスの複数のプロバイダーと定期的にやり取りする必要があるため、これを知っています。これにより、多数の顧客のCVC/CVV/CVV2コードにアクセスできるようになります。予約時にコードを収集し、チェックアウトまでコードを保持するというアプリケーションの動作を個人的に観察しました。
特定の予約エンジンでは、クレジットカード情報を確認できる回数が制限されています(特に1つでは5人に制限されていると思います)が、その情報はまだチャネルマネージャーとPMSに渡されており、3つすべてで作業しています。
もちろん、トランザクションを処理するためにCVVコードを必要としない特定の支払いゲートウェイがあります。ただし、私が一緒に仕事をしているホテル経営者の多くは、支払いゲートウェイを持っています。
このような長期間のデータの保持がPCI-DSS標準、またはその他の法的要件や業界のベストプラクティスに反していることを心配しています。トピック(下記のリンク)に関する1つの質問への回答を読みましたが、予約エンジンなどのサービスにこれがどのように適用されるかについて、問題はまだはっきりしていません。
機密認証データの保管は、許可後に明示的に保管しないでください。事前認証データは保存でき、PCI DSSの領域外にあります。個々の支払いカードのブランドは、それを保管できるかどうか、期間、およびプロセスで何をしなければならないかについての詳細を決定します。
PCI SSCは、このデータはPANなどの承認後のカード会員データと同じ勢力で保護する必要があることを明確にしています。事前承認と事後承認のアプローチが異なるのは、事前承認データが多様で複雑な性質を持っているためです(物理的なカードは事前承認データと見なすことができ、文字通りカードを郵送する人がいます支払い-カード所有者がそうすることを意図している人がいることはわかりませんが。)
CVVの保存は許可されていません:
考慮すべき点がいくつかあります。
1)-お客様が作業を行わない限り、booking.com、Expediaが保存しているかどうかを確認する方法はありません。彼らはQSAに答える必要があります。これで、保存されているCVV、つまりCVV2情報については、 CNPトランザクション に使用されます。私ができることは、会社が行うことを見て、おそらく暗号化ハッシュを作成し、hashを格納して、比較。
2)-繰り返しになりますが、CVVは詐欺を防止するための追加メカニズムにすぎません。実際にトランザクションを処理する必要はありません。
プロセスが承認されると、一部のクレジットカード会社は、将来の検証に使用する他の識別子を販売者に提供します。これは、Visaの " Merchant's Best Practice for Recurring Transactions "を介して読み取り/説明できます。
それがどのように機能するかを推測しなければなりませんでした:
Consumer --> (CC + CVV2) --> Merchant
Merchant --> process this --> VISA
VISA --> all is good to go btw here is a summary [additional code] for future reference --> VISA
Merchant --> stores additional code for future reference
Consumer (months later) --> "I want to buy this" --> Merchant
Merchant --> we have data from you, and also from Visa
Merchant --> processed thank you --> Consumer
限られた量の読書、および/またはカフェインについて私の最善の推測。
チェックする関連アドレスがない限り、取得機能はCVVを効果的に使用しないことに注意してください。取得機能はAVSチェックを無効にできます。つまり、CVVは送信時に無視されます。