Having an "other" payment method only makes sense if you know what "other" means. I propose we allow that to be set by store administrators. The following patch accomplishes this in just a few lines of code. See the screenshots to see its effects.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

geerlingguy’s picture

Status: Active » Needs review

Patch looks fine to me - using a variable would be especially nice, since we could set that in an install profile. Since we have a patch, setting to 'needs review.'

Scott M. Sanders’s picture

Subscribing, will check soon.

Volx’s picture

Nice patch, just what I needed. Works good for me.

Aditionally I would like to be able to edit the payment instructions at checkout as well. I added this to the patch above.

Scott M. Sanders’s picture

I used Volx's patch, and it works pretty well. :) I need this functionality for one of my shops and forget to hack the core when Ubercart is updated.

One thing though: When I use HTML in the label, the settings label when collapsed just says "settings," but the label itself in checkout appears OK.

TR’s picture

I don't see the need for this. "Other" is a payment method meant for the administrator on the back-end, not for the customer. Ryan mentioned this in #388352: How to use payment pack "other" form. The use-case is for when the customer phones in an order. "Other" gives the store administrator a way to accept a non-standard payment method (e.g. "three goats"). If anything, I would suggest modifying Ubercart so that the "Other" option always shows as "disabled" at admin/store/settings/payment/edit/methods, which will prevent administrators from turning on "Other" for the checkout page but will still allow the administrator to use "Other" on the back-end.

Re-purposing the "Other" payment method to be a generic, user-configurable method doesn't make sense to me, because in general a payment method is not generic - each has its own needs as far as customer input and payment procedures. IMO if you want to allow your customers to pay via a method that is not available via an existing module, you should create your own module for that method. Encapsulating the method-specific information in a module is the best way to share it with the community and to improve on the common code base.

Specifically, the example used in the original post in this thread is to rename the "Other" payment method to be "Purchase Order". Purchase orders typically need additional information from the customer, such as PO number and customer account number (!= customer number, because not all customers will be have credit terms, and not all terms will be the same). Likewise, with purchase orders there is a need to present the credit terms and conditions to the customer upon checkout. Purchase orders are fundamentally different than cash equivalents in that legally the transaction isn't complete until the offer of payment via PO is accepted by the merchant because a PO isn't a payment from the customer, it's a merchant offering a loan of money to the customer. You *cannot* address these issues simply by renaming the "Other" payment method, and in fact there already is a purchase order module to handle this case.

Scott M. Sanders’s picture

I don't think there will ever be payment modules that exist for every payment scenario that arises, nor people that know how to create their own payment modules, hence this issue.

A payment module for each payment method may be ideal, but this option should still exist, when creating a new module for every minor use case is just not feasible.

It needn't be this difficult.

ermannob’s picture

Thanks for the patches... they helped me a lot.

Going back to discussion: I think both #5 and #6 are right.
A good solution could be a little module with some configuration that acts as a payment method. Some kind of "generic" payment method to be customized. And it should be able to set multiple entries (more than one "custom method").
I'm not sure I'm able to code that, I'm trying to give just an idea here...

YK85’s picture

subscribing

joelstein’s picture

TR: Thanks for your comments. You may not see the need for this, but I do (as well as others on this issue). The patch is small, functional, and allows site administrators the flexibility to decided what "Other" means to them, without needing to know how to create a module when one doesn't exist to meet their needs. That's why the solution works—it's simple. It only meets simple use cases. Yes, there's a PO module, but I find it overkill in my specific use case. Also, nowhere in the documentation or user interface is the "Other" payment method explained to be an administrator-only payment method. Why not let the site administrator decide how he/she wants to use it?

geerlingguy’s picture

I don't particularly need to use the 'Other' payment method on the four Ubercart sites I maintain, but I do see a use case for it (just echoing @joelstein's remarks).

univate’s picture

I support TR reservation on adding yet another setting to this module.

For two reasons:
1) Adding more settings makes the modules more complex to setup, its just another thing that admins need to try and work out what that option does.
2) Drupal already has a very good method of overriding text output from various modules, its proved by every string that has t() around it and you can use modules like string_override to edit the text through the site.

Scott M. Sanders’s picture

If it is too "complex," just leave it at defaults. This is where Ubercart and Drupal excel.

