Read this http://www.uie.com/articles/three_hund_million_button/

The company was Best Buy. Look at the stats which show that requiring registration essentially never helps. About the only time it would is for (very?) frequent visitors.

You don't need "security" for orders other than making order ids non-guessable. For customer service people can give their order id and other details if necessary (eg zip code, name).

Requiring email confirmation almost always decreases conversion and frequently in a major way. You should have a very good reason for confirming an email address (for example, PayPal tying payments to email addresses) or don't do it (or do it passively; ie, if someone happens to click on a link in an email you send them, mark the email address as confirmed).

I see. Thank you!

I disabled the limits for unconfirmed users and will create a merged form as soon as possible.

The development flow looks like this to me right now: First I built a strictly REST/model-centered back-end, and now I have to smooth the corners between user-friendliness and those standards. Interesting observation.

(Also, if anyone is curious what I'm building, it's https://artistsnclients.com/)

Reduce friction whenever possible. Allow the user to place an order before the confirmation, but limit the account until the user does. Also show an alert after a successful order that an email confirmation is being sent out and an option to resend it.

The only way to know for sure is split testing.

On the one hand, you build a bigger mailing list + extra friction.

On the other, smaller mailing list, but more users get to try your service.

I recommend a split test.

I would say you should combine them. As long as you provide an easy way for contacting in case they have a problem, they best thing you can do is simplify the registration/purchase process.