Latest News: (loading..)
imusorka

One-Page / Guest Checkout

25 posts in this topic

We would like to have a one-page checkout for both guests and registered customers. Many add-ons intend to add a guest checkout or transform the stock checkout to a one-page layout but all of them are ancient. What is a good way forward today, using Edge?

Share this post


Link to post
Share on other sites

I had a one page checkout on my site and it led to all sorts of issues. It was inherently glitchy and confused customers.

After that I decided to code and sell Better Checkout. I still use it on my site but I do not sell it anymore because I don't like all the changes required to make payment modules work properly. Basically, your customers can checkout with or without an account and it's seamless. It splits the checkout up into manageable chunks for customers and is easier to maintain code-wise. You are welcome to check it out on my site and see what you think maybe just to get some ideas. Mine is highly customized.

The more that I read on the topic it seems that people in general do better with small simple checkout pages and don't mind having to complete 3 or 4 SIMPLE steps (pages).

douglaswalker likes this

Share this post


Link to post
Share on other sites

I use Better Checkout (thanks Matt) I have not had too many issues with Payment Modules. 

Checkout with or without an account even if you already have an account but cant remember password etc.

All orders are still recorded under the email you use to checkout.

i have it working with zones, multiple shipping modules, payment method etc.

You are being to modest it is an awesome checkout alternative.

Share this post


Link to post
Share on other sites

Attached is what we would like to have instead of the stock checkout. Single page with AJAX-powered sections (both for registered users and guest). Clean, fast and convenient. We find that customers have become very impatient. Many leave because there are too many pages and no guest option.

checkout.png

Share this post


Link to post
Share on other sites

Sorry, I didn't write anything constructive in my post :blush:

I think just by judging the way that one page checkout screenshot looks is overwhelming the customer with too much information on the screen at once. The checkout process column on the right is not needed as I presume that information is shown again in the last step for the confirmation. The same edit links are also available with each step listed.

Having a JavaScript based one-page checkout procedure is nice and can outperform a standard checkout procedure, but only if it has been designed properly. The idea behind a one-page checkout procedure is to keep it as simple as possible for the customer experience, not the technical achievement experience.

Share this post


Link to post
Share on other sites

@Harald Ponce de Leon Agreed on the progress column. Step 1 is registered/guest user selection, which eliminates this elsewhere altogether. Step 3 is skipped if billing and delivery addresses are the same. Step 4 could be avoided by passing details from the shopping cart if it has a shipping quote and selection box. Down to 3 steps really. To have something like this in stock osC would be awesome. I'm pretty sure it's a piece of cake for you all mighty devs. :)

What is wrong with entering card details before confirming the order? Isn't that how it is in osC and everywhere else?

Share this post


Link to post
Share on other sites

There isn't a one page checkout procedure in v2.3 due to the legacy codebase having the ideology of working on browsers with cookies enabled or disabled and JavaScript enabled or disabled. The v2.4 release will still have a standard checkout procedure however it doesn't share the same ideology and can have a one page checkout in a future v2.5 or so release.

Regarding entering card information before the checkout confirmation page, we moved those fields in the payment modules a while ago to the checkout confirmation page. I don't remember if there is a European law on it, but it's more satisfying for the customer to see the real and exact order total when entering their card information in. If something alters the order total during the checkout payment page and the checkout confirmation page (card acceptance fees?), the customer will feel cheated of giving up their card information for an order total they didn't agree to.

For the cases where card acceptance fees are passed to the customer, the customer chooses Credit Card on the checkout payment page and first enters their card information on the checkout confirmation page where the fee is included in the order total rows. The customer sees the exact order total before entering their card information in.

Gyakutsuki likes this

Share this post


Link to post
Share on other sites

Hey guys, enjoying this discussion.... 

Just wanted to point out, if you think it's relevant to OsC, Amazon (the largest ecom retailer in the world by far) doesn't use one page checkout. 

4 super simple clean steps  

 

mattjt83 and John W like this

Share this post


Link to post
Share on other sites

Interestingly, Amazon asks for card details before the checkout confirmation page. They also use AJAX, which helps making the whole process so smooth. It's lightning fast on mobile.

Share this post


Link to post
Share on other sites

@imusorka they do - and therefore do what knowone on here would recommend... they store you CC details. 

That said, amazons security budget is larger the the GDP of a small country. 

Share this post


Link to post
Share on other sites
2 hours ago, greasemonkey said:

they do - and therefore do what knowone on here would recommend... they store you CC details.

I advise against that too if you're going to store the details locally in your database due to PCI-DSS regulations, however there is absolutely nothing wrong with storing card details if you have a payment service provider providing you that service (most do today without an extra charge).

To be on the safe side it's nice to have a checkbox option near the card input fields to save the card details for the next purchase. Some sites don't have the checkbox and always store the card details - this always comes down to your business and your target audience. At the very minimum it should then be described in your privacy or terms and conditions page.

Requiring CVV and 3D Secure is common for first time purchases (though I believe amazon.de asks for neither) and is usually configurable if the CVV and 3D Secure should be asked for again for future purchases to allow one-click purchases. This again comes down to how strict you want the security checks to be to protect against fraudulent sales.

 

Share this post


Link to post
Share on other sites
1 hour ago, ArtcoInc said:

