Switching payment processors with recurring payments

This may be interesting if you're considering a move from one payment processor to another, or migrating to CiviCRM from a proprietary CRM that provides its own payment processing (looking at you, Blackbaud).

Recurring contributions and membership payments are great. They're an important source of income for most organizations using CiviCRM. And all of CiviCRM’s most popular payment providers (Stripe, iATS, Authorize.net, PayPal Pro) support this feature.

So what happens to them when you decide you hate Authorize.net and want to switch to iATS, for example? Can you migrate recurring contributions from one payment processor to another?

Short answer is: it's not easy.

Longer answer is: it's usually possible, but you should ask yourself if it's worth the effort.

Your unique situation will dictate how you want to work through this problem, but in general terms I suggest thinking about it like this:

1. Estimate the cost of not doing it.

If you don't transfer the recurring contributions, the only way to keep them going is to convince your recurring donors to manually recreate their recurring payments after you make the switch. How much staff time will you need to make that happen? How many of your recurring donors won't bother? What impact will that have on your organization?

2. Estimate the cost of doing it.

If you've already estimated the cost of not doing it, that cost is your maximum budget for this project. You'll probably need a specialist to help you determine whether it can be done within that budget.

3. Pick whichever one of those is cheaper.

Naturally those are both estimates, so there's some unavoidable level of uncertainty. Ideally, you'd want both of those estimates to have the same level of uncertainty.

Measuring uncertainty in estimates is a topic for another time, but it can be done.

All the best,
A.

Previous
Previous

Dealing with uncertainty

Next
Next

Blending in is no longer “safe”