1-Page Checkout

I have almost completed a true one-page checkout. A customer of mine requested it for his site so I decided to give it a go. It has turned out better than I expected. There is still some work to be done on it, but you can get the general idea by visiting http://www.justimagine-crafts.com/store1512. This is the fully customized version (save the submit button is disabled in the demo) so the actual extension version I will be releasing in the next week or two will look a little different. There is a Create Account button under the customers billing information which will be going away as the create account will happen after customer submits the order. Replacing the button will be a checkbox for stores that do not require customer registration in order to shop. This will allow the customer to choose at that point if they would like to create an account or not (default). Also, the payment section is customized for my customers site so it will also look different when the checkout page is complete.

The highlights of the checkout page are:

- Update the quantity of an item in the shopping cart
- Remove an item from the shopping cart
- Add a coupon/discount code
- All totals (taxes, discounts, shipping, etc) are added as necessary and updated on the fly
- Facebook/Google logins integrated to the checkout process - if customer logs in using one of these, their information
from FB/Google will be transferred to Opencart and an account created for them (optional)
- If your store requires customer registration, account will be created after submitting order
- If your store does not require customer registration, customer will have option to choose to register by checking a
box below their billing information or continuing as a guest. If they choose to do so, account will be created after
submitting order.

Please take a look at it, http://www.justimagine-crafts.com/store1512. Any questions, comments or ideas to improve it, please email me at develop@justimagine-crafts.com.

It looks nice, but I dont see how it is any diff than the default one. That isn't what people are considering a true one page checkout. You still have the accordion tabs that load just like the default. It is just styled better and possibly works better.

I think what people are calling "true" means there are no tabs.. all fields are shown at the same time like the magento onestepcheckout.com site

you mean something more like this

I guess it is different in that the customer can see everything on one screen without clicking "continue" to open the next step other than if they choose to ship to a different address from their billing address. Ultimately, that could be shown and disabled from the beginning and only become enabled if the customer chooses to enter a different shipping address. Then there would be no "accordion" like tabs. It would all be on one screen. I think it is best to be hidden at the start as most customers will be shipping to their billing address, at least that has been my experience with my online store. Also, the Create Account and Ship Here buttons will be gone as they are on the completed customized checkout page. The account will be created (if applicable) and the shipping address updated when the Submit Order button is clicked. I just have them on the demo site since I have the submit button disabled at the moment.

Thank you for the comments Q. That is the type of feedback I am looking for as I work to complete the checkout page. I have to make a bunch of changes on it since the one on my test/development server is the fully customized one for my customer and won't work for most shop owners. I did have one question though. Is it really necessary to have a confirmation since the totals update in the side cart as the customer makes changes? Would that and the message above the submit button actually constitute a confirmation? I want to make sure I make it usable by everyone should they choose to use it.

Xsecrets wrote:you mean something more like this

Thanks Xsecrets. I can see the diff now. This was the kind of feedback I was looking for. Obviously, my idea of a one-page checkout was different as was my customer's. The layout was his design, so I can't take credit for that. I guess mine is a visible one-page checkout where you don't have to click "continue" to move on to the next step. I certainly did not charge enough to do the checkout page. I obviously didn't know the amount of coding necessary to make that work. I do now.

ncdad2four wrote:

Xsecrets wrote:you mean something more like this

Thanks Xsecrets. I can see the diff now. This was the kind of feedback I was looking for. Obviously, my idea of a one-page checkout was different as was my customer's. The layout was his design, so I can't take credit for that. I guess mine is a visible one-page checkout where you don't have to click "continue" to move on to the next step. I certainly did not charge enough to do the checkout page. I obviously didn't know the amount of coding necessary to make that work. I do now.

no doubt. I had no idea how much work it would be when I started either. I've completed on for a customer that only works with limited options. That screenshot is from the one I'm working on that will support every feature of opencart, but I've got a week or two worth of work left on it.

hehe yes xsecrets... looks great. Glad you are working on this because It is so far down on my list at the moment i may not get to it until 2013!

Qphoria wrote:hehe yes xsecrets... looks great. Glad you are working on this because It is so far down on my list at the moment i may not get to it until 2013!

yeah it's pretty much at the top of my list, unfortunately due to a few things it's much harder than it should be, and due to the way the payments work It has to be a bit hacky at best.

IMHO the default OC checkout is fine.

It's simple to follow.

Putting all the info on one page is only going aid in confusing some people when presented with all that info to fill out at once.

uksitebuilder wrote:IMHO the default OC checkout is fine.

It's simple to follow.

Putting all the info on one page is only going aid in confusing some people when presented with all that info to fill out at once.

well I personally don't have a big problem with the current checkout, but people want the all in one page approach, so I'm going to build it for them to make some money.

I guess it is all personal preference, which tells that this should perhaps be more extendable and designable.

uksitebuilder wrote:IMHO the default OC checkout is fine.

It's simple to follow.

Putting all the info on one page is only going aid in confusing some people when presented with all that info to fill out at once.

The complexity of the current system's ajax-to-callback is a big turnoff for me. I think xsecrets design is cleaner personally. I've even done some shopping myself lately and find many simpler checkouts that I'd like to port over.

Qphoria wrote:

uksitebuilder wrote:IMHO the default OC checkout is fine.

It's simple to follow.

Putting all the info on one page is only going aid in confusing some people when presented with all that info to fill out at once.

The complexity of the current system's ajax-to-callback is a big turnoff for me. I think xsecrets design is cleaner personally. I've even done some shopping myself lately and find many simpler checkouts that I'd like to port over.

