Storing CVV2 for delayed credit card clearance.

[pgaspara]

Hi,

our company is analyzing new requirements to accept credit card payments online for new regions, for some credit cards we have a processor in place and for others we are storing the information and processing them manually. The customers do not know whether their credit card is processed automatically or manually in a delayed fashion.

For the automated credit cards we request a real-time authorization and we do not need to store CVV2. For manual, we are required to provide CVV2 to our banks (required by the bank in some of the regions that we do business) but we need to be PCI complaint and thus cannot store CVV2 either.

The solution we're being proposed is to call the customer to gather CVV2, but that of course is very inconvenient and may have an impact on the customer experience and we may even see an increase in orders cancellation because of this.

Does anyone know of an alternative we can look at? For MOTO credit cards, is it ok to ask customers to fax their credit card information with CVV2? I suppose not but I will appreciate if anyone can confirm.

[cmark]

CVV2 is required for initial authorization only. If you are manually entering the data for a MOTO transaction, you can retain CVV2 until you receive the initial authorization response. Once the authorization has completed the data must be purged. This is very common.

[pgaspara]

Thanks cMark!

What if it was not technically a MOTO transaction but we capture credit card information online. Would it be ok to store it encrypted in our databases and blank it out after authorization?

Regards,

pgaspara

[cmark]

technically you can retain sensitive authentication data until the initial authorization is complete. It does not matter whether it is ecommerce, MOTO, or some other form or transaction. That being said, the data is critical and as such you want to ensure you don't have compromise of such data. Whether it was prior to author or after auth, it will be treated the same under card brand rules.

[Maxwell]

Not from what I have read. The CVV is not allowed in the DB period. If it were allowed, there isn't really any point to store it anyways.

It should be transmitted to your gateway at the point of sale, when the client completed the order. The authorization is sent instantly back to your shopping cart.

You can then run your batch whenever you want and capture the funds as desired, up until when your authorization expires (7-30 days depending on your agreement with your processor)

Capturing the authorized cards doesn't require a CVV nor does recurring billing of said cards.

[Immople09]

I would like to know what the time frame is to process a credit card and ship an item out for an e-business.

Once I process a card, how long do I have until the item must be shipped out to the customer?

Thanks.

[jbhall56]

Not from what I have read. The CVV is not allowed in the DB period. If it were allowed, there isn't really any point to store it anyways.

It should be transmitted to your gateway at the point of sale, when the client completed the order. The authorization is sent instantly back to your shopping cart.

Not all business models work the way you describe. We have a number of eCommerce merchants that batch their transactions and therefore do not authorize until end-of-day or end-of-shift. In those cases, the CVV/CVC/CID/etc. data is considered pre-authorization data and can be stored. It still must be protected (i.e., encrypted, limited access, etc.), but it is allowed to be retained until the transactions are approved or declined.

Capturing the authorized cards doesn't require a CVV nor does recurring billing of said cards.

Correct. There are a number of schemes that can be used between a merchant and processor to allow for conducting recurring transactions that do not involve the merchant having to store the cardholder's account information. It's always good to see if you can leverage such a solution before you start storing cardholder data.

However, the capture of CVV/CVC/CID/etc. does typically reduce a merchant's chargeback and dispute charges. So that is why a lot of merchants capture it.