From Shopping to Checkout

[SaranacLake]

This is part PHP, part MySQL question, but since I'm more interested in the process-flow, I'll ask here.

I am ready to start coding the e-commerce module of my website, which features mostly paid subscriptions.

 

Do the below steps sound like the correct sequence to do things in...

	- Anonymous shopper adds subscription to Shopping Cart
	- Shopper goes to check out
	- Shopper completes checkout form which includes setting up the account and entering payment details
	 
	Now for the important stuff...
	- System takes Shopping Cart details - which include the PHPSessionID
	- System creates Member record
	- System takes Shopping Cart details associated with PHPSessionID and links them to the new Member record 
	- System creates Order and Order Details records
	- System runs the payment
	- System hopefully gets back a "success" message from Payment Processor
	- System activates the Member's account
	

 

How does that sound at a high-level?

 

Really what I'm trying to validate is if I should create the Member record 1st, then create the Order records 2nd, and worry about the payment last.

(Originally I was going to run the payment first, but I'm thinking it's better to capture the anonymous shopper's details in a Member record and Order records first, because even if the paymnt fails, you want something to work off of - like reaching out to the person and getting another valid payment.)

 

Thoughts?

 

[requinix]

- System takes Shopping Cart details associated with PHPSessionID and links them to the new Member record

Do you care about storing shopping carts with an account? Some sites do, some sites don't. If you don't care then you don't have to do that step.

 

1 hour ago, SaranacLake said:

Really what I'm trying to validate is if I should create the Member record 1st, then create the Order records 2nd, and worry about the payment last.

Look at your process this way:

If a worst case scenario was to happen between any two steps, would your process be able to recover gracefully from the failure? Will you lose any information? Will the data in your database be incomplete or otherwise corrupted?

For example,

- System runs the payment
- System hopefully gets back a "success" message from Payment Processor

One potential worst case here is that you submit a request to your payment gateway but the system blows up before it can receive the successful response. What would happen with the plan you've described? What should happen?
But be careful: I've chosen a particularly devious scenario for you to consider. The answer may surprise you.

[SaranacLake]

@requinix

 

8 hours ago, requinix said:

- System takes Shopping Cart details associated with PHPSessionID and links them to the new Member record

Do you care about storing shopping carts with an account? Some sites do, some sites don't. If you don't care then you don't have to do that step.

I have designed the "shopping cart" to be a database record regardless of whether a person a first-time shopper and doesn't have an account, or the person is a repeat customer and has an account.  (I think most people just use cookies, but I've never really liked or undestood using cookies.)

So the moment a person chooses "Add to cart", things should get written to the database to provide some permanency.

 

 

8 hours ago, requinix said:

Look at your process this way:

If a worst case scenario was to happen between any two steps, would your process be able to recover gracefully from the failure? Will you lose any information? Will the data in your database be incomplete or otherwise corrupted?

For example,

- System runs the payment
- System hopefully gets back a "success" message from Payment Processor

One potential worst case here is that you submit a request to your payment gateway but the system blows up before it can receive the successful response. What would happen with the plan you've described? What should happen?
But be careful: I've chosen a particularly devious scenario for you to consider. The answer may surprise you.

Well, the process I described in my OP was "piecemeal", and I chose to create the Member record first since it is a parent table that kind of drives everything else, so I didn't want to lose that, plus I need that before I can add things the Order and Order Details.

 

I could wrap the entire process in a database transaction, but then the question becomes, "Do you ant an all or none approach, or is it better to at least capture some info like creating the Member record?"

I'm not sure of the best answer to that.

 

Sounds like you have some thoughts...

 

 

 

 

xxxxx

[requinix]

3 hours ago, SaranacLake said:

Well, the process I described in my OP was "piecemeal", and I chose to create the Member record first since it is a parent table that kind of drives everything else, so I didn't want to lose that, plus I need that before I can add things the Order and Order Details.

Sounds good.

 

3 hours ago, SaranacLake said:

I could wrap the entire process in a database transaction, but then the question becomes, "Do you ant an all or none approach, or is it better to at least capture some info like creating the Member record?"

A transaction is only necessary if you have to run multiple queries and the database is not in a consistent state until they've all executed.

[SaranacLake]

26 minutes ago, requinix said:

Sounds good.

A transaction is only necessary if you have to run multiple queries and the database is not in a consistent state until they've all executed.

Well, I have to think about that, and I suppose that is one reason I posted here...

