Split payment method pack into multiple modules

I believe this is by design. The idea is to allow the admin to manually accept payments of any installed type, even though these payment types may be disabled for on-line purchasers. For example, an admin can take an order over the telephone and enter it manually, choosing "Purchase Order" as a payment type, without enabling the Purchase Order payment method for anyone making a web order.

I don't see how this causes a problem, because it is only available to the admin.

That's a good reason.

well its good to give a manger the right to choose a payment method that is not available online, it must be an additional option and never by default.

Sounds like the right thing to do. It will probably get fixed faster if you submit a patch that makes the necessary changes.

Hmm... I used to allow you to enable / disable them for administrators as well as on checkout, but I had to change this. The reason was you would lose payment info if, for example, you had a payment method enabled on the front end that wasn't on the back end. The core example of this was PayPal Website Payments Standard. It doesn't make sense on the backend, because it requires the customer to redirect and enter their payment information then be sent back to the checkout complete page. I decided instead to just make the enable box work for checkout.

A solution to your scenario, imo, would be a simple bit of code in a custom module for the site. You can form alter options out of the payment method select box easy enough, and a site that large better have at least a small budget for custom tweaks. ; )

I suppose this sort of thing could easily be handled through a contribution as well, I'm just not sure I want to have it back in core at this point.

I believe I understand your reasoning for the post, but I guess it still doesn't address the issue that disabling a payment method on the backend that is available during checkout will result in lost data if an administrator edits/saves an order that used one of those payment methods. We populate a select list of available payment methods on the order edit screen based on the backend enabled payment methods. That's why I took out this option, and I don't know what alternative solution would be cleaner.

I think splitting up the payment method pack into multiple modules is a good idea. It is out of place, after all. As for the upgrade path, if you're willing to figure that out, that would rock. So, the way it would work is the user would disable payment method pack on D5 and then on D6 enable only the modules they were using. I suppose we might have to build the update functions into uc_store.install or something.

My hunch is that this change should take place from 2.x - 3.x. As such, I've moved it to 6.x-2.0-beta1 and marked it postponed. If we get a patch, go ahead and change it to patch (code needs review). Otherwise I'll revisit it when we start developing the 3.x branch.

+1 Having it before Drupal 7 would be good.

I understand the issue and agree that "it would be nice" to have the ability to get rid of installed payment methods that are disabled altogether (in my case, its more than just the Payment method pack; I want to only display a single Paypal option as well). I further understand the problem that is outlined in #6. Basically, it boils down to "you have to at least have the same set of payment methods available on the back-end as there are on the front-end" to prevent data loss.

I propose a different solution to this issue:

Why not create a permission "Display disabled payment methods", enabled by default for admins and disabled for all others. That way a person can decide if they just want to see the enabled ones, or if they want to see all of them. In my case, I just want to see all of the enabled ones and none of the disabled ones. I think this should make it work for both needs, no?

Sounds like a good idea. I'll see if I can come up with a patch for that.

How about two columns of checkboxes on the payment methods settings page, one for checkout and the other for admins?

That would be similar I suppose to what was available back on comment #6. I guess if you make the admin checkbox disabled-checked if the checkout checkbox is checked, all should be well. Right?

As proposed in #1321616: Payment method select element includes non-enabled methods an alternative here to two checkboxes would be a drag-drop list of payment methods split into three sections: enabled, admin only, disabled.

Moving this to 8.x-4.x.

If we convert payment methods to plugins, and they then need to be individually added/configured before they can be used, we could in fact roll them into uc_payment and drop the separate pack module.

See #2293939: Replace the payment API with Payment 8.x-2.x.

Fixed by #2620956: Convert payment methods and gateways into configuration entities. This will not be backported to 7.x-3.x.