CVC2 Authorisation for back orders

[JohnH]

We know that the storage of CVC2 is forbidden post authorisation, however, how do companies overcome the out of stock/back order issue?

For example where 3 items are ordered, but only 2 are in stock and 1 goes on back order.

Currently, we take a payment for the 2, which is authorised, then the CVC2 is stored until the 3rd is in stock and dispatched. This is when the second payment is then taken, authorised and the CVC2 is then purged when the order is completed.

However, we acknowledge this as storing the CVC2, which is forbidden by 3.2.

So, we can only see the following approaches -
1) Process second transaction without CVC2
2) Re-contact card holder for CVC2 for the second transaction (a real PITA)
3) Taking the payment for all 3 items (a bit 'sharp')

Has anybody got an alternative solution that is accepted by the PCI-DSS?

[wconway]

Let's try a process of elimination... We should reject #3 since it is not, I believe, compliant with the associations' rules (can't bill before shipping). The question then comes down to a business decision: what is the difference in merchant fee (based on interchange classification) between having the CVV2 and not. That is, is it worth the cost/pain to re-contact the consumer?

Alternatively, I'd check to see if your acquirer can help with a split shipment. That is, do they have an offering (like recurring payments) that might fit the bill? Is there a way they can retrieve/keep the CVV2 for the second auth or better yet link it back to the original? This seems to be as much a MOTO issue as PCI.

[jbhall56]

We are seeing more and more acquirers issuing transaction numbers or codes that are tied to an original transaction that can be used for backorders or other issues related to out of stock or future shipments. The merchant stores the transaction number/code for later use so that they do not have to store the PAN, name, expiration date and CVV data. When the backorder is finally satisfied, the merchant conducts the transaction using the number/code and the acquirer completes its part by providing all of the sensitive information.

The other alternative is to store the PAN, name and expiration date in an encrypted file/DB for later use for the backorder just like an online retailer stores information for future orders.

[Patrick]

Option 1; accepting transactions without the CVC2 transfers liability onto the merchant in the case of fraud. If you've already approved with the CVC2 then you know that the transaction is not fraudulent (or at least if it is then the fraudster holds a valid CVC2 for the PAN)

[J.D. Oder II]

"When the backorder is finally satisfied, the merchant conducts the transaction using the number/code and the acquirer completes its part by providing all of the sensitive information."

This comment is not quite accurate. All processors, gateways, service providers and merchants may not store CVV2 at all. You statement would imply that processors store this data and then stuff it in.

Book and Ship processing - What we are talking about works this way.

Example: Order has three items. 2 are in stock, one is backordered.

Best Practice:

1. Obtain CVV2, AVS, and Card data, and amount including estimated shipping.
Note: This might even be the amount including the backordered product.
2. Authorize this amount, and settle for the two items to be shipped. If the settlement and authorization amount differ return that difference using a partial void/partial reversal.

3. Once the backordered item is in stock, create a new transaction with either the card number, expiry info, and AVS info (or better yet a provider's reference number or Token) and then settle for that amount.

Since the CVV2 passed the first time, and the cardholder is expecting the item CVV2 should not be needed.

Compliancy is as follows.

CVV2 - This protects from Chargeback and Merchant Liability
AVS - Lowers total cost of the transaction and discount rate paid.

Thanks

[kellz123]

Option 1; accepting transactions without the CVC2 transfers liability onto the merchant in the case of fraud. If you've already approved with the CVC2 then you know that the transaction is not fraudulent (or at least if it is then the fraudster holds a valid CVC2 for the PAN)

Option 1 would be using a merchant account processor to process the payments. I currently use cardservicesales.com (http://www.cardservicesales.com/) to process my online payments and it works out great. I had no idea about the CVC2 to determine a fraudulent transaction. Thanks for the feedback.

[jbhall56]

"This comment is not quite accurate. All processors, gateways, service providers and merchants may not store CVV2 at all. You statement would imply that processors store this data and then stuff it in."

The reason a transaction number is issued is to show that the correct information was gathered in the original transaction so that subsequent related transactions can be processed. That way when the rest of the transaction is completed, the additional charges, if any, can be processed through on the original transaction's pre-processed information by providing the transaction code/number to complete the follow up transaction. This allows the merchant to not have to store cardholder data (CHD) on their system(s).

This type of process is particularly useful in the hospitality industry where the cardholder usually only presents their credit card when they check in and then when they check out. At original card presentment, the hotelier's system presents the card for a phantom payment and then receives back a transaction code/number that is then used for the processing of future payments until check out.

[J.D. Oder II]

I was not talking about the Transaction Number per se, but the CVV2 and how it is not to be stored. Bottom line all of us in the transaction flow from the merchant, to the gateway, to the processor, et al are prohibitied from storing the CVV2 information post initial authorization. The CVV2 number, since it is only a chargeback protection anyway and does not hinder regulatory compliance (that is discount rate or interchage fees) should be used as a fraud detection mechanism for the initial authorization and then all subsequent back-order or split shipments should only use the AVS info.