There will be several tables that need to get populated in order for the checkout to reach a final state.

The question again is, "Should I make it all-or-none or allow a partial checkout and then allow the user to go back and try again?"

It seems to me that in the past n PHPFreaks, people encuraged me to create the Member record at all costs so that I had some way to reach out to people via email or whatever in case of a failed checkout.  (I think that makes sense.)

And if I had to guess, I probably need to wrap things like "Order" and "Order Details" into a transaction, because you cannot have an "order" if you haven't been paid - at least not with my business model.  Likewise, you cannot have a 'paid subscription if you haven't paid me, so I suppose any tables related to that should be in a transaction too.

 

But I welcome any thoughts from the PHP gurus here!  😉

 

 

[StevenOliver]

Great questions, SaranacLake! I want to know the answer to this one, too!

Here's my 2 cents:
When database queries are super-important, my code always does a "select" immediately after the "insert," just to verify the important data really got inserted properly.
So, maybe:
1.) Create a simple Member Record database (e.g. Username and ID)
2.) Create a 2nd database crossreferencing the Member Record with any data you can gather (shopping cart, session ID's, IP, date, time, etc.)
3.) Verify those records are created by doing a select after the insert
4.) If records created properly, then Payment Processor.
5.) Figure out how your PHP code will know if Payment was a success or not. I dunno this one. Maybe fun reading about event loops
6.) If success, php mail a "congratulations email" to customer
7.) If no success, php mail() yourself an error, so you can fix it quick.

I'll definitely watch this thread!

[SaranacLake]

@requinix,

Thanks for the responses above, but if I wasn't clear earlier, what I am really trying to figure out is how to handle things if the payment fails.

In that case, do I...

1.) Go ahead and create the Member, Order, and Order_Details tables, then display a message to the user that their payment failed, and ask them to contact me?

2.) Reload the checkout form leaving some fields "sticky" (e.g. username and email), but leaving others blank (e.g. password, payment details).  In this case I would *not* create any tables since I don't have their money yet.

 

Maybe approach #2 isn't "customer focused", but I'm not crazy about creating *incomplete* Member, Order and Order_Details records.  That seems like it creates a mess on the back-end for me, as well as from a customer-service standpoint.  Maybe that is how Amazon.com might do things, but I'm thinking it has more down-sides than pluses.

Or, if I don't take the #1 approach, am I a "jerk" and can I expect to lose sales when a payment fails?

 

*******

Fwiw, the reason I'm not crazy about approach #1 is that then that forces me to allow people to log into an account that they haven't paid for, and I'd have to build additional functionality to allow them to try to checkout again, and I'd have to put in extra logic to prohibit them from having access to the paid portion of the site and things like an online book they may have tried to purchase.

As I see it, it would be like a move theater letting you inside when your credit card failed while buying a ticket, and then asking you to wait in the lobby until you found another way to pay them.  (Or maybe giving you a large bucket of buttery popcorn, but telling you not to eat any while they try your card again...)

How well do you think that would work?

And think of how much work that would create for the movie theater and staff for that exception?! 

Just my 2-cents...

 

Edited July 31, 2020 by SaranacLake

[requinix]

9 hours ago, SaranacLake said:

1.) Go ahead and create the Member, Order, and Order_Details tables, then display a message to the user that their payment failed,

Always record data. A payment failing counts as data.

 

9 hours ago, SaranacLake said:

and ask them to contact me?

What.

 

9 hours ago, SaranacLake said:

2.) Reload the checkout form leaving some fields "sticky" (e.g. username and email), but leaving others blank (e.g. password, payment details).  In this case I would *not* create any tables since I don't have their money yet.

I think part of my problem with this thread is that I don't even understand why you would consider this idea.

Sign the user up. That's a separate step. Store the order data. That's a separate step. Take the payment information. That's a separate step. Attempt to process the payment information. That's a separate step. There is no reason why one of those steps resulting in a problem should somehow undo what happened before it.

 

9 hours ago, SaranacLake said:

Maybe approach #2 isn't "customer focused", but I'm not crazy about creating *incomplete* Member, Order and Order_Details records.

Even if you went for step #2 (which, to reiterate, is wrong), there's nothing incomplete here. A user is a user. Doesn't matter whether they have an order, let alone have successfully paid for an order. These are two completely different concepts. And the order has every reason to exist even if the payment didn't go through - again, always record data.

 

