CVV number on a remit envelope

We never ask for it and have always been fine. And I agree with @Austen Brown - post the online link instead. Saves a lot of room on the envelope, plus people are skittish about giving their credit card numbers in writing these days anyway.

As we look at moving our gift processing to Unified View, we are now required to have the CVV to process offline credit card donations. @Silvia Ochoa is correct, PCI DSS prohibits CVV data from being written, retained or handled in any format including paper (DM reply coupons in our case). So it looks like we are stuck being unable to accept credit card donations for mailed appeals once database view is gone. @Jake Gaston where does this leave all of your customers who still use mailed appeals?

I understand the need for the CVV. In our opinion having the info on a reply slip mailed back to the org is a very high risk to the donor. We removed it from our response slips. Still have a few folks who call in to make their payment by card.

I am not an expert on PCI compliance. My understanding has always been, for US anyway - don't know if different for other countries, is that it's storing the CVV/card info that is a compliance issue. Not receiving it in the mail. The compliance documents I been a part of reviewing focused on secure storage and destruction.

Google AI results:

PCI Compliance Requirements for Donation Cards:

• Do Not Store: The card verification code (CVV2, CVC2, CID) must not be stored in any system or paper file after the transaction is authorized.
• Immediate Destruction: If a, CVV is collected to process a one-time, mail-in donation, the paper form must be physically destroyed immediately after the transaction.
• No Recurring Storage: You cannot store the CVV code to facilitate future or recurring donations.
• PCI Security Standards Council +5

FWIW

Most of the PCI guidance talks about storing the CVV after authorization, but writing it down on a paper reply coupon counts as storage, even though it is prior to authorization, and it constitutes a big risk to the donor to do that, as well as making the organization collecting and handling it, now PCI non-compliant.

PCI also suggests checking the card brands in your country. I’m in Canada and Visa Canada specifically exempts mail-order transactions from requiring the CVV (and prohibits the collections of it in written form) [visa.ca]

There are some useful comments on this thread that I'd encourage you to read/respond to so we can share as much as possible about why this process is not ideal for charities relying on mailed donations. 😔

Apologies in advance for the length of this post and that I have posted this in three discussion relating to CVV, I think its important to share the information as widely as possible to ensure we're getting a compliant, useful response.

After the Beyond the BB RE Product Update Briefing – @Bill Connors on Friday 8th May followed up by this post by @Carlene Johnson we learned that BB has changed its approach to the CVV requirement.

I followed this up with our customer success manager and was given the below link to keep update on this topic:

'You’ll see the latest updates will be updated here: What are the CVV or CSC requirements for Raiser's Edge NXT back office transactions?'

I've subsequently responded as I feel the guidance is still a little 'off track' with regarding what is compliance for PCI and for card issuers, please see below for my response and suggested course of action, I'm really happy to receive feedback/comments on this approach as I believe it to be correct but very much want to learn if I have misinterpreted guidance along the way:

Thank you for sharing the updated guidance.

Having now reviewed the article in full, I remain concerned about the way the guidance characterises ‘PCI-compliant collection of CVV for manual transaction entry’.

The wording throughout the article appears to imply that collecting CVV through manual or postal workflows is fundamentally acceptable from a PCI/card-brand perspective provided organisations implement suitable internal controls.  For example:

‘Many customers have active solicitations and campaigns in the market and may not have internal processes in place to support PCI-compliant collection of CVV for manual transaction entry’.

My concern is that this frames the issue primarily as an operational/process gap, rather than acknowledging the underlying compliance concern with collecting CVV via persistent written channels in the first place.

While PCI DSS permits CVV use for card-not-present authorisation, Visa also classifies CVV2 as sensitive authentication data which must not be stored.  In a postal donation workflow, the CVV is necessarily written down, transported, handled, and temporarily retained before destruction.  That creates an exposure scenario fundamentally different from a telephone MOTO transaction where the value can be entered directly at the point of collection.

As written, the article could reasonably be interpreted by customers as confirmation that collecting CVV on mailed forms is broadly recognised as PCI compliant if appropriate internal procedures exist. I do not believe the current wording adequately reflects the nuance, differing card-brand interpretations, or the practical compliance concerns many organisations and assessors would have with that approach.

The recommendation to use QR codes or follow-up phone calls appears to recognise that collecting CVV on mailed forms presents additional security and compliance risks.

I’d appreciate it if you could pass this feedback on to the relevant compliance, product, and engineering teams, as I think some clearer wording around the distinction between telephone MOTO and postal workflows would be really helpful for customers trying to interpret the guidance correctly. 

For transparency, I also intend to add these observations to the existing Blackbaud Community discussions on this topic (as linked in my original email below), as I think it would be helpful for customers to have a broader and more collaborative discussion around the practical compliance considerations here.  PCI requirements and card-brand interpretations can be something of a minefield, and I think additional context and nuance would benefit organisations trying to navigate this area responsibly.