Ubercart

In fact, payment method info is also ignored when called on form submission. That is, when pressing the "review order" button. So this is not an omission in the javascript part of this module, but a lack of "cooperation" between the shipping quote and payment method module.

What I, and many others, are looking for, is a way to exclude combinations of shipping quotes and payment methods. Depending on the order of the panes on the cart/checkout form this should be definable in the shipping quotes module or in in the payment method module.

Consequences:

For the shipping quotes module:
- include payment method in the data passed to the "calculate shipping quote ..." actions
- include this info thus also in the ajax call(s) issued form the uc_quote.js script
- ... ???

For the payment method pack:
- define and implement a system to enable or disable certain payment methods based on order information. Most easy, for us the users of ubercart, would be a system based on conditional actions like shipping quote has.

Alternative:
(Probably) Easier to implement, but less user friendly for the visitors of the store, would be a trigger that would be fired on cart checkout review, thus not on checkout completion, as that is too late.

(note: I'm using a translated version of Ubercart, so I may have translated some terms /modules incorrectly back to English)

fietserwin, thanks for your reply.
All I needed was just a confirmation that I hadn't missed or misunderstood anything about that.

So it appeared to be quite simple

details["payment_method"] = $('input[name*=payment_method]:checked').val(); (uc_quote.js, function quoteCallback(), inserted after line 78)

$fake_order->payment_method = $_POST['payment_method'];(uc_quote_pages.inc, function uc_quote_request_quotes(), inserted after line 48)

that's all!
conditional actions now aware of currently selected payment method. I didn't tested this thoroughly, but to my situation it works like a charm, and I see no reason why it shouldn't. (Sorry, I cannot provide patch for the moment)

One more thing left to do in uc_qoute.js is to add handler to payment method selection form to automatically recalculate shipping quotes when payment method changes.

Main problem here is the fact that it's a HACK. Alternatively one can recreate checkout shipping pane with an additional module by copying and modifying corresponding code the way mentioned above. But that's no good too. Any suggestions?

A few optimisations:

- To minimise dependencies between modules, don't have the quote module assume that the payment module always selects a payment method by default
- Have the quote options recalculated when the user selects a payment method

This leads to the following changes. Changes are to the existing code, thus repeating the changes from sleamey as far as they were left unchanged. Changes include the way I tend to comment patches. Changes are additions only, add the lines to the function where you like, as far as variables used are initialized/created and before the information you add is used.

uc_quote.js function setQuoteCallbacks():

uc_quote.js function quoteCallback():

uc_quote_pages.inc function uc_quote_request_quotes():

As shipping quotes now depends on the selected payment method it is probably better to arrange the payment method pane before the shipping quote pane. But this will lead to information display changes higher on the page (Order total might change as you select a shipping method, but order total is presented above the selection). So it is probably still not optimal, but to keep the changes easy, this will do.

You guys saved me. I was looking for a problem and solution for a couple of hours and haven't even found it in this long thread:

http://www.ubercart.org/comment/45550

I bet some of their problems are due to this bug.

Validations are absolutely necessary, thanks for pointing this out, fietserwin!
Obviously, I ended up with similar code on the next day, but unfortunately I've been totally screwed up with with my main job, unrelated to web development.

@philipz: Great to hear we helped someone!

OMG, guys! What are you doing?

Excuse me, please, but I think that getting shipping quote based on the selected payment method is maybe one of the most common things in e-commerce solutions. How is it possible that this does not work? Do you test the modules before you deploy them? There is even a condition for that in CA (Check the payment method) and it does not work.

Don't take me wrong, I am not angry or anything. I respect your work, but this sort of issue? It is really surprising.

Can someone promise this fix is going to be part of the next release so I do not need to patch the code again?

Thanks a lot and thanks for the patch as well guys!

First off "You Guys" is everybody.. there isnt a "team" that does this, or is responsible for this.
Second.. I have *never* purchased something online and had a different shipping quote based on the shipping method.. so this being something "urgent" is debateable.. whats the use case? In what scenario does how I pay for a purchase impact how much it costs to ship somewhere? It sounds really edge case to me, but then again, I deal primarily with stuff that doesnt ship.

And *finally* if you are going to submit issues and patches and bugs to core ubercart, posting this here, under
Home » Projects » Ubercart Contributed Modules » Ubercart Contributions » Issues is probably not going to go anywhere.

You should probably re-post your issue on the actual ubercart issue queue.

http://drupal.org/project/issues/ubercart

[Note: this is based on my experience with the European consumer market, USA market may be completely different]

The use case is simple:

• banks charge for payments,
• but the commission depends on the payment method: credit card payments are much more expensive then bank transfers
• e.g. on-line bank transfers are close to free
• credit cards payments are much more open to fraud than bank transfers and the transaction may be disputed afterwards. You loose your money.
• payment on delivery (COD) (paying to the postman) costs you a staggering €17 + percentage (in the Netherlands)

So what does this have to do with charges for shipping method? Simple: customers are not willing to pay for being able to pay. So, charging the payment method is difficult, few people will shop with you. On the contrary, charging the shipment is accepted and people even understand that different shipment methods have different costs.

So shops try to persuade people into paying the way that is the cheapest for the store by playing around with the charges for the shipping methods offered. The attached image shows a banner telling people that shipping will be free if they pay with iDEAL (iDEAL: people are redirected to their Dutch on-line banking system where they can validate a bank transfer with all payment details already filled in. Easy, fast, cheap and secure, also for the shop)

And then some very straight forward use cases where payment and shipping methods are directly linked to each other:
- In the Netherlands exists a payment method "betalen onder rembours", comparable to COD, but I'm not sure if the details are the same. Paying this way implies a shipment method that is handled via TNT, the organisation that offers this payment method. So there is a direct link between the chosen payment method and shipment method (and this link is bi-directional). Thus whatever choice comes first determines the available options of the other.
- Paying in cash on pickup is also a case where shipment method (in store pickup) is directly linked to the "shipment" method (pickup).

Having said all this: charging credit card payments is not uncommon in Europe, but the payment module does not allow for charges based on payment method, so maybe we are circumventing (yet) another omission in Ubercart. Conclusion: my observations from #1 still hold: both payment and shipment module needs improvement in this area.

@Mixologic: each and every condition built into Ubercart is edge case: only a small number of shops will use some given built-in functionality. E.g., I have never seen a shipment methods that calculates its costs per kg interval, its always in different intervals (e.g. 0-500gr, 500gr - 2kg, 2kg - 5kg, 5-10, 10-20, etc), yet that "edge case" is implemented and readily available while the "normal" weight interval based shipping costs method costs you some good 1 to 2 hours of setup of conditonal actions...

Moreover, when even the color of the product is available to you to calculate available shipping methods and their costs, I don't see why payment information should be left out of the order when the conditional actions are executed.

@Mixologic: I will "move" the issue by creating 2 new issues on the main ubercart issues queue (one for pamyent, one for shipment). Thanks for pointing out.

Hi Mixologic,

there must be someone who deployed the last release, right? And someone who didn't test it properly.

I do not know where you live, but simple case:

Typical example is Cash on Delivery. Local Mail delivery companies offer this as a paid services on tthe top of the delivery itself so if customer choose this method of payment we have to build the shipping quote as a price for the delivery + price for the COD service.

If the customer uses Credit Card payment method, we only charge him for the delivery.

Also - we want to use different delivery company for COD than for non-COD payments. The prices of these differ, of course.

I will re-post my issue, thanks for pointing out.

Oh, and one more thing: I have applied the patch in #4 and it works correctly - what do we need to do to make sure this is going to be included to the next release?

Issue transferred (and split) to Ubercart issue queue on drupal.org:

- http://drupal.org/node/982194: Payment method information should be available when conditional actions are executed
- http://drupal.org/node/982218: Allow for charges on payment methods
- http://drupal.org/node/982232: Allow to enable/disable/charge payment methods based on order information

Right on.. thanks for posting these explanations.. It really helps to have an understanding of the why and how of what people need.

I agree 100%, though saying stuff like "most common things in e-commerce solutions" isnt really helpful.. understanding what all the edge cases are, and being able to identify a pattern amongst all those edge cases allows for developers to be able to alter what was originally implemented as a US centric solution to fit more and more cases. COD is virtually non-existant in the US, especially for ecommerce, so without a thorough explanation of why this is necessary it seems like a total edge case to me. Additionally charging extra if somebody uses a credit card, for example, violates almost all merchant service agreements. Clearly this isnt the case in the Netherlands, and they've moved even further into direct bank transfers (which would be awesome if we had that here in the us, but electronic checks are as close as we got).

and @petiar: yes, there are maintainers who take community reviewed patches, and apply them to the project. And they test those patches, and make sure that everything works the way its supposed to. But assuming that testing is going to somehow reveal functionality that isnt implementented and to date hasnt been important enough for anybody else using ubercart to ask for or implement themselves.. well.. thats what makes me think this is edge case.

If you want to make sure this patch gets committed, First roll a proper patch against the dev version. I.e. Make a patch file. This allows other people (specifically the maintainers) to properly review its impact and add it to the codebase. Asking folks to 'just change these lines' and test it out is extra work that most people are going to avoid since they dont have a vested interest in making the feature happen in the first place, a patch is the best way to move it forward.

Second, create an issue with this specific patch attached to the issue (its not enough to simply link back here and say 'hey, go read a ton of posts to figure out what we're trying to accomplish"). Once you have a patch attached to the issue, explaining what the patch fixes and why its important - you then mark it as "needs review" which basically means " there is a code change that we think will benefit the project" - Then, project maintainers will take interest, examine the patch, verifiy that not only does it fix what you want but more importantly, that it doesnt break a bunch of other features. Finally, it also gives the maintainers a chance to evaulate and assess the intent of the patch, as there may be other patches attempting to fix something similiar, and there may be a better solution that works for more people by combining stuff together and rewriting various patches.

Anyhow, that'll help move this forward if its important to you.

You are right, thank for pointing out some procedures regarding the way the Drupal community handles patches. I'm relatively new to Drupal, and though I have already posted some patches, it is still unclear to if, how and when these requests are going to make it into a new version.

It is probably those merchant service agreements that make shops play with the shipping costs instead of charging payment methods. That said, some (very) big companies charge you for using your credit card like, e.g., Easyjet, the largest European low-cost airline.

#4 works .but i could not add other condition .for eg: i want two shipping method ,if cod is pickup free shipping is available other one is order total>=$65.00 free shipping is available. after i changed the js payment method is working but order total is not working .how to work on both conditions