9 hours ago, SaranacLake said:

That seems like it creates a mess on the back-end for me, as well as from a customer-service standpoint.  Maybe that is how Amazon.com might do things, but I'm thinking it has more down-sides than pluses.

If the disadvantages outweigh the advantages when why would Amazon do it?

 

9 hours ago, SaranacLake said:

Or, if I don't take the #1 approach, am I a "jerk" and can I expect to lose sales when a payment fails?

It's not your fault the payment failed. (Probably.) You have no control over that. If it fails and the user aborts the order then sucks to be them.

 

9 hours ago, SaranacLake said:

Fwiw, the reason I'm not crazy about approach #1 is that then that forces me to allow people to log into an account that they haven't paid for,

You cannot store order data for an anonymous user. It's not good. The user must exist so that you can associate the order to it. That's fundamental ecommerce there.

 

9 hours ago, SaranacLake said:

and I'd have to build additional functionality to allow them to try to checkout again,

That's right. You have to do that.

 

9 hours ago, SaranacLake said:

and I'd have to put in extra logic to prohibit them from having access to the paid portion of the site and things like an online book they may have tried to purchase.

I'd say "you have to do that" but you already have: it's called "anonymous people don't have access to the paid portion of the site". The only difference now is that you need to tighten your restrictions to allow users who have also paid (or have an active subscription or whatever).

 

9 hours ago, SaranacLake said:

As I see it, it would be like a move theater letting you inside when your credit card failed while buying a ticket, and then asking you to wait in the lobby until you found another way to pay them.

Bad analogy. They don't let you do that because there's a high risk you'll sneak off to a screening while the staff aren't looking. Which totally does not translate to an ecommerce website.

 

9 hours ago, SaranacLake said:

(Or maybe giving you a large bucket of buttery popcorn, but telling you not to eat any while they try your card again...)

I cannot come up with a polite response to this one.

 

9 hours ago, SaranacLake said:

Just my 2-cents...

Do whatever you want. I'm out.

[SaranacLake]

@requinix

 

On 7/31/2020 at 10:53 AM, requinix said:

Always record data. A payment failing counts as data.

Why create an account if the payment fails?

 

On 7/31/2020 at 10:53 AM, requinix said:

I think part of my problem with this thread is that I don't even understand why you would consider this idea.

Sign the user up. That's a separate step. Store the order data. That's a separate step. Take the payment information. That's a separate step. Attempt to process the payment information. That's a separate step. There is no reason why one of those steps resulting in a problem should somehow undo what happened before it.

I wasn't proposing undoing anything, but rather not committing things.

 

 

 

On 7/31/2020 at 10:53 AM, requinix said:

Even if you went for step #2 (which, to reiterate, is wrong), there's nothing incomplete here. A user is a user. Doesn't matter whether they have an order, let alone have successfully paid for an order.

So if I create the user account and the payment fails, then what comes next?

Am I expecting them to log in and then try to checkout again?

 

On 7/31/2020 at 10:53 AM, requinix said:

These are two completely different concepts. And the order has every reason to exist even if the payment didn't go through - again, always record data.

Similar questions to above...

If I create an order and the payment fails, then what is the next step?

In other words, how do I tie the user and the order to what failed?

 

My setup is unique in that I am doing a one-stop checkout.  And I'm doing this because after reading lots of research from UI experts, they all say that to avoid "cart abandonment" you should make checkout as simple as possible!

So a shopper adds a membership plan to their cart and clicks "Checkout".  They are presented with a form asking for a username, email, password, and payment details.

If the payment succeeds, then the plan was to create the member account, create an order, and send them an email to activate their account.

I was thinking this way because if you haven't paid then you can't do anything on my site (e.g. view paid content).

I could make it so people can log in and maybe see the unfinished checkout, while restricting access to content, but that just seems like more work.

 

 

 

On 7/31/2020 at 10:53 AM, requinix said:

If the disadvantages outweigh the advantages when why would Amazon do it?

Well, I don't know what Amazon does on their backend, but they probably have a skyscraper full of developers and I don't!

 

 

 

On 7/31/2020 at 10:53 AM, requinix said:

It's not your fault the payment failed. (Probably.) You have no control over that. If it fails and the user aborts the order then sucks to be them.

If a payment failed it is likely they just didn't have enough available credit.  (Although maybe they fat-fingered their credit card number?)

 

On 7/31/2020 at 10:53 AM, requinix said:

