Have a Test Payment part of the Core [#814732]

Hi guys,

I wrote a little module, UC Test Payment, that lets me, and people assigned a specific set of roles (there is a permission for that purpose,) access the Test payment method. This method let you debug your other development features without having to turn off your website and setup the CC Test gateway or some other method that you would not otherwise offer. In other words, it can securely be used on a live website! (because of that permission support)

One strong point is that this module is made accessible only to a few select. All payment method should have such a permission (I think), but that's beyond what I'm posting this here for.

My question is: would you be willing to get this module as a payment method part of Übercart Core? If so, I can make it work for 7.x-3.x-dev and voilà (maybe you'd have to give me CVS access, he! he!)

Thank you.
Alexis Wilke

Comments

Comment #1

Andy_Lowe commented 1 June 2010 at 19:00

I agree a permissions system for payment methods would be nice. I'm open to including this in core assuming Lyle approves. If you plan on continued general Ubercart development, we can discuss CVS access, but for just this module, patches are probably the way to go, imho.
--Andy

Comment #2

AlexisWilke commented 1 June 2010 at 23:33

Andy,

I would not mind to correct the numerous E_ALL notices in the 6.x version. If that is good enough to get CVS access, then that could be something you assign to me. I'd also need to learn about your procedure. Do you always post a patch first, etc.

Otherwise, I could be the one responsible for that specific package (the Test Payment package) and I could look into adding Role checks for all payment methods (with a better way than the Test Payment which is very specific to that package!)

Thank you.
Alexis

Comment #3

Island Usurper commented 2 June 2010 at 17:13

I'm in favor of having a permission to use a specific payment method, but I don't think it needs to be restricted to just a test payment method. In some ways, the "Other" payment method fills that role already. I can also see some stores only letting trusted customers pay by check or purchase order.

I don't think it would be hard to patch uc_payment to create a permission for every payment method that's been installed on the site.I think it could even be done for 2.x, but making sure that all users have those permissions enabled during the update is a bit of trouble.

Comment #4

tr commented 2 June 2010 at 20:18

Isn't there a contribution that creates a CA for this? Then you can offer different payment method based on user role, billing address, etc. I think that would be more useful than a simple permission-based system.

Comment #5

AlexisWilke commented 3 June 2010 at 12:03

TR,

You've got to start somewhere... 8-) But I like the idea. I have seen credit card processors that only work in the US. So a user who were to see that choice from another country would get his card refused... not good. But with the one page cart, you have a problem because the payment choices are offered at the same time as the user is to enter his information.

Speaking of that, it would be good for credit card payments to include more than one default entry. I did not try 3.x, but that's quite a limit on 2.x. Because that way I could use both, my live payment option and the Credit Card Test Gateway and that would mostly solve my problem.

Island Usurper,

I tried the Other choice and it did not work. But a user may already be using Other as a "standard" mean of payment on his/her website. Also, you cannot choose the outcome of the payment (and long term, many other statuses) and that makes the Test Payment feature a lot more attractive to me.

Thinking of it, the fact that Other did not appear was probably because I had the Recurring system running and Other may not be defined in there and thus it would be removed from the cart.

Tank you.
Alexis

Comment #6

tr commented 3 June 2010 at 07:24

You've got to start somewhere...

Sure, I'm not questioning the usefulness of your module. Just wondering what functionality we want in core and what should be left in contributed modules.