Has anybody set up checkout as a "single page" che...
# support
g
Has anybody set up checkout as a "single page" checkout? I have a client who wants to collect everything (cart qtys/billing/shipping/payment/discount info) all on a single page. Wondering if anybody has done it and has any words of advice on things to watch out for while we work on it.
j
Yeah, I’ve done it. Be mindful of the dependencies of the data in the steps. I’ve seen people try to make “auto-updating” single page checkouts and those tend to introduce enough UX issues to make it not worth it. Instead, even if it’s all on one page, still design it with discrete steps and have buttons to submit things (address, shipping method, payment, etc). There’s different ways to present that, but it’s definitely the right way to go.
💯 1
g
I'll keep that in mind, unfortunately their existing site has that "auto-updating" functionality. It's possible they'll push to keep that. I'll definitely try to make it clear that's not ideal with how data needs to be handled.
m
We've gone there and back, and we find we're better off with several steps.
w
Sorry if this is off-topic, but any chance this Turbo email-only signup for Devise (https://stackoverflow.com/questions/71105237/inline-devise-signup-form-using-turbo-frames) could aid in the UX?
c
I think the sign-up / guest user is one part of it, but I think what Jared was getting at is more there are certain dependencies in the steps, w/o an address you can’t show shipping methods / tax totals etc, without choosing a shipping method you don’t know what the payment total is going to be etc.
w
Yup, true that.
c
So even if you do all this on a single page, you have to do it in a way that facilitates a certain order, either by hiding the subsequent sections or some other means
w
I've implemented the above on my other apps by the way -- works really well 👍
👍🏼 1
I see
g
Luckily with this particular thing I think they're using flat-rate shipping, so we don't need to worry about generating rates based on their location.
c
You still need to have an address persisted on the order to advance it through the state machine states
I think one tip would be not to try and remove any of the states, but instead advance the order through as you get the data you need to transition to the next state.
g
Oh for sure. If we do make an effort on a one-page checkout, I'd probably approach it from the "treat it like the cart page" so they can update quantities and discount codes. Conceptually I would think we could step through the states behind the scenes when the customer clicks the "check out" button, since there isn't really much on their page that relies on other pieces.
I'm sure that's a bit naïve, but in my head it seems like it should mostly work.
c
Yeah, the nice thing with allowing individual sections to be submitted separately is that a user doesn’t go through a giant form only to refresh the page and have to start over or you as a developer having to keep all that state on the frontend somehow.
I am also not a UX expert but I feel checkouts with a lot of things can be a bit daunting, so hiding some of the stuff and having the user advance step by step might improve conversion
g
Yeah, that's the part that I think we'd have to try to sort out. I do like the idea of having the steps "collapsed" and then have a "continue" button that would step into the next state, but also would give an action that we could hook into that could submit the data along the way.
👍🏼 1
v
Bit late to the party but: I initially build the checkout in Nuxt. What I did as suggested above by submitting each step. I would either do this using a button (address) or hidden events like entering an email, changing a country, a payment method etc. Depending on what was needed I would move to checkout back or push it forward. The layout just changed based on step number. This made it feel like a one page, but in reality I would just move through the state machine
👍🏼 1