To further secure our customers’ credit card information, we are required to make a few changes in how the CVV is stored in our system as part of the card token, how / when the CVV is sent to third parties and when the CVV is deleted.
Below is our suggested implementation of the behavior as approved by our security consultants. We would like to ask your input on these changes in order to ensure that the proposed solution can address all issues. We ask that you provide us with your feedback no later than Monday, August 21st.
Currently, customers can store the CVV along with the card token indefinitely.
CVV details are deleted from a token either when the customer actively deletes the card token or the CVV itself or when the card details are viewed in the card display page (in which case the CVV is deleted automatically after one viewing).
In addition to unlimited storage period, customers can relay the card details, including the CVV, to any third party as many times as needed.
Proposed changes in behavior
We would like to enhance the security of cards stored in the PCI Booking system by adding the following restrictions, which will be based on the requirements of the reservation. For example, according to the reservation, the card data with the CVV will need to be sent to an airline and a hotel, for a reservation that will take place in two months.
CVV value will be stored for a limited time only - up to 48 months (4 years).
The default storage period will be one month, the merchant can change the date up to 48 months. Once the storage period has passed, the CVV will be deleted automatically. The other card details will not be affected.
- Whitelist targets: Customers will whitelist the targets where the card details (along with the CVV) will be sent to. The target whitelist can include the name of the payment gateway (for use with our Universal Payment Gateway), a target URI (for use with our relay (token replacement) method) or a merchant ID / booker ID (for use with the display iframe page).
- Number of times sent: Customers will set, for each target, the number of times that the CVV can be sent to that target.
- The default is that the CVV can be sent once to one target.
- Once the max number of times a CVV can be sent to a whitelisted target has been reached, the customer will not be able to send the CVV again to this target.
- Irrespective of the above restrictions, the other card details can be sent to the third party as many times as needed without any limitation.
Customers will need to submit the settings of storage period and target whitelisting within one hour of the card tokenization in PCI Booking or until the first instance of relaying the card to a third party - the earlier of the two.
Proposed changes in PCI Booking
In the PCI Booking API, we will provide a set of API methods to update the CVV restrictions and view the current set of restrictions for each token.
Setting CVV restrictions
The user will be able to submit the following information regarding a token:
- Storage expiration date
- A list of targets and number of relays permitted per target
Retrieving CVV restrictions
The users will be able to retrieve the following information about the token:
- Target whitelist
- How many times per target
- How many times sent
- How many times remaining to send
- Is the CVV already deleted
- What is the CVV end retention date
Required changes from clients
If you are only sending the card details with the CVV once per card to a single third party, then you will not be required to make any changes in your implementation.
If you require to send the card details with the CVV to multiple locations and or multiple times, you will need to change your implementation accordingly:
- Tokenize the card as always
- Within one hour of tokenizing the card, send PCI Booking the CVV restrictions list (this is the additional step)
- Relay the card as always
Current users - Rollout Plan
Once we have received your feedback on the proposed plan and addressed all of the issues raised, we will begin the implementation process of these restrictions in our system.
Once it is deployed in our production system, we will notify our clients and from that time, we will allow a period of 3 months for existing customers to implement the changes in their system. After those 3 months, the restrictions will apply to all customers.
During that implementation period, existing customers will need to change their system to utilize the new API methods:
Whitelist target destinations, where those CVV will be sent to. These can be:
- Target Uri’s to set the card to
- Users who can view the card
- Specific Payment Gateways
Define how many times each target will be entitled to receive the CVV .
Set CCV delete date.
Note: the following actions will not change:
- Customers can delete the CVV at any point.
- Card details - without the CVV - can still be stored for an unlimited amount of time.
- Card details - without the CVV - can still be sent an unlimited number of times to any third party target without any limits.
We would appreciate receiving your feedback on these proposed changes. Please send your feedback to email@example.com no later than Monday, August 21st.
We value your feedback and and design changes will be assessed based on the feedback received; we will send out further announcement with details of the planned schedule.
July 24th, 2017