根据个人的工作相关经验，我知道许多“预订引擎”会从预订到客人离开酒店期间存储客户信用卡的 CVV 信息。对于提前一年预订房间的人来说，这意味着他们的 CVV 数据在预订引擎中保存了一整年！
我知道这一点，因为我的职责要求我定期与该服务的多个提供商进行交互，这使我能够访问大量客户的 CVC/CVV/CVV2 代码。我亲自观察了应用程序在预订时收集代码并将其保留到退房时的行为。
某些预订引擎确实限制了您查看信用卡信息的次数（我相信其中一个特别限制了我到 5 次），但信息仍在传递给渠道经理和 PMS - 我与这三者一起工作。
当然，有些支付网关不需要 CVV 代码来处理交易。但是，与我合作的许多酒店经营者都有支付网关。
我担心长时间保留这些数据会违反 PCI-DSS 标准或其他法律要求或行业最佳实践。我已经阅读了关于该主题的一个问题的答案（下面的链接），但是关于这如何适用于预订引擎等服务，我仍然不清楚这个问题。
不允许存储 CVV：
有几点需要考虑：
关于 1) - 除非您在那里工作，否则无法确认 booking.com、Expedia 是否正在存储。他们必须回答 QSA。现在，就存储的 CVV 而言，即 CVV2 信息，它用于CNP 交易。我可以看到一家公司正在做的事情可能是制作加密哈希，存储哈希并进行比较。
关于 2) - 同样，CVV 只是一种旨在防止欺诈的附加机制。它并不真正需要处理交易。
一旦流程获得授权，一些信用卡公司会为商家提供其他标识符以用于未来的验证。这可以通过 Visa 的“商户经常性交易最佳实践”阅读/解释。
如果我猜猜它是如何工作的：
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
我对有限阅读量和/或咖啡因的最佳猜测。
敏感身份验证数据的存储明确不得在授权后存储。预授权数据可以被存储并且在 PCI DSS 的范围之外。各个支付卡品牌决定了它是否可以存储、存储多长时间以及在此过程中必须执行的操作。
PCI SSC 已明确表示，应以与 PAN 等授权后持卡人数据相同的力度保护这些数据。预授权与后授权的不同方法很大程度上是由于预授权数据的多样性和复杂性（您的实体卡可以被视为预授权数据，并且有些人将他们的卡邮寄到付款 - 虽然我不知道有人打算让持卡人这样做。）
值得注意的是，除非有关联的地址可供检查，否则收单方不会有用地使用 CVV。收单方可以禁用 AVS 检查，这意味着提交时忽略 CVV。