Do not enable core payment processor types that we believe likely don't work on new installs

[eileenmcnaughton]

…

Overview

There are a bunch of payment processors that ship with core for historical reasons that we feel somewhat uncomfortable about. We suspect most don't work any more and don't know how to support them if they do. We are now seeing
regular test fails on enotices on some & I think disabling them on new installs is a reasonable approach.

Before

Following payment processor types (that likely don't work) enabled on new installs

• Realex
• Elavon
• PaymentExpress (Omnipay has the recommended version, supports recurring)
• Eway (Agileware extension recommended)
• Firstdata - I'm pretty sure this doesn't work
• Payjunction
• Payflow Pro

After

Above disabled on new installs

Technical Details

We could go further & disable them on existing installs with no active instances (I thought we already had for eWay) but
I think that can be a follow up

Comments

I know I wrote some of these - none would be less than 8 years old which is a long time for a payment processor to go untouched

@lcdservices & @Stoob may have used some of the more obscure ones & be able to say if they work but I'm still fairly comfortable reducing their visibility since we can't support them even if they technically work

@colemanw @seamuslee001

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[lcdservices]

I have a client using FirstData. But I believe I had to make one modification for it to work in current core. The library we use for it in core is quite old, and last I checked, there's no updated version available.

When you say we would disable them -- how would that be done? As far as I'm aware, none of these are extensions, so they cannot simply be disabled. Actually... I see the civicrm_payment_processor_type table has an is_active column, so presumably it would be handled there.

I agree in principle, but I think we should make sure there's some visibility to let people know that other processor integration code is available -- though not actively supported by core. Maybe a message on the top of the payment processor page to that extent? That might encourage others to update the code and get it back to a supportable state.

[eileenmcnaughton]

@lcdservices yes - just changing is_active on new installs. Regarding letting people know other processor integration code is available - ideally we would point them towards extensions

[mattwire]

@eileenmcnaughton Please see #16601 for a follow up for authorize.net