String Overrides do not work in this case, as Joel said -- the string is too general.

joelstein’s picture

univate:

Adding more settings makes the modules more complex to setup, its just another thing that admins need to try and work out what that option does.

With all due respect, I don't think that's a good argument. When are there too many settings? When are there not enough? It seems to me that the "Drupal way" is to allow more settings than less, so that site administrators can customize things without having to know how to create modules. If people want a simpler version of Drupal, they can sign up for something like http://www.buzzr.com/ (or hire a developer like me). Still, whether I'm right or wrong, I don't think the merit of this issue should be governed by an incalculable limit on the proper number of settings.

Drupal already has a very good method of overriding text output from various modules, its proved by every string that has t() around it and you can use modules like string_override to edit the text through the site.

That is true, but overriding the word "Other" is not a practical solution, especially when you think about drop-down selects which often have a last option of "Other". In our case, "other" means something very different.

In conclusion, this is a very simple solution, which actually increases the flexibility of the intentionally flexible, generic "other" payment method. If you simply don't want to do it, that's one thing. But, I believe we have some strong points in favor of this issue, and I'd like to see you respond to those.

univate’s picture

Its not that one option like this is complex on its own, its the accumulation of lots of options that is the issue. Adding options like this are not features for developers, as soon as you put it in the UI it becomes a features for end users.

I agree that the string_override module may not work that well in this case, but the point is drupal already come with a feature to override the output of strings and rather then using the variables table to store all this junk (which is something that has been mentioned in other issues) I would prefer to see ubercart try and make use of the native method for overriding text rather then use the variables table which was never intended to store site strings.

YK85’s picture

I like the idea of being able to rename "Other" payment method with ease (I'm a web designer so custom coding to change it is difficult for me).

TR’s picture

Status: Needs review » Postponed (maintainer needs more info)

I still haven't heard one use case for this. On the other hand, if "Other" were turned into a generic payment method (for which it is ill-suited, as I tried to explain with an example above), many (most?) Ubercart users would immediately turn to it when they didn't see their desired payment method (Purchase Order, Gift Card, etc.) in core Ubercart. This would be a big mistake, and something I'm not prepared to support.

A generic payment method, IMO, could be a contributed module, but it would have to have a webform-like capability to add form elements of various types to collect information from the customer and to save that information in a database table related to the order. A generic payment method is useless unless it can collect information. And of course it would have to display that information on the back-end order administration pages, invoices, etc. And be translatable, which this patch isn't. And have configurable orders statuses and Conditional Actions. "Other" doesn't meet the needs for a generic payment method, even if you could change the name.

As I said, I'm far more inclined to just disallow the use of the "Other" method on the front-end since it was never meant for that purpose.

Scott M. Sanders’s picture

My client uses Other as "Invoice Me," then sends the customer an invoice.

Scott M. Sanders’s picture

Version: 6.x-2.3 » 6.x-2.4

Just a reminder that Ubercart 2.4 is out, so if you update and still want this, you need to patch again for now.

I dunno how to make patches, but if you just copy from this patch file the + lines and remove the - lines from where the other unmarked lines are, and remove the +/-'s, it will still work w/ 2.4 and retain your former settings -- it does for me anyway.

MBroberg’s picture

My customer wants users to be able to select:
*bill me
*school purchase order
*apply credit
*scholarship fund
*will pay in installments

so we definitely need an "other" option, perhaps with "add another" features.
None of the extra payment options for my needs would require anything more than a checkbox and perhaps a textfield to put in a little more detail and send that with the order.

I can see how a separate module would make sense for this since it is not for every Drupal user, but then again there are lots of features with Ubercart that I do not use and I have to ignore those settings.

String overrides is a universal override which is not practical. I do not want every "other" string on my site to be renamed.

MBroberg’s picture

Patch in #3 works great for me. Thank you for the ability to change instructions, which is what I needed most.

univate’s picture

Its probably worth being clear that there are two issues being raised here:

1) Renaming the other payment method, so users see alternative text to "Other"
2) Provide a feature to allows administrators to define alternative other payment methods.

The first issues is a string translation issue, the second one is about adding new payment method (possibly dynamically?).

Scott M. Sanders’s picture

