My delivery address is the same as my billing address

[Ben224]

Hello fellow Cubecarters,

I am finalising my second cubecart store and would like to modify the following:

I believe that forms are a huge turn off for customers and the less they have to deal with them the better. It's an opinion and not based on any research. I appreciate that collecting customer details is critical to a sale but I think that the quicker I get my customers through checkout the better.

At checkout, currently customers are faced with two address options:

1. Billing Address
2. Delivery address

There is a check box right after the Billing Address that confirms... 'My delivery address is the same as my billing address'.

Once checked the Delivery address goes away. Perfect.

My question is can this question be reversed? In other words can the customer be faced initially with ONLY the Billing address form and two (REQUIRED) checkboxes to confirm either...

A. My delivery address is DIFFERENT from my billing address (if checked the second delivery address form expands to be completed)
or
B. My delivery address is the SAME as my billing address (if checked nothing happens they continue to checkout)

It's picky I know, but a very small percentage of my customers actually have separate billing and delivery addresses. And I think the initial smack in the face of form fields that you get when you hit checkout would be greatly reduced doing it this way. This may help with abandoned carts?

Anyone?

Thanks in advance.

[bsmither]

There are two or three aspects to this:

* You as the store owner can require that all orders be sent to the billing address - period.

* You can require all customers be 'registered'. As such, they have the opportunity to enter as many delivery addresses as they want into their "Addressbook".

* You can require all customers use their "confirmed address" as entered into PayPal (and may be Google and Amazon).

 

In Store Settings, Stock tab, Allow delivery to non-invoice address can be set to disabled. Then, the delivery address selector or form, for both registered and 'ghost' customers, will not be displayed.

 

On the Features tab, Hide prices until logged-in will induce your customers to register. At their convenience, they can update their addressbook. During checkout, everything is already done.

 

I have come to learn that some of the plugin-based gateways (Alternate Gateways) can allow the customer to be taken to the payment page of the gateway (PayPal Express, for example). If the customer hastheir delivery address already established there, PayPal will send back to CubeCart the result of the transaction as well as the confirmed delivery address.

 

If none of these approaches are satisfactory, let us know.

[Ben224]

Hi Bsmither,

 

Thanks for your response. I want to allow delivery to an address other than the billing address should the customer require, so disabling the form completely in the stock tab is not ideal.

 

What I'm looking for here is a way to keep all the current input forms and functionality but create a kind of 'Checkout Lite' experience or 'Minified' checkout; just the bare bones. If the customer needs to input more information i.e. a separate delivery address then I want those fields to be hidden until they are required rather than display every possible field available from the outset. Most of my customer’s don’t need to fill out all the available fields and I think they can be a bit daunting in those instances.

 

I want to keep the checkout as simple as possible conducive to 'passing trade' rather than registered users.

 

Thanks again

[bsmither]

I think the most streamlined of checkouts is to use PayPal Express (or similar). Hide the billing and delivery fields altogether, and even hide the Continue/Checkout button.

 

Make sure they choose a shipping method not based on a delivery address, and then off to PayPal they go. No need to go to the Gateway screen.

 

PayPal then sends to CubeCart the delivery address from the customer's PayPal account.

 

That said, from your original post, perhaps you want just a tad more to the checkout process.

 

So, working on your specific request, you said:

"At checkout, currently customers are faced with two address [blocks]: Billing Address and Delivery address. There is a check box right after the Billing Address that confirms... 'My delivery address is the same as my billing address'. Once checked the Delivery address goes away. Perfect."

 

That's not how it is supposed to work. Your sig says you have a bespoke skin. Let's look for a few items of interest:

In the template file content.checkout.confirm.php, look for the line similar to the following:

{if $ALLOW_DELIVERY_ADDRESS}<div><label>&nbsp;</label><span><input type="checkbox" name="delivery_is_billing" id="delivery_is_billing" {$DELIVERY_CHECKED} /> {$LANG.address.delivery_is_billing}</span></div>{/if}

Make sure there is a {$DELIVERY_CHECKED} Smarty variable.

 

I am going to assume that the core code of CubeCart has not been modified with respect to this variable. That core code is near line 977 in cubecart.class.php.

 

So, I think for some reason, your bespoke skin or the Cubecart class has been changed. The box should be checked by default.

[Ben224]

Hi Bsmither,

 

Thanks for the clarity. I should have mentioned that I am working with Crosshatch on this occasion. Anyhow Paypal express does appear to be the ultimate 'Checkout Lite' solution but yes you're right I do need a little more.

 

I've had a look content.checkout.confirm.php and I note that the variable {$DELIVERY_CHECKED} is where it should be only spelt in lower case as follows {$delivery_checked}. I changed to your uppercase variable and it now checks the box as you would expect collapsing the delivery address block below by default.

 

Much better, I think I can live with this now thank you.

 

Before we close the thread it's probably worth mentioning that I went over to the cubecart.com demo and loaded Crosshatch. It appears that the delivery-checked variable is not effective across the board? Might need a tweak?

 

Thanks again!

[bsmither]

Thank you for making the discovery that the variable is in the wrong lettercase in the Crosshatch skin.

[Ben224]

You're welcome, I'm only too pleased to contribute!

 

Thanks again.