<p>A shipping address needs a First Name (<code>firstName</code>) and Last Name (<code>lastName</code>) as they are required fields - This is why your cart won't update. You will also run into issues if you write any <a href="https://craftcms.stackexchange.com/questions/15897/craft-commerce-validation-on-address-fields">address validation</a> for use during the checkout process.</p>

<p>For these reasons it isn't advisable to set fields on an order's address for a customer. It is perhaps a better idea to list your shipping methods and costs manually somewhere on your site or your product pages.</p>

<p>A final solution - <a href="https://craftcommerce.com/docs/adjusters" rel="nofollow noreferrer">An adjuster</a> could be written that adds a base shipping cost to an order without the need for a shipping address. There would be a lot of things to consider whilst implementing something like that though.</p>

CC BY-SA 3.0
2016-09-22T10:24:23.467Z
Is there no way to even set a default country of the commerce/site so at least a fallback shipping can be displayed?
Terry Upton
CC BY-SA 3.0
2016-09-22T11:12:57.660Z
There isn't - the only "default" is the store's currency.
Luke Pearce
CC BY-SA 4.0
2019-11-18T10:32:20.980Z
Did this change with Craft Commerce 2.2?
outline4
CC BY-SA 3.0
2016-09-22T08:48:59.830Z
2016-09-22T09:24:42.793Z
2017-04-13T12:50:59.930Z
Luke Pearce
<p>I've also been struggling with this a lot. I get why you have to have an address defined in order to process the shipping rules, but the lack of defaults is maddening.</p>

<p>My client's checkout process is very lean - ideally one page. There are no user accounts, no shipping method choice (it's enforced by cart contents and address) and no payment method choice.</p>

<p>It's a challenge to get Commerce to work that way without submitting hidden form fields etc. It was also important to me to show at least an informed estimate of shipping on the cart page (I fear abandoned carts otherwise).</p>

<p>I've explored similar options to Jeremy but in my case I found using an Adjuster by far the easier path (at least for solving shipping cost display).</p>

<p>My adjuster closely resembles the <a href="https://craftcommerce.com/docs/adjusters#example" rel="nofollow noreferrer">example from the docs</a>. It simply iterates the cart contents and adds to <code>$order-&gt;baseShippingCost</code> based on my default country rules. (This is custom code shared with my Shipping Rules). The adjuster takes no action if <code>$order-&gt;getShippingAddress()</code> returns a value.</p>

<p>In my cart template I then have a <code>{% if cart.shippingAddress %}</code> conditional and if it doesn't I present the <code>cart.totalShippingCost</code> as an estimate. This works really nicely and I hope will prevent any nasty surprises for customers just before payment.</p>

<p>The other problems to solve related to this were auto-completion of <code>shippingMethod</code> and <code>paymentMethod</code>. I've done this using the <code>onSaveOrder</code> event to set the values if they are empty. You just need to watch this event as it can get into an infinite loop if you don't follow the "out-the-box" Craft checkout process (i.e. set loads of stuff at once).</p>

CC BY-SA 3.0
2016-11-24T14:03:45.480Z
2016-11-24T14:03:45.480Z
Darren Miller
<p>I agree with the basic underlying premise that showing full cost - i.e. with shipping - is essential on the cart index page for a modern checkout.  Customers loathe what they see as a hidden surprise if they hit shipping costs later in the process and your completion rate plummets in my experience.</p>

<p>Luke's answer is right about the root cause of the issue - Commerce currently requires a customer with a valid 'address' before you can set shipping on the cart, and a 'valid address' is (out of the box) at least a <code>firstName</code> and a <code>lastName</code> .  You can definitely throw a countryId in a hidden field as a default, but only in addition to setting the address details.</p>

<p>This has become without doubt my <em>least</em> favourite thing about Commerce as it currently stands, and I have spent WAY more time on solving this problem than anything else in Commerce.  To be fair I really should have discussed this a lot more with Luke (Holder, not Pearce above!) - as I really think this needs to be solved (by Commerce) sooner rather than later for a sophisticated checkout flow to be achievable without too much hassle.  But at a certain point I was too far along to contemplate going back to scratch with it (as I will have to once a proper fix comes I guess!).  So I've hacked away at it and have it all working pretty well.</p>

