Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 2 of 2 FirstFirst 12
Results 16 to 22 of 22
  1. #16
    New Coder
    Join Date
    Jul 2009
    Posts
    20
    Thanks
    2
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by mlseim View Post
    I would still add a new record and save it at stage 2.
    Ok, that is very helpful. You advice me to add the data directly after submitting. The status field is required from iDEAL, because iDEAL is providing the status of the payment and will updating it automatically.

    If you look at my webshop ordering proces in 5 stages:
    1) shopping cart
    2) customer information
    3) payment
    4) delivery
    5) confirmation

    Now I have stored the products from the customer in a session at stage 1. Should I also insert the products from the shopping cart directly in the database after stage 1 or should I wait for the payment proces at stage 3?

    The reason I am asking this is because people can add products to the shopping cart before the payment proces. A scenario: customer has 3 items in shopping cart (stored in session) and go through the customer information at stage 2. At stage 3 before the payment, he is thinking I need another item and go back to the webshop. The item will be add to the session with in totaal 4 items. And proceed it at stage 3.

  2. #17
    Master Coder
    Join Date
    Jun 2003
    Location
    Cottage Grove, Minnesota
    Posts
    9,512
    Thanks
    8
    Thanked 1,090 Times in 1,081 Posts
    My "status field" is about a field in your MySQL database.
    You are talking about a status field you are giving iDEAL. Not the same thing.

    I keep mentioning MySQL because once they pay, how will you know what
    they ordered, who they are, and where they live? And without a database, how
    will you know what the status is?

    I'm thinking along these lines ...

    You don't require a customer (person) to log in. So, when someone adds 1 item to
    a shopping cart, a "customer ID" is created (a PHP SESSION variable contains the ID).
    The 1 item is added to the database associated with that ID. Every other item they
    add gets added as a new row in the database.

    If the user checks out, you query all rows with the ID ... that's their cart contents.
    You also go to step 2, so you update every one of their rows (ID) with their info.
    (name, address, phone, etc).

    If the user closes their browser before step 2, you lose the session ID. If they come back, you have
    no idea who they are, but their previous items remain in the database. As an admin
    function, if a session ID is lost, you simply delete all of those shopping cart items, and
    return those items to inventory. You have to, because you never got to step 2, so you
    don't know who they are.

    By not having anyone log-in, you will have the same problem with any system you use,
    because any session variables are lost when the user leaves and closes their browser.

    When they are ready to check out and pay, you query the database and build the
    variables you need for sending to iDEAL ...

    If the customer comes back in 2 days, they can enter their email address or some ID
    code you give them and they can check their order status ... remember you will have
    all of their items still in the database.

    This whole thing affects the inventory for everyone else, because you might have
    50 people shopping at the same time ... and 10 of those people might be adding
    T-shirts to their shopping cart. What if you have 3 shirts in inventory, and 5 people
    want to add them to their cart? You need to adjust inventory in REAL TIME. If 2
    of the people decide to bail-out before paying, you need to purge their carts and
    return the shirts to inventory.

    That's the point of using OSCommerce, Magento, or some other script.
    They have the programming already done for you.

    You have a big project ahead of you.
    You have to think about the whole operation ... what if 50 people are shopping at the same time?

    Also ... you have to control the database of items (inventory) in REAL TIME.
    Your "session" shopping cart idea is going to be a problem without a database, unless you only have 1 customer at a time.


    Good luck.
    Last edited by mlseim; 02-16-2010 at 01:50 AM.

  3. #18
    New Coder
    Join Date
    Jul 2009
    Posts
    20
    Thanks
    2
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by mlseim View Post
    I keep mentioning MySQL because once they pay, how will you know what
    they ordered, who they are, and where they live? And without a database, how
    will you know what the status is?
    I will use a MySQL database to store the items of the shopping cart and customer information. But I am wondering at which stage I add those data to the database.

    Your explaination for storing the items directly in the database is great. But I was thinking to a different approach.

    A customer adds 1 item to a shopping cart. The item will be stored in a PHP SESSION with the ID of the item. So, this part differs from yours, because you add the item directly in the database and I am storing it in a temporary SESSION. Every item they add will be added to another SESSION with the ID of the item.
    Still the customer don't need to log in. If user checks out, the total amount of price will be calculated by the SESSIONS.
    User go to step 2, fill in his information. The information will be added to the database when submitting the form. Still, the shopping cart will be remembered by the SESSIONS

    If the user closes the browser before step 2, the SESSION will be destroyed, simple as that. And when the user checks out and pays, I can add the items from the SESSION to the database after stage 3 (after payment). The variables will be build from the SESSIONS for iDEAL.

    At stage 2 they will create an account by entering their e-mailaddress and a password. For the next order they can use their account.

    What do you think of my approach by using the SESSIONS till stage 3 and add it in the database if I am sure the user is paying for the items?

    I know I can use existing webshop, but they are too heavy for a small webshop that I am building.

  4. #19
    Master Coder
    Join Date
    Jun 2003
    Location
    Cottage Grove, Minnesota
    Posts
    9,512
    Thanks
    8
    Thanked 1,090 Times in 1,081 Posts
    Your way will work fine if there isn't an inventory issue.
    Perhaps your shop only has a small amount of items, or it doesn't matter
    if several people are shopping at the same time. Maybe you won't even
    have a need for a database for your items?

    So, if that's the case, you can go with your sessions idea (or cookies if want).

    The harder part will be to save your shopping cart into a database, or perhaps you
    won't use a database ... email the shopping cart to the store admin person for
    shipping purposes? You really don't need a database? Something to think about.

  5. #20
    New Coder
    Join Date
    Jul 2009
    Posts
    20
    Thanks
    2
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by mlseim View Post
    Your way will work fine if there isn't an inventory issue.
    Perhaps your shop only has a small amount of items, or it doesn't matter
    if several people are shopping at the same time.
    Indeed, there is no inventory issue, since the concern of the webshop has a large amount of each product. And the webshop has small amount of items. That is also the reason not to point real-time indication of the amount of items for each product, since this will be always in stock.

    Quote Originally Posted by mlseim View Post
    The harder part will be to save your shopping cart into a database, or perhaps you
    won't use a database ... email the shopping cart to the store admin person for
    shipping purposes? You really don't need a database? Something to think about.
    Why is saving the shopping cart to the database the harder part?

    No, I must work with database, because the service of the webshop is to give customer (with an account) a list of orders they can find it back for bookkeeping or taxes for example.
    Also, when the payment with iDEAL failed for the first time, they can proceed the payment a second time without going through all the stages. They can log in on their account and pay it directly with iDEAL in a single stage.
    Furthermore, the admin of the webshop is receiving an e-mail with the shopping cart of the customers. Also the customer itself will receive one.

  6. #21
    New Coder
    Join Date
    Aug 2003
    Location
    Derby, UK
    Posts
    97
    Thanks
    0
    Thanked 14 Times in 14 Posts
    Every owner of an online shop I have ever worked for would want to capture customer information associated with an order and most would want to capture it associated with an attempted or incomplete order, i.e. as early as possible.

    You need to seperate the idea of creating a customer account for future use (optional) with storing information required for fulfillment of the order. Unless there are no goods associated with the transaction you should record all customer information regardless of if it is a one-off order or not and if they have a problem with payment wouldn't it be better to still have a record of their details and the order details so that the shop owner can choose to email or phone them to say e.g. "I am sorry you had a problem purchasing this item, is there anything I can do to help?".

    Also consider whether the shop owner may want some form of customer relationship management functionality e.g. the chance to email previous customers with special offers? In this scenario it is better to record as many details as possible.

    Of course a particular shop owner may choose not to do anything with user info if they view it as spam/anti-privacy etc. but if this is code to beused in multiple scenarios then some will almost certainly see it differently?

    Next consider bugs - in an ideal scenario of course there are none, but if there are and orders are not completing (maybe a problem with payment API) then it is helpful to see them and be able to try to see a pattern?

    Lastly consider statistics - it is useful to a webshop owner to see where in the order process people are abandoning. You could record this just as a set of numbers for how many people got to each stage, but for the purposes of tracking down why they abandoned it can be helpful to have order and customer info (e.g. Mr M Mouse of Disneylanf probably isn't worth worrying about abandoning).

    In summary form a technical POV either will work, but for me more data is better (unless you have load issues) so I would record order info and customer info early, if you find you need it you will be grateful and if it is never actually used, well no great loss?

    HTH,

    Dai

  7. #22
    New Coder
    Join Date
    Jul 2009
    Posts
    20
    Thanks
    2
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by DaiWelsh View Post
    Every owner of an online shop I have ever worked for would want to capture customer information associated with an order and most would want to capture it associated with an attempted or incomplete order, i.e. as early as possible.
    So, you recommended me to add the info as soon as possible in the stages? In other words, add the items for the shopping cart at stage 1 to the database instead of at stage 3 (after payment)?

    Quote Originally Posted by DaiWelsh View Post
    Also consider whether the shop owner may want some form of customer relationship management functionality e.g. the chance to email previous customers with special offers? In this scenario it is better to record as many details as possible.
    I had thinking about that, during customer information form (stage 2), they may choose to subscribe for the newsletter with special offers.

    Quote Originally Posted by DaiWelsh View Post
    You could record this just as a set of numbers for how many people got to each stage, but for the purposes of tracking down why they abandoned it can be helpful to have order and customer info (e.g. Mr M Mouse of Disneylanf probably isn't worth worrying about abandoning).
    I agree that this is good for the statistics of the webshop to find out where something is not going well for sales. But it is a quite small webshop and the webshop owner isn't that interested to know what item will not be sold and what is a topsell-item. However, I will keep this in mind for future improvement.


 
Page 2 of 2 FirstFirst 12

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •