The responses to yesterday’s post and the Confidential Agitator Survey were both thoughtful and concerning.

[If you haven’t already completed the survey, I hope you will take 3 minutes and do so today. Just click here.]

Clearly, many readers responding to the survey have experienced significant frustration, confusion and substantial lost income in their efforts to change CRMs and Payment Processors.

And, by a substantial majority, folks want a better, more transparent way to deal with these issues –including a surprising number who expressed interest in forming a nonprofit payment processing cooperative.

Because some Agitator readers are in the process of changing CRMs and Payment Processors, we’re reprinting some of the Comments that surfaced in the survey in hopes they will provide guidance to others.

Because so much of the confusion, obfuscation and stalling around the process of changing vendors involves the mysteries of Payment Processing, I’ve consulted a former owner of a payment processing company with $6 billion in transactions and with the highest levels where compliance standards are concerned.  He has no stake in payment processing for nonprofits.

From those conversations I’ve prepared a free Agitator Guide to Dealing With Reluctant CRMs and Payment Processors. Don’t hesitate to download it.

Comments and Responses

What follows is a sampling of the comments received from the Survey along with responses from the expert. I’ve withheld names of CRMs and Processors for privacy reasons.

These comments include the terms “PCI compliance” and “tokens”.  You’ll find these explained in full in the Guide we’ve prepared.

1. COMMENT: “Our CRM database switched from users being able to directly key-in credit card information to using a separate, plug and go credit card processor. Even though this change was issued by the vendor for PCI compliance and donor security, we still had to contact all of our recurring donors, obtain their credit card information, and reenter into the new system.”

RESPONSE:  Manually keyed credits cards are definitely a concern when it comes to PCI compliance, however, their process should have included some identifier and included that in the tokenization process, like “account id” or some other id.  To say that once they transition you to a PCI-compliant process and are unable to migrate all of the prior card information is definitely lazy – or they simply lack the technical skills and should not be in the payment processing business.

2. COMMENT: “Their system was unable to move the tokenized details”

RESPONSE: This function should be a basic part of building a payment processing platform.  To not have this function is like CRM vendors not having an export utility.

Part of building a payment processing platform is ensuring you have all customer requirements implemented.  To say they are “unable” to perform this is as shocking as a payment processor saying they are “unable to process refunds” – despicable.

3. COMMENT: “Said they couldn’t do it because of some PCI Compliance excuse.”

RESPONSE:  The process of transferring tokenization data between two PCI-compliant vendors is covered in the PCI compliance standards checklist.  Using this as an excuse is quite ridiculous.

That vendor is counting on the ignorance of organizations in regard to PCI compliance and are banking on that ignorance to hold the client’s donors hostage.

4. COMMENT: “Our vendor could give us the encrypted data, but not the “token” to decrypt it. The “token” was the property of the payment processor, I believe. Obviously, the encrypted data is useless if we can’t decrypt it.”

RESPONSE: Not possible.  In fact, if a payment processor uses a single “key” to encrypt all of their data they are at risk of that key being compromised and all of their customer’s data exposed.

Saying the encryption key is owned by the processor is fair, but that’s not what your new processor needs.  They only need the data being sent by the old processor which will encrypted only for the purpose of the transfer. To do otherwise would be like your ATM PIN only working at a single ATM machine because the ATM vendor didn’t know how to validate it across financial institutions.

There is an entire section in the PCI standards devoted to encryption keys and management of credit card information.  Since tokenization is not directly a part of the encryption policy, any processor that has more than one organization using tokenization would tokenize that data using a key unique to the organization.

This would protect them from system-wide breaches and enable them to support token transfers which is about as basic a requirement as payment processing itself.

5. COMMENT: “In my time at this organization we’ve had six or seven different CRMs (currently using XXX, XXXX, and XXX) and multiple charge processing platforms. Fortunately, the number of recurring pledges we’ve been unable to move as part of any past migration has numbered in the 10s or 100s, not 1,000s. It’s only through struggling through these processes in the past that we’ve learned to make sure portability is in any new agreements with vendors.”

RESPONSE:  Sad that you’ve ever had to deal with this at all.  Carefully review the language in agreements with CRMs and Processors to ensure they can and will deliver should the time for switching vendors comes.

6. COMMENT: “We switched from XXXXX   XXXX in June/July2018 to XXXX CRM. XXX warned us that XXXXX Merchant Service would make things difficult–and they did. Although we did suspect some of this was because of GDRP, and consumer protection. And they gave an explanation that supported that theory. At least with our recurring donors.

        “We had to contact each [monthly donor] individually, by letter, follow up by phone, follow up again by    letter. Long and short, we lost about 20% our sustainers, although since then we have recouped many. Lesson learned, before switching CRM, do your homework, and plan for every difficulty.”

RESPONSE:  Wow. Another throw-compliance-at-the-organization-and-see-if-it-fights-back excuse.  GDPR allows for you to revise your privacy terms and allow those affected to opt-in to any changes to those terms.  PCI could be used as the umbrella for revising those terms and ensuring that no PII (Personally Identifiable Information) is actually transferring hands since the processor technically should never have access to any unencrypted PII.

7. COMMENT: “We previously worked with XXXXXX for our gift processing. They said they were unable to share the information because of PCI compliance.”

RESPONSE:  Sharing is not what this is about.  Transferring tokenized cards does not imply nor require any “sharing” of information of any use to anyone but the donor. Also See #4 above.

8. COMMENT: “In a past role, the specter of PCI got thrown around a lot–regardless of the fact that we would be moving to another PCI-compliant system.” 

RESPONSE:  Invoking the mysteries of “PCI Compliance” is an all-too-common technique to confuse, baffle and block what is usually a simple, low cost transfer.  Alsosee #4 above.

What’s Next?

Hopefully, the comments and responses above will prove helpful to some folks facing a change of vendors.  And if you haven’t yet completed the Survey I urge you to do so — and please share it with colleagues in other organizations.

In the next post we’ll outline some practices every organization should follow when it comes to selecting CRM and Payment Processing providers to avoid data transfer problems when the time comes to switch.

Roger