The Foxy forums are on the move!

We're in the process of moving our forums over to a new system, and so these forums are now read-only.
If you have a question about your store in the meantime, please don't hesitate to reach out to us via email.

FC 2.0 checkout for gift orders

Since we updated to FC 2.0, I have been trying to figure out the best way to set up the checkout to process gift orders -- as in: an order made by a customer that is shipped to someone else as a gift. A few things to clarify up front:

1. We don't want to use multi-ship, as it seems like it would be more complicated and confusing for our purposes, and the design of our product pages would not accommodate an extra select field for this.
2. We used to process gift orders pretty easily in our store checkout with FC 0.7.2, but the information flow at checkout was different in that version, where the billing address served as the default shipping address and the option to use a different shipping address was provided. Version 2.0 has reversed this flow for some reason.
3. We use the default checkout user type of "Allow guest and customer accounts, default to account".

So what we used to do, in FC 0.7.2, was to add an optional "gift message" field to the form container that was revealed when a customer checked the box to use a different shipping address. In that context everything was pretty clear, especially for customers who used an account at checkout. The customer account flow would save the last used billing and shipping addresses, so if there was an alternate shipping address used for a previous "gift order" it would be saved too. But this wasn't a problem if on their next order a given customer didn't use an alternate shipping address, so their order would just ship to the billing address.

Now that the shipping address is displayed as the primary address in FC 2.0, the process of placing a gift order in the manner mentioned above is confusing and burdensome, especially for customers who use their account at checkout. The problem is that if they want to place a gift order and ship it to their friend/family, the address that is pre-populated when they log in to their account is the shipping address. This forces them to delete all the shipping address fields and re-enter a different address. Some customers have reported problems changing the shipping address on their accounts (the state select field being particularly troublesome for some reason). Further, assuming a customer succeeds in completing their gift order, this presents a problem later when they log in to their account the next time they order -- because the gift order address they entered last time will now be the default saved address, so they have to change their address again. On that note, I can can tell you that it's already a somewhat regular occurrence for customers to NOT notice problems with their shipping address at checkout, and I am sure that plenty of them will take for granted that everything pre-populated by their account is correct without looking at it closely and breeze through checkout with the wrong shipping address populated from their last order.

When the billing address was the default saved address on customer accounts none of these problems existed. I don't know what your rationale was for making this change, but I think it presents a significant usability problem in our use case. It would be great if there was an option in the configuration panel to choose between making the billing address or the shipping address be the default address. Or if there was a built in option to give customer accounts a place to enter an alternate shipping address on a given order that does not overwrite their default shipping address. Without options like these I'm at somewhat of a loss on how to re-add "gift order" support in a manner that is clear and uncomplicated to customers. As I said above, I do not think that multi-ship is a viable solution or alternative to the functionality I'm describing, mostly because it sets the shipping address on each item and that kind of order flow only seems truly relevant to very small minority of stores. We just want there to be easy and uncomplicated gift order support, where a customer orders any number of things that can be shipped to ONE alternate address that doesn't overwrite their default saved address.

Given the way 2.0 checkout flow is set up, the best option I have come up with so far is to try indicating to customers who wish to place a gift order that they should NOT log into their account and use guest checkout instead, so that they can enter an alternate address without overwriting their account address. This is a rather confusing process to try explaining to customers though, and it also has negative implications for tracking a customer's order history. We are developing a customer account portal, and want to make order history available to customers in a meaningful way, but presumably their guest checkout orders might not show up in the history associated with their customer account. Anyway, I would rather have a more direct way of letting customers place gift orders while still being able to use their account, and not have to worry about their default address being overwritten. I don't think that's too much to ask, and if we could just have the option of reverting to the old flow of the billing address being the default that would be fine.

