Yes, generally, you still want to use a confirmation email even if you are using a verification service (we use BrightVerify at my company) because you want to make sure the person who signed up is actually the person who has access to the email and isn't someone just entering their email in to get them spammed by you or just generally pretending to be be someone else.
Follow up question on your order of operations: Do you send the confirmation email immediately and then finish your user onboarding AFTER they respond, or do you create your new user (getting all their info) and then send the confirmation email? and then handle (somehow) deleting the user if they don't confirm?
For the process I'm thinking of, I think I'd have to wait to finish onboarding to avoid collecting money from people who don't have access to the email that they gave us. However, I am super curious how other people handle it.
Pellentesque nec neque ex. Aliquam at quam vitae lacus convallis pulvinar. Mauris vitae ullamcorper lacus. Cras nisi dui, faucibus non dolor quis, volutpat euismod massa. Donec et pulvinar erat.
Jess. Create the user the moment they enter your form. In the form, only ask for minimal user info needed for a valid account. Name and email for instance. Let them add all user metadata / fields such as address and phone after they fully registered/confirmed. When users decide on their own to provide their info in stead of it being mandatory during registration they have a more positive experience, communicate more open, are more likely to trust you. Youre right. Never accept payments before email is confirmed and do not even ask for payment details in the sign up form. It should not be possible to pay without verification.Let the user add this information manually after their email is verified and they are logged in. Not only will nobody be able to say they never gave you that info (after all they consciously added it manually) and it also increases the likelihood of a purchase/lead whatever you're doing. This has a number of reasons well known to marketing and lead generation minded people.
This may sound obvious but do not send the confirmation email from the sign up page script. So don't call your mail() function from the page that handles the POST data of the form. Separate the two always. Create a task of some sorts, even if it gets executed almost immediately don't let the same process be responsible.
Thanks for your thoughts. I was thinking that the "send confirmation email" is it's own function but is called kinda like so in the route handler -> action is createUser -> go to /api/user/new -> call createUser which ... checks to see if user already exists.then(create user).then(send confirmation email).then(go to login page or something else) - However, I'm not sure if you are saying that I should exit the createUser function and say now, go to send confirmation email.
I think what he means is that sending the e-mail should be done asynchronously in a separate thread/process/worker, thus not blocking your main thread. You can return a response to the user while the e-mail is still being sent in the background.
Yes, generally, you still want to use a confirmation email even if you are using a verification service (we use BrightVerify at my company) because you want to make sure the person who signed up is actually the person who has access to the email and isn't someone just entering their email in to get them spammed by you or just generally pretending to be be someone else.
Thanks for your thoughts here, Richard.
Follow up question on your order of operations: Do you send the confirmation email immediately and then finish your user onboarding AFTER they respond, or do you create your new user (getting all their info) and then send the confirmation email? and then handle (somehow) deleting the user if they don't confirm?
For the process I'm thinking of, I think I'd have to wait to finish onboarding to avoid collecting money from people who don't have access to the email that they gave us. However, I am super curious how other people handle it.
Jess. Create the user the moment they enter your form. In the form, only ask for minimal user info needed for a valid account. Name and email for instance. Let them add all user metadata / fields such as address and phone after they fully registered/confirmed. When users decide on their own to provide their info in stead of it being mandatory during registration they have a more positive experience, communicate more open, are more likely to trust you. Youre right. Never accept payments before email is confirmed and do not even ask for payment details in the sign up form. It should not be possible to pay without verification.Let the user add this information manually after their email is verified and they are logged in. Not only will nobody be able to say they never gave you that info (after all they consciously added it manually) and it also increases the likelihood of a purchase/lead whatever you're doing. This has a number of reasons well known to marketing and lead generation minded people.
This may sound obvious but do not send the confirmation email from the sign up page script. So don't call your mail() function from the page that handles the POST data of the form. Separate the two always. Create a task of some sorts, even if it gets executed almost immediately don't let the same process be responsible.
Thanks for your thoughts. I was thinking that the "send confirmation email" is it's own function but is called kinda like so in the route handler -> action is createUser -> go to /api/user/new -> call createUser which ... checks to see if user already exists.then(create user).then(send confirmation email).then(go to login page or something else) - However, I'm not sure if you are saying that I should exit the createUser function and say now, go to send confirmation email.
I think what he means is that sending the e-mail should be done asynchronously in a separate thread/process/worker, thus not blocking your main thread. You can return a response to the user while the e-mail is still being sent in the background.
Thanks for your thoughts Christian!