Jump to content
SaranacLake

From Shopping to Checkout

Recommended Posts

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?

 

Share this post


Link to post
Share on other sites
- 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.

Share this post


Link to post
Share on other sites

@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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!  😉

 

 

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

@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 by SaranacLake

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

@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!    

 

 

Share this post


Link to post
Share on other sites

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?

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.