You cannot store order data for an anonymous user. It's not good. The user must exist so that you can associate the order to it. That's fundamental ecommerce there.

Agreed.

 

On 7/31/2020 at 10:53 AM, requinix said:

> and I'd have to build additional functionality to allow them to try to checkout again,

That's right. You have to do that.

So if the payment fails, why can't I just re-display the checkout form with sticky data minus sensitive data like payment info?

It's pretty standard in PHP to just reload a form if their are data entry errors and let the user fix them.

Can't I do that on my checkout form?

 

 

On 7/31/2020 at 10:53 AM, requinix said:

I'd say "you have to do that" but you already have: it's called "anonymous people don't have access to the paid portion of the site". The only difference now is that you need to tighten your restrictions to allow users who have also paid (or have an active subscription or whatever).

So create the user account, create the order, tell them their payment failed, then what?

Require this new semi-user to log in?

(Do I force them to activate their account by verifying their email first?)

After they log in, then what?

Is their shopping cart still like before they checked out?

Do I try and have them complete their existing, unfinished order?

Do I have them try and checkout again, this time creating a *new* order?

Do I send them to "My Account" and somewhere in their have them find their incomplete order?

 

All of this may seem obvious to others, but I guess things I have purchased online have worked the first time, so I cannot recall a "recovery process" that I had to deal with.

Furthermore, I think this is trickier to me since I am selling an account and not a physical product like socks!    

 

 

[SaranacLake]

I can't say that I personally recall any websites where you are signing up for a paid membership, your payment fails, but the website still creates an account for you.

Can anyone else speak to this?

 

[SaranacLake]

@kicken,

Can you help out?

[kicken]

On 8/1/2020 at 5:56 PM, SaranacLake said:

I wasn't proposing undoing anything, but rather not committing things.

Not committing the changes is essentially undoing everything.

 

On 8/1/2020 at 5:56 PM, SaranacLake said:

Am I expecting them to log in and then try to checkout again?

Sure, why not?  That's exactly what someone who was already a member and needed to renew would be doing.

 

On 8/1/2020 at 5:56 PM, SaranacLake said:

If I create an order and the payment fails, then what is the next step?

In other words, how do I tie the user and the order to what failed?

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.

 

On 8/1/2020 at 5:56 PM, SaranacLake said:

I could make it so people can log in and maybe see the unfinished checkout, while restricting access to content, but that just seems like more work.

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.

 

On 8/1/2020 at 5:56 PM, SaranacLake said:

Although maybe they fat-fingered their credit card number?

That is something you can and ideally should catch client-side with JS before the form is submitted.

 

On 8/1/2020 at 5:56 PM, SaranacLake said:

So if the payment fails, why can't I just re-display the checkout form with sticky data minus sensitive data like payment info?

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.

 

On 8/1/2020 at 5:56 PM, SaranacLake said:

So create the user account, create the order, tell them their payment failed, then what?

Require this new semi-user to log in?

(Do I force them to activate their account by verifying their email first?)

After they log in, then what?

Is their shopping cart still like before they checked out?

Do I try and have them complete their existing, unfinished order?

Do I have them try and checkout again, this time creating a *new* order?

Do I send them to "My Account" and somewhere in their have them find their incomplete order?

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.

 

On 8/2/2020 at 8:13 PM, SaranacLake said:

I can't say that I personally recall any websites where you are signing up for a paid membership, your payment fails, but the website still creates an account for you.

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.

 

Edited August 7, 2020 by kicken

[SaranacLake]

@kicken

Very nice, and thoughtful response!

 

On 8/7/2020 at 3:16 AM, kicken said:

> Am I expecting them to log in and then try to checkout again?

Sure, why not?  That's exactly what someone who was already a member and needed to renew would be doing.

Except, if you are already a Member, then you know you have an account, so it follows you would log in.

One concern about creating an account for a new Member is that they might not know that I created an account for them in the background - and considering this is a one page checkout, it sorta implies it is an "all or none" process.

 

On 8/7/2020 at 3:16 AM, kicken said:

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.

So are you implying that regardless of the other stuff we are discussing, that I should wrap the CREATE MEMBER and CREATE ORDER in a MySQL transaction?

 

 

On 8/7/2020 at 3:16 AM, kicken said:

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.

Yes, you remember correctly.

And, yes, I do have to build my renewal module to force them to log in before they can renew.

