Leaderboard

Not committing the changes is essentially undoing everything. Sure, why not? That's exactly what someone who was already a member and needed to renew would be doing. The user and order should already be tied together. Then you tie the payment to the order and record whatever it's result is, be it failure or success. If it's a failure, notify the user and offer them a chance to try another payment. For the second payment you can either make a new order or just add a new payment record to the existing order. Totally up to you and what you want to do. Unless you're doing a one-time payment thing, which if I remember correctly from prior threads you're not, then that's work you have to do anyway for when a member's subscription expires. When that happens they need to be able to login so they can manage their account (and potentially renew) but you'll want to block the content. So...Do the work and take advantage of it for new sign-ups as well. That is something you can and ideally should catch client-side with JS before the form is submitted. Sure, you can do that. If you go for the simple roll everything back method then that's probably all you need to do. If you create and keep the account however, consider this scenario: I'm trying to sign up for your site but, unexpectedly, my payment fails. "Oh my, how can this be!" I say. I open a new tab and rush over to my online banking to double check my account. Upon logging in I discover my card has been deactivated due to potential fraud, some other site must have been hacked! My new card is on the way in the mail. "Drats, I guess I will just have to wait til next week for the new card" I sigh. Since signing up obviously won't happen today I shutdown the computer and go on with my day. **inspired by a true story With the accout having already been created as part of the original attempt, I can't just sign up again with the same details, an account already exists. So I'd need a way to login then complete the checkout from there. Ultimately, this entire thread just boils down to "Pick something, and do it" There's not a single right way to handle this. There are some ways that can arguably be better than others, but every option has a pros and cons list and it's to you to decide how the pros weigh vs the cons. Option 1) Single transaction, roll it all back if the payment fails Pros: Easy to implement. Fairly easy for users to understand (had a problem, nothing saved, start over) Cons: Less flexible. Less data to track/analyze. If the user calls wondering why their payment failed, you may not be able to answer that question. Possibly annoying for users, particularly if the sign-up process is long. Option 2) Create account, handle payment separately. Pros: More flexible. Able to track all orders and payments. Potentially able to answer user's questions about payment failures. Cons: Users may not expect the account to exist (easily addressed though). Harder to implement. Other: Details can implemented in a range of different ways, either with their own pros/cons and level of difficulty. Option n) whatever other way you can think of. Weigh it's pros and cons. Pick a route. Figure out what process you want to follow and Just do it.™ If you're ok with not tracking every payment and want to take the easy route, then go for option 1. Otherwise go for option 2 and figure out what features you need and what you can live without. Have some other idea you think is good? Go for option n. You can always revise the process later if it turns out to not work out as well as you'd hoped. If it were me, I'd lean toward option 2 and putting in the work necessary to track all the payment details. I'd probably make the sign-up a two-step process rather than a one-step process just to help make it clear to then user that the account is created regardless of payment status. You can have both steps on the same page if you wanted for a nicer UX, just use JS to process the account creation via AJAX in the background. Most places I've dealt with in the last few years offer a trial period which kind of forces them into creating the account separate from payment handling. Many don't even ask for payment details until the trial ends. Some have asked up front but don't process them until after the trial. A few have run a small authorization (which is later voided) just to check the validity of the card and prevent signup on failure; mainly to prevent abuse where people just sign up for a new trial every month and/or as a type of captcha to prevent bots from signing up.