This is especially important to us with the holiday sales season coming in short order. Is there anything you guys can suggest or do for us on this? Thanks for your help and consideration.
  • fc_adamfc_adam FoxyCart Team

    Thanks for providing all of those details.
    When the billing address was the default saved address on customer accounts none of these problems existed. I don't know what your rationale was for making this change, but I think it presents a significant usability problem in our use case.
    I'm sorry to hear that the change has had a negative impact for your set up. We made that change after some feedback from some of our larger stores and research available that were showing an increase in conversions when the shipping fields were displayed by default instead of the billing fields for shippable orders. There has also been a move to that approach across other ecommerce systems as well since then too. This way, for shippable products, the focus for the customer in that instance is just getting their products - so we present that as the more important aspect. If there isn't any shippable products, then we just show the billing address by default and that's all.

    I understand that you said that multiship wouldn't be possible on your add to cart page - but the requirements you described are the exact use case of multiship. Customers being able to login to their account and specify a secondary shipping address to send products to someone else that doesn't affect their usual saved shipping address. I can definitely understand that customers may not notice that their preloaded address isn't set to their usual one after changing it to ship to a friend - which is exactly why multiship exists.

    For your needs, you could possibly not include the multiship name field in your add to carts, and instead just include a checkbox for "This is a gift". If that is checked, then you could set the multiship name to be "Gift Purchase" or something else for the name - so those products are grouped into a separate multiship address. If the customer just orders gift products, then on the checkout they would see billing fields and shipping fields for "Gift Purchase" (or whatever you call it). The address entered there would in no way affect their normal saved address. If they order both, then they'll see the billing fields and shipping fields for "You" and "Gift Purchase".
    We are developing a customer account portal, and want to make order history available to customers in a meaningful way, but presumably their guest checkout orders might not show up in the history associated with their customer account.
    That's right - guest checkouts wouldn't be linked to a users account in any way.
  • @fc_adam,

    Thanks for the reply. I appreciate your suggestions for an alternative way of working with multi-ship to meet our needs, however I do still think that multi-ship is quite problematic for the following reasons:

    1. The shipto parameter must be added on each product individually.

    -- problem A: the customer may fail to notice that they have not checked this parameter on all cart items by the time they arrive at checkout, frustration ensues, increasing the potential of a lost conversion.

    -- problem B: supposing a customer orders multiple things for a gift order, this requires them to take the extra step of checking the "gift" box many times and on many different product pages, when it would be far more convenient and organized for them to check one gift box in the cart or at checkout to indicate a gift order.

    2. The shipto parameter on each item cannot be added or changed in the cart/checkout.

    -- problem C: if the customer makes a mistake and fails to check all the boxes on each product correctly, they are required to abandon their cart or checkout session and go back to the site to fix things by removing cart items and adding them back again on the relevant product pages, assuming they don't get frustrated and abandon the order altogether.

    -- problem D: the required process of adding gift options or alternate shipping options at the product page, rather than in the cart or at checkout, is a pretty serious departure from established e-commerce conventions. I honestly do not know of another non-foxycart e-commerce platform or site that does this. I just looked at a handful of product > cart >checkout flow examples on big brand e-commerce sites (Apple, Amazon, Target, Bed Bath & Beyond, Macy's, Etc.) and all of them present gift options and alternate/multiple shipping options either in the cart or at checkout. Of all the examples I've looked at, only Macy's is doing anything remotely similar to the FC multi-ship process with a new special option called "E-GIFT IT" on their clothing product pages, which is not really the same but does introduce an alternative gift ordering option at the product level; and even so, Macy's does provide the more conventional gift order options at checkout. Since the established convention is for e-commerce shoppers to set gift options and multiple addresses in the cart or at checkout, I am pretty certain that many customers will manage to miss or be confused by these options if they can only exist and be set on the product pages. After years of running our e-commerce site, I know the peril of underestimating people's capacity to miss or misunderstand things, even when they're spelled out in the most obvious ways. I can't even count how many times our support team has received messages from customers who couldn't figure out how or where to add a coupon to their order. For this reason alone, I am of the opinion that FC multi-ship (in its current form) is inherently flawed and not a particularly viable solution for its intended purpose. If in breaking with the established conventions multi-ship made the mentioned processes easier and more intuitive than what the average e-commerce customer is used to, this would all be fine... but I'm not convinced that it is anywhere near doing that. I think that not having the ability to alter these options in the cart or checkout actually makes multi-ship more difficult for the average user.

    For all the reasons above, I honestly don't think we can consider using multi-ship. What really hamstrings the whole function for us is the fact that it can only be used via an option set on the individual products, and which can only be set before the item goes into the cart. That is a serious limitation, and we won't be able to revisit the prospect of using it until such a time when you can restructure multi-ship to allow those options to be changed in the cart and/or checkout. That said, if I may have overlooked anything regarding the limitations of multi-ship, please do let me know. We would honestly like to be able to use it, but its apparent lack of flexibility/control in the cart/checkout is a deal breaker.

    I hope that the issues I've mentioned here are helpful to you, and that you carefully consider them as you plan future updates. In the meantime, I'm still at somewhat of a loss about how we can best manage the kind of gift order functionality we used to have. I'll keep thinking about it and hopefully come up with something.
  • brettbrett FoxyCart Team
    edited October 2015
    @Geoffrey, thanks for the clear communication on this issue. @fc_adam and I are discussing, but a few quick things.

    To touch on the reason for the reorganization: As @fc_adam said, we saw test data from some of our users showing it increased conversions considerably, so we believe it to be a net-positive change. Not helpful in your case, though. We didn't make an option because the logic for the checkout template is pretty intense, unfortunately.

    To your problem A and B: If it were me, I'd probably throw a cookie (and/or a value in the FC.json) for that checkbox setting. So once it's checked, keep it checked. The possible problem situations as I see them are:
    * Customer misses it at first, then selects it later. Not sure if you're using the url parameter, but the customer could click the product to go back to the product's page, re-add with the checkbox, and remove the "ship to: me". Or they could miss this and find out at checkout, at which point they'd still have the billing address first, then the shipping address next. That'd be less pleasant.
    * Customer hits it at first, then unchecks it on a subsequent product add-to-cart. Not really a problem, as that'd be their intent, and the checkout would do multiship.

    Perhaps worth noting is that multiship does do the billing address first, followed by shipping, which is more what you're after.

    -- problem D: the required process of adding gift options or alternate shipping options at the product page, rather than in the cart or at checkout, is a pretty serious departure from established e-commerce conventions. I honestly do not know of another non-foxycart e-commerce platform or site that does this.

    This isn't at all intended to come across as "you're wrong," because both @fc_adam and I agree you're bringing up some great points, and that your particular situation is indeed tricky with the 2.0 changes. But I think we're at least partially in good company, because Amazon has similar behavior:

    The first shows the gift option on the product page near the add-to-cart button. The second shows shipping address selection there as well.

    All that said, you're absolutely right that our multi-ship functionality would be better if we allowed moving products from one shipto to another. I agree 100% there.

    @fc_adam and I are going to continue talking this over. I think we both think multiship probably would be the best approach, though you do bring up good points as to why it's not perfect (and may in fact be detrimental). So short of that, I think the solution would be to customize the checkout template a bit to get it how you'd like it. In theory, this should be totally doable, but we'll discuss a bit more on our end before we officially make that recommendation.

    Thanks again for the great dialog! These are exactly the types of conversations that help push us towards improvements.
  • @brett and @fc_adam,

    Thanks for the follow up and additional information. I very much appreciate the lengths that you go to help. I see the potential conversion value of having the shipping address be the default, though it does present its own problems where customer accounts enter the picture. I'm starting to think that an account-based customer address book that could be managed and saved on the account level would be very useful in addressing the problem of saved account addresses getting overwritten, but that is somewhat of an aside.

    What I really wanted to get across with problem D is the limitation that users can only set the shipto/gift option on the product page, and are not given the ability to set these options in the cart or checkout. You pointed out that Amazon allows shipping address options to be set on the product page, which I recognize, but the important thing is that Amazon also allows the shipping and gift options to be set in the cart > checkout. The fact that FC multi-ship can only set these options prior to cart add is the critical limitation I wanted to touch on.

    I think in it's most ideal form a multi-ship function would allow for setting these options at any or every step of the product > cart > checkout process. The greatest detriment to not allowing the shipto option to be set in the cart or checkout, is that in the event of error it potentially requires the customer to navigate back to several different pages in order to make corrections to their order. If they could do this in the cart, all the options to be set would be in one place and they could accomplish the task without having to interrupt or navigate away from the cart > checkout process in any way. I'm sure this makes sense to you based on your responses. In any case, I do realize that making this kind of change to multi-ship would probably mean a significant overhaul of the FC systems, so I don't expect it to happen any time soon. I do hope you will seriously consider it though.

    I'm still not convinced that multi-ship is a good idea for us to use in its current form, so if a checkout modification might serve an alternative, I'd be interested in exploring that possibility. Would I run into any problems if I modified the checkout template with TWIG to manually switch the position of the billing and shipping address sections, so that the billing address serves as the default and the shipping address is the hidden alternate address? If I did that, would account users successfully have the billing address serve as the shipping address on a given order if they did not check the box to show and use the hidden shipping address fields? I'd be hesitant to make this kind of modification if it's not necessary, but it's starting to look like it might be to achieve the kind of gift order functionality we're looking for.

    Please share and further insight, thoughts or suggestions you have on this. Many thanks for all your help.
  • fc_adamfc_adam FoxyCart Team

    We definitely hear you - and future enhancements to multiship is definitely on our radar, but as you correctly noted it would be a significant change on our side.

    For now - as Brett hinted at you could change the Twig template for the checkout yourself so that the billing address and shipping address fields are flipped. I did a quick test just now, and it's possible to do - and if you have both billing and shipping displayed by default the checkout should work just fine - although it will mean that the shipping and billing addresses are both required.

    You could handle that a couple ways. One would be to add a link to copy the billing to the shipping so the customer could just click that and it would be copied over. You could also try to use a similar approach to what we do with the billing address now, and only include the shipping address within the form when the "use a different address" checkbox is checked. It's important to note that in that situation, if the checkout is submitted without a shipping address, then the customer won't have a shipping address at all - we don't copy the billing address to the shipping address as the checkout expects it to be there for shippable transactions.

    You can see our current default checkout template here:, and let us know if you have any questions!
  • GeoffreyGeoffrey Member
    edited November 2015

    I have been trying to modify our checkout twig template per your suggestion. I wanted to use a similar approach to the default template, where the shipping address would only be included if the "use a different address" checkbox is checked, but I've run into a major problem with this. When the shipping address fields are not included in the form, the Shipping Method section will not populate, since the script controlling that doesn't have any location data to compute. It doesn't look like there is any way around this.

    I would rather not force all customers to fill out both billing and shipping addresses at checkout, even with a copy function, so I'm having to consider different approaches at this point. My current idea is to include some kind of conditional selector (radio or checkbox) at the beginning of checkout, asking "Would you like to ship this order as a gift?" The selector would default to false, and if the selector is set to true, it would modify the checkout in several ways:

    1. Force guest checkout
    2. change customer shipping block legend text to: Gift Recipient Shipping Address
    3. add custom field for Gift Message
    4. Force "use different billing address"
    5. Hide checkbox for "use different billing address"
    6. append a message somewhere explaining something like, "Gift orders require guest checkout to ensure your saved account information is not overwritten"

    Ideally, all of the modifications I list here would toggle on/off based on the state of the initial gift order selector. Here are my questions:

    1. Is what I'm describing technically feasible in the FC 2.0 checkout?
    2. Are there any caveats or problems I need to look out for with any of the modifications I've listed?
    3. Could the mentioned Gift Order selector effectively force guest checkout before a customer enters their email address, or will it have to be set after the email address account look up is processed? (I want to prevent account log-in as thoroughly as possible when Gift Order = True).
    4. If it is possible to have the Gift Order selector force guest checkout, what are the consequences if SSO is being used? (we don't currently use SSO, but plan to implement it in the near future)
    5. What is the best and most direct way to approach this: modify the TWIG template, use javascript, some combination of both?

    I need to have an effective way to process gift orders in our checkout again by next week, for the big sale weekend. Any additional help and guidance you can provide on this is deeply appreciated.
  • @fc_adam,

    Also, I'm just realizing that our subscription product might throw a wrench into the whole approach I described above, as subscriptions must include account sign up. We want to have a gift subscription option as well, as we used to do this, but also ran into customer account address problems with it in the past.

    I just took a look at how Foot Cardigan used multi-ship to handle gift subscriptions, and I think perhaps we will have to develop something along the lines of that approach for gift options on subscriptions -- using multi-ship only for our subscription product (which cannot be purchased with other items anyway), and not using it for all other orders of regular product.

    I recognize that our situation is unusually complicated by the fact that we have both subscription and non-subscription products, but is there a way that I can still accomplish something like the approach in my last message, but avoid interfering with a normal checkout flow for the subscription product? We already have it set up so that the subscription product can only be purchased separately from non-subscription products. Sorry if this is confusing. Let me know if I can further clarify anything. Thanks.
  • brettbrett FoxyCart Team
    Hi @Geoffrey
    @fc_adam and I have been discussing this. We've got a long response prepared but we want to ensure we re-read through it so we can get you the best info possible.
  • @brett,

    Thanks. I appreciate your help, and look forward to it. Hopefully we can get something manageable worked out in time.
  • Any updates on this, guys? I am hoping to get something set up in the next few days. Thanks.
  • fc_adamfc_adam FoxyCart Team
    edited November 2015

    Sorry for the delay in getting back to you.

    The customisations you're talking about here are quite involved and there's a good chance they'll be quite time consuming for you as well. Putting aside the limitation you've described with the customer needing to set the recipient on the product, multiship is built to handle the exact set up you're trying to change the normal checkout template to handle. It will get especially tricky with your customisation once you throw in SSO and subscriptions as you won't just be able to default to a guest checkout in those instances.

    One alternate approach that came up in some of our discussions would be to try to emulate the ability to specify the shipto recipient on the checkout like you've seen on those other stores. It'd be a primarily javascript solution - and you would have to remove and re-add a product each time the shipto is changed - but it would be technically possible to do.

    The benefit then is you wouldn't need to alter how the checkout form works at all - you could leave it as default, allowing you to make use of SSO and subscriptions without needing to worry about your changes causing issues for customers.

    There is one curveball with this approach though, and that's the inclusion of link and form encoding. What this means is that you need to encrypt the add to cart links when adding/removing products from the checkout. There are a couple approaches to it, but they'd generally rely on passing a secure request off to an endpoint on your website from the checkout to facilitate the encoding of the link. You could send off just the request to your endpoint with the session ID, the product ID and the new shipto value. Your endpoint could then fetch the current session and perform the updates from your server before returning the result and you can then trigger a re-render of the checkout.

    That's the approach we'd recommend taking though - making use of the existing multiship functionality and adding in the live shipto altering that you're wanting. While what you're describing above should be achieveable, there are a whole host of unknowns and edge cases that would be hard to test for that could become big issues.
  • @fc_adam and @brett,

    Thanks for all your feedback and help with this. We will probably pursue the javascript approach you mention for editing the shipto in cart and checkout in the near future, but we have not been able to fit it into our development agenda yet.

    In the meantime we have decided to use multi-ship as is while holiday shopping is still active. There are a couple other shipping related issues I am in need of your help with, but I will post those in new threads.
Sign In or Register to comment.