CVV Retention Policy

According to PCI Compliance regulations, the CVV cannot be stored after the card has been used (i.e. was charged). Since PCI Booking offers card storage solutions and we are not part of the process of "using" the card, the CVV Retention Policy was created to enforce how long CVVs can be stored in PCI Booking and how and where the CVV can be relayed to.

Understanding the CVV Retention Policy

The CVV Retention Policy is made up of two components:

• The retention period end date: CVVs can be stored in PCI Booking for up to 4 years (48 months) from the date that the card was first tokenized in PCI Booking.
• The card relay whitelist: Cards with CVV details can be relayed only to specific destinations (each token can be set to relay to up to 50 destinations).
  The relay whitelist is made up of three components per destination (see below a full list of destination types):
  • Destination Type: Indicates which type of destination this is.
    For example, HostName.
  • Destination Data: This is the destination itself.
    For example, if the destination type was HostName, then the destination data will be the URL of the destination: http://httpbin.org/post
  • Quota: The number of times the card with the CVV can be relayed to this destination (between 1 and 50 times per destination).
    • Please note, in case when using the destination GeneralProperty, the Quota value can be between 1 and 5 only.

The CVV will be deleted after either of the following occurs (the earlier of the two):

• The retention period end date has reached
• The card details with the CVV has been relayed to all destinations in the number of times allowed per destination.

As an additional option, customers can choose to have the full card details deleted when the CVV is set to be deleted.

📘

Regardless of the CVV retention policy set for the token, the card details without the CVV can be sent any number of times to any destination without any limit.

CVV Retention Destination Types

🚧

Make sure that the destinations for relay based on host names are also included in the list of relay restrictions (if one was set up).

System-wide CVV Retention Policy

When a card is tokenized, it is automatically assigned with the default, system-wide retention policy. The system-wide retention policy is:

• CVV retention period will be set to one month.
• The card with the CVV can be relayed only once to the first target that is used. No further relays that include the CVV will be permitted.

Setting the CVV Retention Policy

Once the card has been tokenized in PCI Booking (it is not important which method was used to tokenize the card), the Booker will have up to 60 minutes to set the CVV Retention Policy for this token. Within those first 60 minutes of the life of the token, you can set, change or remove the CVV restrictions for that token - after the 60 minutes have passed, no further changes to the CVV policy will be allowed.
The CVV Retention Policy can be set in one of two ways:

• Specifically for this token by using the CVV Retention Policy API methods.
• Inherit the account-wide CVV Retention Policy (read more on managing CVV restrictions in your account).

If the CVV Retention API method is not used within 60 minutes, the token will be automatically assigned with the account-wide retention policy. If the account is not set with a retention policy, PCI Booking will use the system-wide default retention policy for this token.

Below is an example of a request to set the CVV Retention policy with the minimal set of parameters. You can expand this request based on your specific needs. If you require any assistance setting up the CVV Retention Policy request, please do not hesitate to contact our team.

<?xml version="1.0"?>
<CardCvvRetentionPolicy>
    <CvvEndRetentionDate>2020-05-11T11:37:54</CvvEndRetentionDate>
    <CvvRetentionPolicyList>
    </CvvRetentionPolicyList>
</CardCvvRetentionPolicy>

{
  "CvvEndRetentionDate": "2020-12-12 12:32:45",
  "CvvRetentionPolicyList": []
}

Changing the CVV Retention Policy

The CVV retention policy can only be set or changed during the first 60 minutes after the token has been created. During that time, you can perform the following tasks:

• Set the CVV Retention Policy - this will override all existing settings.
• Delete CVV Retention Policy - this will delete the entire CVV retention policy and revert the token to use the default system-wide retention policy.
• Delete CVV Retention Policy for a specific Destination Type - this will delete only the destinations in the retention policy that match this destination type.
• Delete CVV Retention Policy for a specific Destination Type / Destination Data combination - this will delete only the destination in the retention policy that match this specific combination of destination type and destination data.

🚧

Deleting a destination in the retention policy can only occur within the first 60 minutes after the token has been created and only if the CVV has not yet been relayed to that destination.

Any time after 60 minutes from tokenization, the CVV retention policy for this token cannot be changed or altered.

If you must change the retention policy, we recommend you use one of these workflows:

🚧

Duplicate Token

All of the above processes will result in a duplicate token. It is your responsibility to clear the original token from the PCI Booking storage. If you do not do so, you will be charged storage fees for this token in accordance with your billing terms.

Keeping track of CVV retention policy and usage

Customers can keep up with the CVV retention policy and the usage of the CVV in one of following ways:

• Use the API to retrieve the CVV Retention Policy details - the response will include the full policy and the usage made within it until now.
• Use the API to retrieve the CVV Retention Policy for a specific destination type and data - the response will include the policy set and the usage made for this destination.
• Process the response headers from the Token Replacement in Request or Universal Payment Gateway methods - these headers will indicate the CVV retention policy and the usage so far for this destination (see below examples of response headers).

"Cache-Control": "no-cache"
"Pragma": "no-cache"
"Content-Type": "application/json; charset=utf-8"
"Expires": "-1"
"X-Pcibooking-CVVRetentionEndDate": "2020-04-14T15:58:14"
"X-Pcibooking-CVVUsage": "1/10"
"X-Content-Type-Options": "nosniff"
"Server": "WWW Server/1.1"
"X-XSS-Protection": "1; mode=block"
"Date": "Mon, 14 Jan 2019 15:59:04 GMT"
"Content-Length": "368

"Cache-Control": "no-cache"
"Pragma": "no-cache"
"Via": "1.1 vegur"
"Content-Length": "5915"
"Content-Type": "application/json"
"Expires": "-1"
"Access-Control-Allow-Origin": "*"
"Access-Control-Allow-Credentials": "true"
"X-Pcibooking-CVVRetentionEndDate": "2020-04-14T16:01:29"
"X-Pcibooking-CVVUsage": "1/5"
"X-Content-Type-Options": "nosniff"
"Server": "WWW Server/1.1"
"X-XSS-Protection": "1; mode=block"
"Date": "Mon, 14 Jan 2019 16:02:49 GMT