@mattjt83

 

If so, will you release it? Please :cool:

(and commercially is fine too :ph34r:)

Malcolm

It's free... no need to release as this is how OsC is designed out of the box. 

Of course there is definitely customization you can work on to clean up the 4 pages: shopping_cart, checkout_shipping, checkout_payment & checkout_confirmation 

Share this post


Link to post
Share on other sites

Another issue to consider is the general speed loading time of your site. If it's slow, don't think a one page checkout will increase sales by 650% just because "AJAX is fast". It may be fast because the rest of the site is slow :mellow:

Remove the left and right columns of the checkout procedure and it's a giant step towards the "one thing per page" concept.

Edited by Harald Ponce de Leon

Share this post


Link to post
Share on other sites

My ethos is;

Make it very simple for the customer to do things.   As far as a checkout goes, what can be more simple than;

login > choose shipping > choose payment > review order > complete

It has been proven many times that a bite-size of cake, followed by a bite-size of cake...is far better than ramming a whole cake down ones throat.

What I would like to see [in CORE]...which is sort of related...

On shopping_cart.php a summary (estimated) shipping price, (estimated) taxes and so on.  So they see their grand total prior to starting a checkout.

Edited by burt

Share this post


Link to post
Share on other sites
17 minutes ago, burt said:

On shopping_cart.php a summary (estimated) shipping price, (estimated) taxes and so on.  So they see their grand total prior to starting a checkout.

The shopping cart page could act as a checkout confirmation page for existing customers as their information and preferred payment options are already known. There is no need to go through the checkout steps, if the customer needs to use a different address they can click on the "edit" link and return straight back to the checkout confirmation page.

Share this post


Link to post
Share on other sites

I think it would be best not to include the possibility of storing card details so as to safeguard inexperienced osC users from potential risks. In the US, you may not store cardholder data as per PCI DSS anyway. Are there similar regulations in the EU and Australia?

Share this post


Link to post
Share on other sites
32 minutes ago, imusorka said:

I think it would be best not to include the possibility of storing card details so as to safeguard inexperienced osC users from potential risks. In the US, you may not store cardholder data as per PCI DSS anyway. Are there similar regulations in the EU and Australia?

I did not refer to storing the actual card information locally in the database - that I advise against unless you know what you're doing with PCI DSS (you 99% don't, so don't try). What I'm referring to is allowing the payment service provider store the card information on their servers and have them deal with PCI DSS (they are 100% compliant as it's their business). The payment service provider sends you a token which is stored locally in the database and is referenced for future payments. This token must be of course secured locally just the same as your payment service provider credentials must be secured. The last 4 digits of the card number is stored so the customer knows what card is going to get charged. It is here where CVV and 3D Secure can be configured to be asked for again as they have already been verified when the first purchase was made.

The PayPal and Braintree Apps have this as a configuration option. Other payment modules that support vault storage are also configurable to enable the feature. The card input fields are loaded via iframe from the payment service provider so the card information never touches your server. There is no need to worry about PCI DSS even when stored tokens are enabled.

Edited by Harald Ponce de Leon

Share this post


Link to post
Share on other sites

BTW, at https://demo.oscommerce.com, vault storage has been enabled for the following payment modules:

braintree_cc
sage_pay_direct
stripe

Please use a test credit card number to test it out, eg:

4111111111111111
any expiry date in future
any cvv code

The stored cards are then managed in the My Account area. For your next purchase, the payment module should detect a stored token and automatically select the payment module for the order.

Share this post


Link to post
Share on other sites
6 hours ago, Harald Ponce de Leon said:

 

Remove the left and right columns of the checkout procedure and it's a giant step towards the "one thing per page" concept.

Maybe consider making all these pages modular for 2.3.5 (or even 2.4)???? just like checkout confirmation. 

 

Edited by greasemonkey

Share this post


Link to post
Share on other sites
23 hours ago, ArtcoInc said:

@mattjt83

 

If so, will you release it? Please :cool:

(and commercially is fine too :ph34r:)

Malcolm

I've been working on this for a while now but real life has been getting in the way. 

22 hours ago, greasemonkey said:

It's free... no need to release as this is how OsC is designed out of the box. 

Of course there is definitely customization you can work on to clean up the 4 pages: shopping_cart, checkout_shipping, checkout_payment & checkout_confirmation 

The difference with mine is just that you don't have to create an account first. Yes, eventually the person will have to enter the data regardless but it's how they perceive the task that matters.

I think it's very important to understand your customers and design your site/checkout experience around that. If most of your customers are one-off sort of things than a guest checkout can make a lot of sense.

Share this post


Link to post
Share on other sites

 

4 hours ago, mattjt83 said:

The difference with mine is just that you don't have to create an account first. Yes, eventually the person will have to enter the data regardless but it's how they perceive the task that matters.

Vital point .. account creation option should come at the end of the process (if a customer wants to):thumbsup:

Share this post


Link to post
Share on other sites

Agreed. Account creation option at the end of the checkout would make it much more user-friendly. Our customer surveys show the same. Seeing this in one of the future releases of osC would be grand. As would quoting postage in the shopping cart and jumping straight to payment afterwards. The process has not changed in over ten years. Perhaps it is time?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now