Another issue with patch #3 and using HTML in the payment method name, which one of my clients basically requested, is that in admin order view and edit, the HTML codes appear as plain text.

It appears OK to shoppers though.

longwave’s picture

http://drupal.org/project/uc_checkout_tweaks will let you rename this payment method (and all others), providing the same feature as the patch in the original post at least.

webservant316’s picture

subscribe.

I also need a way to add the 'invoice me' payment option and perhaps other options in the future. A patch or module that would allow the administrator to define 1 to many payment options, and specify the collection of additional information, and be properly integrated into Ubercart would be very useful to me right now.

I plan to investigate uc_checkout_tweaks for now.

one more thing, does the proposed patch above work for Ubercart 2.3?

longwave’s picture

@webmaster_prwa: I guess what would be most flexible here would be to allow webforms to be defined as payment methods, rendering the webform and storing the results when a specific method is selected. Perhaps this could be a separate module, or a feature request for http://drupal.org/project/uc_webform_pane

webservant316’s picture

I am using the proposed patch above with Ubercart 2.3. Works fine.

@longwave... integrating webforms with ubercart to accomplish this might be one solution. However, adding module dependencies like that also can complicate versioning and installation. I would instead recommend that the Ubercart developers simply add a generic payment type to their payment_pack that allows the admin to specifiy the payment name and 1-3 additional data collection fields. The new feature should also allow the admin to create 1 to many of the user defined payment types.

This couldn't be too hard to add and would handle 99% of any custom needs. And custom needs beyond that could simply hook in their own payment module.

LizD’s picture

Category: feature » support
Status: Postponed (maintainer needs more info) » Active

This is exactly what I need, However, I have never used a patch and have no idea how to install it. Searching the Drupal docs I find a lot of info about writing patches but not how to use one. Some basic instructions please? I have full ssh access.

longwave’s picture

LizD’s picture

thanks. Unfortunatley my shell says "command not found"
My server is running CentOS with the bash shell. So I guess I have to do it manually?

webservant316’s picture

yes just do it manually.
I work from a Windows workstation and just apply patched manually.
I use notepad++ to help compare the old with the new.

longwave’s picture

Status: Active » Closed (won't fix)

I don't think we can do this in a way that pleases everyone, TR's points from #5 are still valid, and uc_checkout_tweaks can at least handle the original request.

dave.hussey’s picture

Our current client would benefit from this patch where checkout tweaks is not sufficient.

Checkout tweaks renames the title "Payment Method," which would be confusing to name to Purchase Order when Credit card processing is applicable to other roles.

In this case, purchase order is appropriate to our client's needs for wholesalers, but the purchase order number has proven confusing for their wholesalers as they assume that it something that must be provided to them.

Almost resolving this issue for us, is the COD payment option, which requires no additional user input and has a nice description field that we can configure; however, COD appears as Cash on Delivery, which may also be confusing to wholesale customers where Purchase Order is more descriptive and appropriate.

So, back to where we started, either the Purchase Order should not require the input of a Purchase Order Number, or we should implement this patch so that the administrator can define exactly what 'other' pertains to making it a truly useful option, instead of a rigid, back-end, we-should-hide-this payment solution.

Thanks for the patch. We considered avoiding hacking the core at the advice of TR, but 2 minutes verse the 20 wins in this case and we renamed "Cash on delivery" to "Purchase Order."

webservant316’s picture

FYI - I am still depending on this patch an manually installing it in Ubercart 2.7.

bitsdu-1’s picture

What I miss as a payment method is Invoice, and the possibility to add a fee for it. Then point it to use the template invoice.

andrewm63au’s picture

I also would like to add at least one other payment method - bank transfer - and provide the BSB and account number and some instructions to the purchaser as to what to put as a reference.

longwave’s picture

@andrewm63au: You can use http://drupal.org/project/uc_bank_transfer for that

wodenx’s picture

Also please test http://drupal.org/project/uc_custom_payment, which allows any number of "other" methods, each of which can be configured to collect any kind of data from the customer.

webservant316’s picture

FYI - I am still depending on this patch an manually installing it in Ubercart 2.9.

kuydigital’s picture

Issue summary: View changes

Any updates on this? Subscribing.

sambathbask’s picture

Is there any Update for this Issue?