<p>So what ARE your options (I've tried all three, and none of them are great):</p>

<p>From easiest to hardest:</p>

<ol>
<li><p>Create a fake 'address' for your customer (I used Mr. Shipping Quote for this) - i.e. set firstName Shipping, lastName Quote, and have a select for your countries I guess -> so that you can then use standard methods to set shipping on the cart, and then on your shipping page basically update this with the actual details when you get them</p></li>
<li><p>(as per Luke above) - Write an adjuster to add this shipping until such a point as you do get an address, then once you do make the adjuster adjsut to $0...as you'll then have shipping set on the cart appropriately 'for real'</p></li>
<li><p>(And this is what we do on imagescience.com.au for a variety of reasons) - write a shipping plugin of your own and ALSO give this an option of being called by controller separate to all the regular shipping stuff in Commerce- so that you can then do a bit of fancy JS on the front end to add the result of the controller to the cart totals on your cart page.  That is, fake it totally until late in your checkout when you really do have an address.</p></li>
</ol>

<p>Of these, I think option 1 is about as far as you want to hack in most situations.  Depending on your checkout flow, and how fancy you want to get with address handling/customer address libraries, this can potentially be a relatively simple fix for the issue.  It works for basic scenarios, you basically just need, on your address input form, to test for the Shipping Quote values for those fields and if those are set, display blank fields for user input.  </p>

<p>Option 2 was where I started and could also work, but it gets fairly fiddly fast and it seems a shame to just abandon all of Commerce's shipping stuff - seemed more future proof to not do it this way, to me.  But in retrospect I'm not sure about that, this may have proved easier than option 3 in the end...</p>

<p>Option 3 is actually diabolical to get right.  But, it can solve pretty much all the problems.  However, there are MANY complications with it because if you allow a flow back and forth between your cart/shipping/payment pages, there are a bunch of scenarios that arise to do with the possibility that the cart MAY or MAY NOT not have shipping on it, and/or DOES/DOES NOT have coupons, discounts applied - to make it work consistently you have to do stuff like manually summing the lineItem totals etc.  It works, but it's a right mess if you want a really flexible checkout flow - and it's a lot more complicated than it initially looks.  Add to that address handling such as deleting addresses, adding new ones for billing/shipping etc along the way, and you'll end up writing well more JS than you like (well, I have).  Whilst I have it working, I honestly can't recommend it as an approach.</p>

<p>In retrospect, I wish I had persisted with option 1 as an approach for longer, although it soon gets complicated by the same issues as option 3 really, if you allow back and forth flow between your cart pages (and how can you not?).</p>

<p>(Oh, and shipping currently doesn't deal with tax, which further complicated getting your totals/tax right with these approaches)</p>

<p>To really solve this area I'd love to see:</p>

<ul>
<li>(The biggie!) Set shipping on the cart without requiring irrelevant
data at that point like names - shipping should only need what it
actually needs for each shipping option (including custom plugins).  </li>
<li>Some basic address controllers - that are separate from the cart - add/remove (and addresses should be elements with fields etc!)</li>
<li>Tax support with shipping</li>
</ul>

<p>I wish I could give you a 'this is how you do it' answer but it's really pretty complicated and far from ideal at this point.  If you CAN live without shipping being shown in the cart (and just use e.g. a chart as Luke suggests) - your life will be vastly simpler, that's for sure!</p>

CC BY-SA 3.0
2016-09-22T12:05:30.090Z
Thanks for this @jeremydaalder - a great answer and has answered my fears. Having played with this last night I took it as far as option 1 you had described but I stopped in case I was heading down a wrong avenue and ending up with hack that would actually cause more issues in the future.
Terry Upton
CC BY-SA 3.0
2016-09-22T12:05:37.953Z
The gripe I had with this approach is as you mentioned having to set an email address, first name and surname. I have done this with hidden fields and dummy for the purpose of changing/updating the countryID and getting the shipping. My problems then start when i proceed onto the login/guest checkout page and then subsequent address fields, as it is using this dummy data as already set.
Terry Upton
CC BY-SA 3.0
2016-09-22T12:05:40.413Z
I wonder if there was a way to unset/nullify (make null) these details once you move onto the checkout process, so you essentially wipe out the name, surname and email you set with dummy data. So far I have been unable to work this out. If anyone has any ideas?
Terry Upton
CC BY-SA 3.0
2016-09-22T12:20:07.047Z
Well you can use js to hide the dummy data and overwrite with the real data as you proceed...
Jeremy Daalder
CC BY-SA 3.0
2017-05-29T16:37:04.583Z
Hi jeremy... Thanks for this great answer... It's a shame that this still is not possible... I've tried option one and it somehow works. I've added:     name="shippingAddress[firstName]", name="shippingAddress[lastName]", 
name="shippingAddress[email]", name="shippingAddress[countryId]" and 
name="shippingMethod".
It adds the content to the cart, but it does not redirect to the cart. It stays on the same page... There's no error message... Did you ran in this problem as well? Cheers Stefan
outline4
CC BY-SA 3.0
2017-05-31T00:38:43.040Z
I've added the following and it seems to work out pretty nicely:      <input type="hidden" name="shippingAddressId" value="new">
 <input type="hidden" name="shippingAddress[firstName]" value="First Name" /> <input type="hidden" name="shippingAddress[lastName]" value="Last Name" />
<input type="hidden" name="shippingAddress[countryId]" value="XX" />
<input type="hidden" name="sameAddress" value="1"> <input type="hidden" name="shippingMethod" value="SHORTNAME" />
outline4
CC BY-SA 3.0
2017-05-31T02:29:33.813Z
Sorry, did not see your comment previously but glad you have it working.  (Best to open a new question if you have one rather than pop it in a comment though :) )
Jeremy Daalder
CC BY-SA 3.0
2016-09-22T11:20:54.740Z
2016-09-22T11:20:54.740Z
Jeremy Daalder
<p>I want to set the default <code>countryId</code> and a default shipping method (there is only one shipping method but contain several rules), so that the cart screen shows this and we can then present a shipping cost. I then want to build a facility for the customer to change their country on the cart screen so that they can update their country to see the new shipping costs.</p>

<p>Any ideas how to approach this?</p>

<p>If I pass in the following;</p>

<pre><code>&lt;input type="hidden" name="shippingAddress[countryId]" value="77"&gt;
&lt;input type="hidden" name="shippingMethod" value="standard"&gt;
</code></pre>

<p>on the product/add to cart screen then the flash messages shows;</p>

<blockquote>
  <p>ERROR! CART NOT COMPLETELY UPDATED.</p>
</blockquote>

<p>And whilst it sets the <code>shippingAddress[countryId]</code> on that product page (I checked for it) when I navigate to the cart screen the <code>shippingAddress[countryId]</code> is then not set at all.</p>

<plugin-craftcommerce><shipping>
Setting Shipping Country and Method for the Cart screen
# Setting Shipping Country and Method for the Cart screen

(Asked by: username_0 on 2016-09-21)

I want to set the default countryId and a default shipping method (there is only one shipping method but contain several rules), so that the cart screen shows this and we can then present a shipping cost. I then want to build a facility for the customer to change their country on the cart screen so that they can update their country to see the new shipping costs.
Any ideas how to approach this?
If I pass in the following;



on the product/add to cart screen then the flash messages shows;

ERROR! CART NOT COMPLETELY UPDATED.

And whilst it sets the shippingAddress[countryId] on that product page (I checked for it) when I navigate to the cart screen the shippingAddress[countryId] is then not set at all.

**Tags:** plugin-craftcommerce, shipping

---

## 3 answers

### Answer by username_4 on 2016-09-22. Score: 6 | Accepted answer

I agree with the basic underlying premise that showing full cost - i.e. with shipping - is essential on the cart index page for a modern checkout. Customers loathe what they see as a hidden surprise if they hit shipping costs later in the process and your completion rate plummets in my experience.

Luke's answer is right about the root cause of the issue - Commerce currently requires a customer with a valid 'address' before you can set shipping on the cart, and a 'valid address' is (out of the box) at least a `firstName` and a `lastName` . You can definitely throw a countryId in a hidden field as a default, but only in addition to setting the address details.

This has become without doubt my *least* favourite thing about Commerce as it currently stands, and I have spent WAY more time on solving this problem than anything else in Commerce. To be fair I really should have discussed this a lot more with Luke (Holder, not Pearce above!) - as I really think this needs to be solved (by Commerce) sooner rather than later for a sophisticated checkout flow to be achievable without too much hassle. But at a certain point I was too far along to contemplate going back to scratch with it (as I will have to once a proper fix comes I guess!). So I've hacked away at it and have it all working pretty well.

So what ARE your options (I've tried all three, and none of them are great):

From easiest to hardest:

1. Create a fake 'address' for your customer (I used Mr. Shipping Quote for this) - i.e. set firstName Shipping, lastName Quote, and have a select for your countries I guess -> so that you can then use standard methods to set shipping on the cart, and then on your shipping page basically update this with the actual details when you get them
2. (as per Luke above) - Write an adjuster to add this shipping until such a point as you do get an address, then once you do make the adjuster adjsut to $0...as you'll then have shipping set on the cart appropriately 'for real'
3. (And this is what we do on imagescience.com.au for a variety of reasons) - write a shipping plugin of your own and ALSO give this an option of being called by controller separate to all the regular shipping stuff in Commerce- so that you can then do a bit of fancy JS on the front end to add the result of the controller to the cart totals on your cart page. That is, fake it totally until late in your checkout when you really do have an address.

Of these, I think option 1 is about as far as you want to hack in most situations. Depending on your checkout flow, and how fancy you want to get with address handling/customer address libraries, this can potentially be a relatively simple fix for the issue. It works for basic scenarios, you basically just need, on your address input form, to test for the Shipping Quote values for those fields and if those are set, display blank fields for user input.

Option 2 was where I started and could also work, but it gets fairly fiddly fast and it seems a shame to just abandon all of Commerce's shipping stuff - seemed more future proof to not do it this way, to me. But in retrospect I'm not sure about that, this may have proved easier than option 3 in the end...

Option 3 is actually diabolical to get right. But, it can solve pretty much all the problems. However, there are MANY complications with it because if you allow a flow back and forth between your cart/shipping/payment pages, there are a bunch of scenarios that arise to do with the possibility that the cart MAY or MAY NOT not have shipping on it, and/or DOES/DOES NOT have coupons, discounts applied - to make it work consistently you have to do stuff like manually summing the lineItem totals etc. It works, but it's a right mess if you want a really flexible checkout flow - and it's a lot more complicated than it initially looks. Add to that address handling such as deleting addresses, adding new ones for billing/shipping etc along the way, and you'll end up writing well more JS than you like (well, I have). Whilst I have it working, I honestly can't recommend it as an approach.

In retrospect, I wish I had persisted with option 1 as an approach for longer, although it soon gets complicated by the same issues as option 3 really, if you allow back and forth flow between your cart pages (and how can you not?).

(Oh, and shipping currently doesn't deal with tax, which further complicated getting your totals/tax right with these approaches)

To really solve this area I'd love to see:

* (The biggie!) Set shipping on the cart without requiring irrelevant
  data at that point like names - shipping should only need what it
  actually needs for each shipping option (including custom plugins).
* Some basic address controllers - that are separate from the cart - add/remove (and addresses should be elements with fields etc!)
* Tax support with shipping

I wish I could give you a 'this is how you do it' answer but it's really pretty complicated and far from ideal at this point. If you CAN live without shipping being shown in the cart (and just use e.g. a chart as Luke suggests) - your life will be vastly simpler, that's for sure!

> **Comments:**
> **username_0**: Thanks for this @jeremydaalder - a great answer and has answered my fears. Having played with this last night I took it as far as option 1 you had described but I stopped in case I was heading down a wrong avenue and ending up with hack that would actually cause more issues in the future.  
> **username_0**: The gripe I had with this approach is as you mentioned having to set an email address, first name and surname. I have done this with hidden fields and dummy for the purpose of changing/updating the countryID and getting the shipping. My problems then start when i proceed onto the login/guest checkout page and then subsequent address fields, as it is using this dummy data as already set.  
> **username_0**: I wonder if there was a way to unset/nullify (make null) these details once you move onto the checkout process, so you essentially wipe out the name, surname and email you set with dummy data. So far I have been unable to work this out. If anyone has any ideas?  
> **username_4**: Well you can use js to hide the dummy data and overwrite with the real data as you proceed...  
> **username_2**: Hi jeremy... Thanks for this great answer... It's a shame that this still is not possible... I've tried option one and it somehow works. I've added:     name="shippingAddress[firstName]", name="shippingAddress[lastName]",  name="shippingAddress[email]", name="shippingAddress[countryId]" and  name="shippingMethod". It adds the content to the cart, but it does not redirect to the cart. It stays on the same page... There's no error message... Did you ran in this problem as well? Cheers Stefan  
> **username_2**: I've added the following and it seems to work out pretty nicely:      <input type="hidden" name="shippingAddressId" value="new">  <input type="hidden" name="shippingAddress[firstName]" value="First Name" /> <input type="hidden" name="shippingAddress[lastName]" value="Last Name" /> <input type="hidden" name="shippingAddress[countryId]" value="XX" /> <input type="hidden" name="sameAddress" value="1"> <input type="hidden" name="shippingMethod" value="SHORTNAME" />  
> **username_4**: Sorry, did not see your comment previously but glad you have it working.  (Best to open a new question if you have one rather than pop it in a comment though :) )  

---

### Answer by username_1 on 2016-09-22. Score: 1

A shipping address needs a First Name (`firstName`) and Last Name (`lastName`) as they are required fields - This is why your cart won't update. You will also run into issues if you write any [address validation](https://craftcms.stackexchange.com/questions/15897/craft-commerce-validation-on-address-fields) for use during the checkout process.

For these reasons it isn't advisable to set fields on an order's address for a customer. It is perhaps a better idea to list your shipping methods and costs manually somewhere on your site or your product pages.

A final solution - [An adjuster](https://craftcommerce.com/docs/adjusters) could be written that adds a base shipping cost to an order without the need for a shipping address. There would be a lot of things to consider whilst implementing something like that though.

> **Comments:**
> **username_0**: Is there no way to even set a default country of the commerce/site so at least a fallback shipping can be displayed?  
> **username_1**: There isn't - the only "default" is the store's currency.  
> **username_2**: Did this change with Craft Commerce 2.2?  

---

### Answer by username_3 on 2016-11-24. Score: 1

I've also been struggling with this a lot. I get why you have to have an address defined in order to process the shipping rules, but the lack of defaults is maddening.

My client's checkout process is very lean - ideally one page. There are no user accounts, no shipping method choice (it's enforced by cart contents and address) and no payment method choice.

It's a challenge to get Commerce to work that way without submitting hidden form fields etc. It was also important to me to show at least an informed estimate of shipping on the cart page (I fear abandoned carts otherwise).

I've explored similar options to Jeremy but in my case I found using an Adjuster by far the easier path (at least for solving shipping cost display).

My adjuster closely resembles the [example from the docs](https://craftcommerce.com/docs/adjusters#example). It simply iterates the cart contents and adds to `$order->baseShippingCost` based on my default country rules. (This is custom code shared with my Shipping Rules). The adjuster takes no action if `$order->getShippingAddress()` returns a value.

In my cart template I then have a `{% if cart.shippingAddress %}` conditional and if it doesn't I present the `cart.totalShippingCost` as an estimate. This works really nicely and I hope will prevent any nasty surprises for customers just before payment.

The other problems to solve related to this were auto-completion of `shippingMethod` and `paymentMethod`. I've done this using the `onSaveOrder` event to set the values if they are empty. You just need to watch this event as it can get into an infinite loop if you don't follow the "out-the-box" Craft checkout process (i.e. set loads of stuff at once).


---

