I searched the forum and online, there seems to be quite a number of requests to restrict the types of payment methods, either by
- product classes (content types)
- user roles
- or per node basis
- (... other suggestions?)

e.g.
- product class A thru paypal only, product class B thru COD only, product class C can use paypal/COD
- limit certain role to use specific payment methods
- mixture of the above?

AFAIK, the current way is to use form_alter() to manipulate the payment methods displayed. Is there other way to achieve the same thing?

CommentFileSizeAuthor
#2 437400_ca_payment_methods.patch8.42 KBIsland Usurper

Comments

rszrama’s picture

Status: Active » Postponed
Issue tags: +payment, +checkout

This does come up quite regularly but is impossible for now due to the way payment methods are constructed on the checkout form. Part of the plans for 3.x are to fully embrace the benefits of the #ahah framework for the Forms API, so we may be able to resolve this then.

Island Usurper’s picture

Assigned: Unassigned » Island Usurper
Status: Postponed » Needs review
StatusFileSize
new8.42 KB

Weeelll, impossible is kind of a strong word. ;)

Here's a patch that implements the #ahah framework on the checkout page and filters payment methods through order conditions. In addition, I think I've managed to do it without breaking anything else like shipping quotes or taxes. :P (We'll see how true that is in the testing.)

Eventually, I'd like to see all of the bells and whistles on the checkout page use #ahah, but that can certainly wait until after the 2.0 release. There's a couple of nasty hacks that are introduced because of the design of other parts of the checkout page, but I think as those are corrected, the hacks can be done away with as well.

Interestingly, I've made it so that the payment method predicates don't have actions. Like the shipping quote predicates, you can still try to add actions to them, but nothing will happen. All that the payment pane is concerned with are the conditions. (We're doing this enough that we probably ought to make it part of the API, eh?)

I think this will open the door to a lot of cool things for Ubercart, so test the heck out of this so we can get it in!

rszrama’s picture

Hotness. Tim, you owe Lyle a review. ; )

thill_’s picture

Status: Needs review » Needs work

As discussed with lyle there is an error with the cart contents not being passed.

BayerMeister’s picture

Seemed perfect for my needs at first sight. I tried it out and found out that events are fired (and conditions evaluated) only when entering checkout.

Could this be somehow used to alter the shown payment methods according to the selected shipping method? That would need these changes:
- action would be fired when changing shipping method
- there would be a condition "check the shipping method" or the shipping method would be available to custom PHP code (the condition in the actions introduced here)
- this would require some AHAH which I have no clue about, just like Ajax and other things...

hankpalan.com’s picture

subscribe...

tast’s picture

+1

mandreato’s picture

Like #5, I also would like to have a way to condition the payment method to the shipping method.
For example: avoid cash payment if the products are shipping.

kazah’s picture

subscribe...

shunshifu’s picture

subscribe

shunshifu’s picture

subscribe

longwave’s picture

Status: Needs work » Closed (fixed)
mandreato’s picture

I've resolved by adding a conditional action which triggers when customer completes checkout (trigger), with the wrong conditions (in my case on site cash payment with shipment). As actions I choose to display a message to the user, plus add a comment to the order and finally change its status to cancelled.

Yeah: it's not the best way to avoid the wrong conditions, but those occour rarely and I don't wan't to install another module.

HTH.