well you find alot of really nice easy simple checkouts going around the web, the big problem is that most of them assume limited functionality. Which is perfectly valid for that site because it's based on their business logic. It becomes more difficult to make a nice simple checkout when you have to account for all the various options available in the cart. Dynamic shipping zone based shipping and payment loged in users or guest users etc etc. For inistance the onepage checkout I've completed for a customer was much easier because they don't have shipping and always use guest checkout and don't use zone based payment methods, so I could make assumptions based on that and the logic becomes much simpler.

Xsecrets wrote: well you find alot of really nice easy simple checkouts going around the web, the big problem is that most of them assume limited functionality. Which is perfectly valid for that site because it's based on their business logic. It becomes more difficult to make a nice simple checkout when you have to account for all the various options available in the cart. Dynamic shipping zone based shipping and payment loged in users or guest users etc etc. For inistance the onepage checkout I've completed for a customer was much easier because they don't have shipping and always use guest checkout and don't use zone based payment methods, so I could make assumptions based on that and the logic becomes much simpler.

I agree.. There is complexity supporting unknown payment types with unknown features and potential for things like payment type fee. I should stop pretending that I have some clue as at this point I've not even looked into it all the way through to even surmise what is in involved. Kudos to you for taking the chance!

I do not have a problem with the current checkout either but I have so many people asking me about a checkout page where everything is visible to the customer and they don't have to click a button to move on to the next item. So the demand for it is out there. Like xsecrets said, it is just personal preference and a lot of people seem to prefer the one page everything visible approach. Believe me, if the demand wasn't there I would have stopped a long time ago. Wading through all this AJAX code trying to figure out the best way to do this has been a nightmare.

Qphoria wrote:

Xsecrets wrote: well you find alot of really nice easy simple checkouts going around the web, the big problem is that most of them assume limited functionality. Which is perfectly valid for that site because it's based on their business logic. It becomes more difficult to make a nice simple checkout when you have to account for all the various options available in the cart. Dynamic shipping zone based shipping and payment loged in users or guest users etc etc. For inistance the onepage checkout I've completed for a customer was much easier because they don't have shipping and always use guest checkout and don't use zone based payment methods, so I could make assumptions based on that and the logic becomes much simpler.

I agree.. There is complexity supporting unknown payment types with unknown features and potential for things like payment type fee. I should stop pretending that I have some clue as at this point I've not even looked into it all the way through to even surmise what is in involved. Kudos to you for taking the chance!

Well as far as payment shipping and totals you can pretty much just use the standard code and be ok. Honestly the biggest pain in the but is that the submit button is handled individually by each payment module. This is compounded by modules like yours that don't use the standard buttons. I'm just going to have to assume the standard buttons and provide vqmods for the non standard modules that I come across.

Xsecrets wrote: Well as far as payment shipping and totals you can pretty much just use the standard code and be ok. Honestly the biggest pain in the but is that the submit button is handled individually by each payment module. This is compounded by modules like yours that don't use the standard buttons. I'm just going to have to assume the standard buttons and provide vqmods for the non standard modules that I come across.

Well after being burned so many times I tend to use a lot of my own stuff in fear that the next change will break my stuff. I don't even use the new url::link stuff yet because I'm just waitin for that boat to sail again.

Qphoria wrote:

Xsecrets wrote: Well as far as payment shipping and totals you can pretty much just use the standard code and be ok. Honestly the biggest pain in the but is that the submit button is handled individually by each payment module. This is compounded by modules like yours that don't use the standard buttons. I'm just going to have to assume the standard buttons and provide vqmods for the non standard modules that I come across.

Well after being burned so many times I tend to use a lot of my own stuff in fear that the next change will break my stuff. I don't even use the new url::link stuff yet because I'm just waitin for that boat to sail again.

yes I've noticed. I'm going to have to create vqmods for you payment modules as my clients come across them. I already have the firstdata api one and will have a vqmod included for it in third party modules folder. Unfortunately there is no way to handle it other than to expect the default behavior.

Xsecrets wrote:

Qphoria wrote:

Xsecrets wrote: Well as far as payment shipping and totals you can pretty much just use the standard code and be ok. Honestly the biggest pain in the but is that the submit button is handled individually by each payment module. This is compounded by modules like yours that don't use the standard buttons. I'm just going to have to assume the standard buttons and provide vqmods for the non standard modules that I come across.

Well after being burned so many times I tend to use a lot of my own stuff in fear that the next change will break my stuff. I don't even use the new url::link stuff yet because I'm just waitin for that boat to sail again.

yes I've noticed. I'm going to have to create vqmods for you payment modules as my clients come across them. I already have the firstdata api one and will have a vqmod included for it in third party modules folder. Unfortunately there is no way to handle it other than to expect the default behavior.

If you can perhaps PM me with what problems you are having with my modules, perhaps I can alleviate that part for you. I'm willing to adapt.

well it's very simple the only way I have to intercept the submit and check everything first is to expect the default button intercept it then call it's click event, but your modules don't have the standard confirm order buttons you use submit and back buttons. See unfortunately when you have everything on one page you have to have somehow to do a final check before you let the payment submit unlike with the built in checkout where you already know everything else is done and correct. Luckily all the built in payment modules use the exact same button scheme, so I can simply intercept it. It's not a big deal. I'll just include a vqmod which basically replaces your two button scheme with the same button that is used by default modules. I'm going to have to use vqmod to change the return location for failures anyways since I'm using a different controller otherwise people would be returned to the old checkout.

Xsecrets:

The checkout you are working on, will it work with downloadable products?

And will it work for shops that dont sell to consumers but to other companies?
The only difference, I guess, is the field the costumer need to fill for a registration, company name, name on the person who order, and such.

Will it be possibly to change language? So instead of english, I can have it in Swedish.. If I or someone else do the translating of course. Im a complete newbie so I have to ask about such "trivial things"