I noticed a way that users can get around choosing a valid shipping method (and avoid paying the right amount for shipping in the meantime!):
- Configure a two-page checkout process with the Shipping Information pane and the Shipping Services pane on the first page, and some other pane (e.g., Review Order or something) on the second page. The second page should have a back button. (In my case, I have a "go back" button for the off-site payment redirect page.)
- Check the boxes for "Require a shipping service at all times, preventing checkout if none are available" and "Calculate shipping rates via AJAX as addresses are updated on the checkout form."
- Configure shipping method rules (such as flat rate) such that some shipping methods are available only for US addresses, and others are available only for, say, France addresses.
- Disable JavaScript in your browser (to prevent auto-recalculation of shipping costs).
- Begin checkout and enter a US address. Click either Continue or Recalculate Shipping such that it presents shipping options on reload.
- The US address shipping options are presented. Choose one (or leave the default one selected).
- Click Continue to go to the next page. Your order now has a US address and a US shipping service attached to it.
- Click Back to go back to the first page. Change your address to a France-based address. Note that, since JS is disabled, the shipping services pane won't be refreshed.
- Click Continue to go to the next page. Your order now has a France address but still a US shipping service attached to it.

For my site, the obvious problem here is that shipping to France is considerably more expensive than shipping within the US, so international customers who use this workaround could pay, say, $10 for shipping that will actually cost us $60. (We're using Commerce UPS to get actual rates from UPS.com's APIs.)

A possible solution would be to re-run all shipping service Rules components after submission of the first page, and ensure that the shipping service selected for the order is actually still available as per the Rules components' logic. If validation fails, the user could be sent back to the first page with an error message saying something like "Please choose a valid shipping service." And since the page would be reloaded after the France address had been entered, the correct shipping service options would be presented on reload.

The only drawback I can think of to this approach is that, in the case of Commerce UPS, for example, it will require an additional API call to UPS.com during validation, which will slow things down a little bit. Not a huge problem, but it's something to take into account.

Thoughts?

CommentFileSizeAuthor
#5 issue-2111641.patch672 bytesRalt
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

amittarkar’s picture

Priority: Normal » Critical
amittarkar’s picture

Version: 7.x-2.0 » 7.x-2.x-dev
crbostick’s picture

This would be great. Any results?

Ralt’s picture

The problem is that the shipping rates are only calculated client-side. This is a Bad Thing™.

The calculation should definitely be redone on submit of the checkout form.

Ralt’s picture

Status: Active » Needs review
FileSize
672 bytes

For the record, here is a patch that should fix the behavior.

googletorp’s picture

Assigned: Unassigned » rszrama

I'm unsure about this portion of the code, will you take a look Ryan?

rszrama’s picture

Hmm, I'll look into it. Real briefly we can respond to Ralt in #4, though - there is no client-side calculation of shipping rates. It all happens server side via Drupal's Ajax framework, and it should be updating the form appropriately. I'll bookmark the OP to research, maybe reach out to Jesse on Twitter to see if he already fixed it.

andyg5000’s picture

They can also get away with an invalid shipping method by not blurring on the last required form element (the recalculate trigger). As discussed in #1287124: Support recalculating shipping when the address is entered