Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About SaranacLake

  • Rank
    Prolific Member

Profile Information

  • Gender
  • Location
    New York
  • Age

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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?
  2. @requinix Why create an account if the payment fails? I wasn't proposing undoing anything, but rather not committing things. 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? 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. Well, I don't know what Amazon does on their backend, but they probably have a skyscraper full of developers and I don't! If a payment failed it is likely they just didn't have enough available credit. (Although maybe they fat-fingered their credit card number?) Agreed. 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? 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!
  3. @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...
  4. 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! 😉
  5. @kicken All good advice, but I still worry... Good point. Yeah, that is sorta what I was hinting at in my OP - that hopefully having to change indexes or even keys after you go-live isn't the end of the world. In my mind, what is the most important is that you capture the right data and have the right relationships. For example, if you don't store "Order History", then later on you can't re-create it out of thin air?! And if you didn't have an "Order Details" table, but instead hard-coded 10 slots in your "Order" table, assuming no one bought 11 items, you would be safe, BUT you'd have a real mess to clean up later on!! Let's hope you are right about the "fatal" part!!! Well, hopefully i am at that point in my design where all of this is true. (Although I did find one problem area last night that I need to quickly re-work, but other than that, I think my database design is solid...) Thanks!
  6. @requinix 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. 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
  7. 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?
  8. So I am reviewing all of the pages and pages and pages of ERDs that I have, and hope to start building things in MySQL tomorrow. Those of you who know me, understand that I'm terrified of making some gigantic mistake on my website, and so I often tend to fret longer than necessary?! In abstract terms, where would you say people most commonly get into trouble when building databases from the ground up? Or put another way... What kind of database design mistakes tend to be "fatal"? My hope is that as long as I've included all of the necessary tables, and as long as I have things normalized (or denormalized where necessary), that everything else should be relatively easy to fix - for example changing data-types, adding/removing a few columns, changing indexes, etc. Thoughts on this?
  9. @requinix Okay, good to know. Okay. That being said, and knowing that I will be querying on Orders and Order Details, and knowing that I need a FK on Order_ID and Product_ID, then it sounds like you are suggesting that I create one index on {Order_ID, Product_ID) and then my second index simply on (Product_ID), correct? ...
  10. @kicken Hello. I wanted to get clarification on something we discussed a few months ago regarding FKs and Indexes... Let's say that I have a typical order system with these tables... ORDER - id (pk) and so on... PRODUCT - id (pk) and so on... ORDER_DETAILS - id (pk) - order_id (FK1)(UK) - product_id (FK2)(UK) and so on... A few things I recall you saying to me... - MySQL requires an index on all FKs. - Indexes work left-to-right, and so any column that needs to take advantage of an index needs to be in the 1st position when multiple columns are in the index. - If querying by Orders is more common, then I would want a FK like this: (order_id, product_id) - I would need another index for product_id. Question: 1.) In order to create an index for the Product_ID FK, and to provide for possibly querying on Product_ID, could my 2nd index be (product_id, order_id)? Having (order_id, product_id) and (product_id, order_id) indexes would help with my two FKs, and all me to query by either Order or Product. This seems like the best of both worlds, without a lot of overhead from unnecessary indexes. Thoughts?
  11. @maxxd Told you I was rusty on things!! So there is still a lot of application logic I have to figure out, but it sounds like upgrading to the HTML5 button tag should help me to address any situations where I need to have several command-type buttons on one web page, right? And another advantage is now I can just have one form, right?
  12. @maxxd My var_dump isn't displaying anything. Then I rewrite my code, tried this, but when I click on a button I don't get any results... <?php if ($_SERVER['REQUEST_METHOD']=='POST'){ // My code... var_dump($_POST); // Maxxd's code... $option = $_POST['option'] ?? ''; if ($option) echo "You chose $option<hr>"; } ?> <!DOCTYPE html> <html lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>Sample</title> </head> <body> <form> Select an option <button name="option" value="1">Choose me</button> <button name="option" value="2">Choose me</button> <button name="option" value="3">No, Choose me</button> <button name="option" value="4">No, Choose me</button> <button name="option" value="5">No, Choose me</button> </form> </body> </html>
  13. @Barand and @maxxd, I haven't actively coded PHP in nearly 5 years - which is a painful place since I am trying to finish the last 10% of a very complex code-base. 😞 I added a var_dump to Barand's code to try and undrstand what was going on, but it isn't working. What did I do wrong? <?php var_dump($_POST); // Added to show data associated with button click. $option = $_POST['option'] ?? ''; if ($option) echo "You chose $option<hr>"; ?> <!DOCTYPE html> <html lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>Sample</title> </head> <body> <form> Select an option <button name="option" value="1">Choose me</button> <button name="option" value="2">Choose me</button> <button name="option" value="3">No, Choose me</button> <button name="option" value="4">No, Choose me</button> <button name="option" value="5">No, Choose me</button> </form> </body> </html> Yeah, I came to that conclusion last night. (This is probably why on a related page that I started working on a while back I broke things up into 3 forms on one web page.) Yeah, that's a bummer. Okay, but why didn't my var_dump work?
  • 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.