I'm just not crazy from a UI/flow standpoint of surreptiously creating an account in the background when the creation of a Member is on the single-page checkout form, and if the payment fails, I think most people assume their account was not created.

I guess I can re-direct them to an error page stating that their payment failed, and asking them to log in to try again...

But since I also require the user to activate his/her account by clicking on a link in an email I send them, again, all of this is an awkward UI/flow.

(If it was me signing up for the first time, I'd rather the checkout page was re-loaded, and I was forced to re-enter my password and credit card details.)

 

 

On 8/7/2020 at 3:16 AM, kicken said:

That is something you can and ideally should catch client-side with JS before the form is submitted.

Unfortunately I don't know Javascript, so that is a version 2.0 thing.

 

 

On 8/7/2020 at 3:16 AM, kicken said:

> So if the payment fails, why can't I just re-display the checkout form with sticky data minus sensitive data like payment info?

 

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 account 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.

Well, in that scenario, I think having not committed anything, and thus not created an account, would be easiest.  (Never having been a Member before, if you come back in 3 days, you are likely to have forgotten where you left off, and if you have to remember what your username/email that you used were, and remember your password - which is hopefully unique - then that could cause real confusion, right?

I could email the potential Member an e-mail stating an account was created using username/email (blah), and state that the person will need to log in and try checking out again, but in the scenario that you described, that just seems messier to me than having things fail the first time with no account created, and then you come back when you come back and start fresh - with the ability to use the same username/email/password.

(Of course, IF I had a sales/marketing/customer retention dept, I would get yelled at for not capturing the user's details and creating a crippled account, because that provides a way to harass people to finish signing up, but them I'm not that kind of person/business, i.e. all about the $$$...)

 

 

On 8/7/2020 at 3:16 AM, kicken said:

Ultimately, this entire thread just boils down to "Pick something, and do it"

Yeah, just didn't want to choose a path that was destined to fail...

 

 

On 8/7/2020 at 3:16 AM, kicken said:

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. 

Not having ever build an ecommerce site before, and never having used my merchant account, I cannot really comment on what I would want/need, BUT you make a good point there about being able to field emails/calls on, "Why did my payment fail?"

 

 

On 8/7/2020 at 3:16 AM, kicken said:

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.

That was/is my concern, although I mentioned how that can be addressed...

 

 

On 8/7/2020 at 3:16 AM, kicken said:

Option n) whatever other way you can think of.  Weigh it's pros and cons.

Yeah.

 

 

On 8/7/2020 at 3:16 AM, kicken said:

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. 

Yeah, I am just exhausted t=with this never ending site and am afraid I'm gonna make so fatal design decision on my ecommerce module and this will never get done.

(This must be what it feels like when a Ph.D. student is starting their dissertation?!)  😕

 

 

On 8/7/2020 at 3:16 AM, kicken said:

If it were me, I'd lean toward option 2 and putting in the work necessary to track all the payment details.

Do you prefer fixing the incomplete Order, or leaving it orphaned and creating a second one?

 

 

On 8/7/2020 at 3:16 AM, kicken said:

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.

Yeah, a lack of Javascript is a weakness of mine, so that is out.

And I am already scrapping the design I had last year which was a "traditional" sign up process like PHPFreaks uses.  But as mentioned, I research UX/UI, mobile, and  cart-abandonment AT LENGTH, and all of the research says, "Make checkout as quick and easy as possible, where you create the account and get the $$$ all in one step!"

(I still want the user to verify their email using account activation, but I am delaying that until after I get their $$$.)

 

 

On 8/7/2020 at 3:16 AM, kicken said:

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.

Good point, and yes, I do offer a "30-day Trial for $1" where I use the exact same checkout process as we have been discussing, but the only difference is I only charge $1.  (Would need to address my concerns above in the same way as a full annual subscription on a new user.)

 

I appreciate you taking time to spell out different options and your reasoning!

 

I guess ultimately I can program your Option #1 or Option #2, I just personally lean towards the easy (for the user) option.

But I think I need to kick all of this around some.

 

Fortunately tonight and tomorrow, I am setting up the tables and such in MySQL, so i don't need a decision just yet.  (And implementing either approach will NOT impact my database design which I have spent like the last year working on?!  And which *should* be bullet-proof...)

 

In closing, if I had one wish before I die - "figure of speech", God - it would be to finish this damn website and to see it successfully "go live"

This is worse than the worst tooth-ache ever....