Allow register users during checkout / update cart

[sjcallender]

A first-party solution to Jeremy Daalder's "Commerce Register on Checkout" plugin and code snippets. We have a Craft 3 version of it running here - https://github.com/FosterCommerce/CommerceRegisterOnCheckout - but it'd be good to have this baked in.

[brandonkelly]

I’ve read the plugin’s README and the Stack Exchange Q&A it links to, and I’m still at a loss as to why a plugin (or core Commerce enhancement) is needed for this?

It’s already possible to register a user mid-checkout, and Commerce will automatically assign the active cart over to that user account afterward, just like if a user logs in. You can even enable the autoLoginAfterAccountActivation config setting so they get logged in automatically as soon as registration is complete.

What am I missing? (cc @bossanova808)

[lukeholder]

On a related note, I just added a functional user registration form into the example commerce checkout templates.

The templates now do the following:

1. Checkout now starts by only asking for an email address (Thanks @sjcallender for the idea in your dotAll talk)

2. If that email address has an account, the next step shows the login form. Also shows a continue as guest link.

3. If the email address does not have an account, show the sign up form. Also shows continue as guest link.

Hopefully that should help others wanting to know how to add user registration during checkout.

[bossanova808]

Ok, so this example will be very handy I'm sure....but...

The original motivation was to provide the simplest possible registration of users, and to do so as late as possible in the checkout process (there's some research (Baynard maybe? I can't find it again right this second but I've also observed this in user testing on many many occasions) - that shows presenting the option to register for accounts later is considerably more successful - the idea being this is because the user has already passed the mental threshold of entering all their shipping gump etc, so they might as well register at that point...).

There were a few issues in the longer distant past that meant the behaviour with a classic user reg form was distinctly less than perfect - for example when I started with this, way back when, I don't think autoLoginAfterAccountActivation was yet actually available maybe? - https://docs.craftcms.com/v2/config-settings.html#users maybe? TBH the exact reasons are a little lost in time, now...but either way, you couldn't do the registration as part of the last step in checkout (and still can't - without doing some fancy ajax multi submits anyway).

The other thing I recall was that addresses used in that first order were not copied to the new customer if they then registered as a user during (or even after) making that order (which I think it still the case (#36) - so when they came back, they had to re-enter their address details for their second order - I got maybe 20 emails from customers about this, was definitely an irritant to them ('Why have accounts if it doesn't bloody save the address etc.' - users, gotta love 'em)

Basically, with this approach, my issue is the timing of it. 'Mid-checkout', as a separate thing, is in practise quite different to actually 'with the final checkout', and I personally still want to to do it as part of that final stage as I know, from testing (and many years experience & consultancy in this area) - that that's the most successful approach to getting people to actually register. Our registration rate with our current approach is very high indeed...and anything that reduces that I'd very much like to avoid.

Anyway, I am about to start on the checkout bit of my upgrade now I am finally past most of the plugin code challenges etc...so I will be re-visiting this stuff soon...but personally I'd still like to really see a parameter (+ entered password) - with the final order submit that allows one to register the customer specifically at that point, and solves the address copying issue too.

[RitterKnightCreative]

I'd love to see the ability to register a user on the thank you page AFTER checkout when the user is already feeling good about their purchase (or even from a subsequent email). There's been quite a bit of research done in the Shopify community about this very topic.

Forcing users to register is like asking for marriage on a first date, it's a tough sell but after they've whipped out their credit card, it's a much easier sell. It's why things like instant upsells work so well.

Since we have the email address, we just need a password. Unfortunately if we prop up a registration page after checkout, the user will get registered but their shipping details, etc. are lost, negating the very reason they wanted to register in the first place.

In an ideal word, when we register users, I'd love the ability to reference back an email address and order hash (essentially treating the email like a login and the order as the "password") and let Commerce pull in the information from that order to populate the registration details. There's obviously some security by obscurity here if we let users register any time but if the user still has an active session (ie right after checkout), I think the risk is minimal.

Marketers forget it might take a couple purchases from a user to get them to register as well.

[bossanova808]

@RitterKnightCreative That's fairly easy to implement with Commerce (V1 at least, presume nothing has changed here with V2) - when you submit the payment/order completion bit...basically if you set a redirect on that to <input type="hidden" name="redirect" value="/cart/complete?number={{ cart.number }}"> - then you can just use the number to retrieve the order & grab the details from the order billing to pre-fill the form to the point all they have to do in enter a password. That's what I did originally.

Thus, I have tried exactly this and the registration drop off is unfortunately huge - we get about 90% of new customers creating accounts if we ask at the payment stage, and about 50% if we ask on the order completion page. I think people have already mentally moved on.

If they choose to register with payment, we log them in so that we can point hem straight at useful features like their dashboard, order tracking etc.

(That's anecdotal, but actual testing data from our store. We're not your average shop of course, so the Shopify research might be right, but I wonder if it's based more on theory than actual testing, as lot of this stuff seems to be.)

If P & T don't choose to add this (at the payment step) - as seems to be the idea here, then I will keep CROC going because this is a pretty essential thing from the shop owners perspective and I'm not willing to go backwards on this. This is one of those quite subtle UI things that you can only really get a feel for from long experience of actually running an ecommerce site, which in my case leave me 100% certain the best stage is that last order submission stage...

[lukeholder]

@bossanova808 & @sjcallender I am going to implement #36.

Planning on it working like this:

1. User can register (using the standard Craft registration form) at any time before or after checkout. Just as they can right now.
2. When any prior guest orders are consolidated to the new user account, any addresses from those orders are added to the new user's address book.

Question I have is: If they have more than one prior orders, should all addresses be copied to the new user's address book? Or just the latest guest order's addresses?

What are you thoughts on the above?

[sjcallender]

Copy all of the addresses over so we can display them to let them decide what to do with them.

I do wish there were a way to have the user registration happen with the checkout process, especially for subscriptions. For example, on a subscription site, users have to first create an account then subscribe. If in that checkout process they abandon before subscribing, they've now created an account without subscribing, which is not ideal. That was my intention with this request, but more in terms of a standard ecommerce cart checkout. The subscription example is better, I think, however.

[RitterKnightCreative]

@sjcallender Ouch, that's the way Commerce handles subscriptions? You need an account to make it work? Never tried that but if so, that's going to be a dealbreaker for many orgs. Is this because the Stripe plugin itself requires a full non-guest user? (That leads to a separate but related topic of OTOS.)

If we look at something like ClickFunnels, you can go through a whole OTO sequence for example while subscribing. No passwords at all. They actually set you up right away in a members order area if so desired and send your password via email. I'm not a fan of sending passwords via email but it must work. (If it were me, I'd probably use Craft's deferPublicRegistrationPassword.)

[bossanova808]

Hi Luke

I think all addresses should be copied for sure. That's what user's expect in my experience. And ideally last used ones for billing/shipping set to default.

So just to be clear - this means you'll definitely not be implementing registration as part of the order submission? If we have a clear cut negative statement on that I can get on to making sure CROC is ready for C 3.1 and Commerce 2...as for me this is essential functionality.

I don't use subscriptions so can't comment on that but that does, on the face of it, seem another good argument for having it...

[lukeholder]

This is now on the develop branch.

Please test with dev-develop please @bossanova808 @RitterKnightCreative @sjcallender

Docs on the feature are here: 9c6ac8e#diff-60dba506cab3a3e06b1bdcf53cbed370

Feedback on docs also welcome.

As mentioned the feature comes down to this:

With the registerUserOnOrderComplete flag set to true on the order, the following will happen when the order is marked as complete:

1. Check if a user with that email already exists, and if so, do nothing and not continue with the steps below.
2. Create a user with the same email address as the order.
3. Set the customer record to relate to that new user. This means all addresses in the guest customers address book will become the new users.
4. An account activation email will be sent, that will allow them to set their password.

The docs will no be published until we push this out in a release.

Also note, that this feature does not work with saving the payment method time or subscribing the user to a plan, they will need to create an account or log in first (current behavior), before starting those actions.

[bossanova808]

This is great Luke and I should be able to pull and test this during the coming week.

A few thoughts:

One thing to consider & perhaps document - assuming 1 thru 4 happen - but the customer then does not follow through at the time, and actually click on the set password link in the email.

They later come back and are checking out again - our checkout will now tell them they have an account and should ideally login - when they attempt to do so...what happens? I.e. what state is the user account in at that point? I presume it's just a live but dormant account (would that be 'pending' in status?) , and they then just have to use the Forgot Password feature, and away they go?

Also perhaps worth explicitly pointing out in those docs that users won't be auto-logged in after registering during the checkout.

Finally, for extension purposes (say I want to sign registering people up to a mailing list or whatever) - is it worth considering having some dedicated events here? Craft does currently have dedicated user registration events (which I find odd), rather one has to listen to element save events and check isNew etc. I suppose one can also check for this registerUserOnOrderComplete param there and extend that way...just feels like dedicated events might be more elegant.

[bossanova808]

So given I have now tested Luke's implementation above & it works well, I have offically decided to retire CROC - https://github.com/bossanova808/CommerceRegisterOnCheckout/blob/master/README.md - @sjcallender feel free to carry on with it if you need it, but the built in functionality is now enough for me so I'm running with that!

(I have now officially retired all my Commerce plugins actually - friendly order numbers, multi-add, CROC, my commerce mailer...since all of that is either now in core, or has become too business specific!

Many thanks @lukeholder for all your work in these areas - much appreciated - and the more that is properly done in core, and thus supported, the better (assuming it's pretty essential ecommerce functionality!)

[sjcallender]

@lukeholder This is really great @lukeholder. Thank you for prioritizing this. I haven't tested it yet, but we have a project over the next month where I'll be able to give a good go.

@bossanova808 Once this feature is shipped, I'll update the README for our forked version of CROC.

[stenvdb]

Any estimate for when this feature might be released?

[lukeholder]

@stenvdb this was released in commerce 2.1

[stenvdb]

@lukeholder ah sorry! Missed it in the changelogs then, very nice 🙂

[engram-design]

Wanted to raise this issue from the dead again. It'd be great to be able to set the password as part of checkout, rather than just a flag to register a new user. Doing so would be a much nice UX than getting two emails after checkout (one for the order-completed, and another to activate the account - if your site is setup for that).

Obviously this raises issue where @bossanova808's plugin had to encrypt and store the password, because this flag could be set anywhere through the checkout process. Would it be too much to ask to add a new column to an order, with a tempPassword or something similar, which stores the hashed password from the user. This is then simply copied over to the new user account, so there's no storing of unencrypted passwords, etc.

[bossanova808]

Have to say I would (still) definitely like this too...it's definitely more effective & better UX. But I believe there was some significant frowning on the idea of passwords in the DB (for history - with CROC I stored them in the DB (after asking Luke for advice) - but they were aggressively cleared out of there basically as soon as the registration was done and dusted).

Thinking about it, WHY was there resistance to passwords in the DB? Because of course the users table is full of encrypted passwords. So perhaps I misunderstood the objection....

[engram-design]

I could pull up numerous examples of other systems that include a checkbox to register the user, and when ticked, expose a password field - so this isn't treading new ground in the e-commerce world 😄

Sure, storing passwords in plain text is 101 stuff, but there's hardly much difference storing the hashed password against an order, until complete, where it can be applied to the new user record, and removed from the order.

But, always keen to be proven why its not a good idea?