Jump to content
Kuuzu Forum


Popular Content

Showing content with the highest reputation since 11/12/2018 in all areas

  1. 2 points
    I think that's the ticket. Dan
  2. 1 point
    OK, I can see customers as being reluctant to create an "account" because they're afraid it gives the store permission to keep data around for a long time (reality: most data needs to be kept for business/tax/regulatory reasons anyway) they're afraid that having a "long term" relationship with a store (an account) will mean they're innundated with spam (reality: most mailings should be controlled by explicit opt-in selections that can be revisited at any time) remembering yet another account name and password is a PITA (using their email address is better than an arbitrary account name they'll forget) Almost all of the information you would collect for an account is needed anyway for processing an order, so it's not that much more work for the customer the first time around. Giving keys or tokens to a "guest order" to access order status, write reviews, make returns, etc. is a possibility, but the big prize (for customers) is not having to enter everything again, once their email is recognized. You can't keep credit card numbers, etc. without going full PCI-DSS compliant, but does keeping the shipping address, phone number, etc. violate any regulations if access is not password-controlled? An email address is fairly public knowledge, so would it be a security problem to prefill fields based on an email address that the store has seen before? Or should it require a password to retrieve such information? How about allowing access to writing/editing reviews, and checking order status? The confirmation email could have links in it (with tokens) to perform these actions, which could be used as passwords. Or, the customer could create an account at any time (by giving a password), and streamline their interaction that way. So, the basic checkout interaction could work this way: enter your email first, and if it's known, ask for a password if there is an account. If the customer does not log in with a password, ask for all shipping information. If they do log in, prefill the shipping information, etc. Ask (if they do not have an account) near the end if they'd like to create an account by giving a password. In the confirmation email, give links with long tokens to check order status, enter a review, or create an account with a password (if they did not have an account). If the customer realizes later than they did in fact have an account (or had forgotten their password), and had checked out as a guest, they would need some way to pull that order into their account (another link, if the email is recognized?). It gets more complicated to merge two accounts if they used a second email, or otherwise created another account, but it should be possible. Would this work, as a normally guest checkout that allows account creation (with a password), and access to various functions via link with token regardless of whether they have (or used) an account? To encourage account creation, what sort of functions or goodies should be available only to those with accounts (cross selling, upselling, "you also viewed", a formal wishlist, prefilled shipping address, etc.)? For "guest" checkouts, what should be the protocol if the shipping address or contact information changes? The email address should receive a copy of the order anyway, plus the changes, just in case something fraudulent is going on. Checkout flow: ask customer to enter their email not seen before? ->(A) seen before: account for this email? Yes: ask for password declines to log in, or gives wrong password? ->(A) gives correct password within 3 tries prefill shipping address and contact info (if customer changes anything, note that in conf. email) No: no account associated with this email (and repeat customer) (A) merge point enter shipping address and contact information if no account for this email, ask if want to create an account Yes: enter password twice, store hash in new account entry ask customer to enter payment information
  3. 1 point
    The short answer is "no". 2.4 is an "on the fence" release designed to pacify those people who want a forward movement from the official osc, whilst also pacifying those who want to stay "close" to how 2.3 works. The longer answer: 3.0 (which was in its time, absolutely the most brilliant piece of code I had ever seen) was unreleased. I won't say why it was unreleased but it was a personal choice of HPDL to nuke it. Prestashop (which is now well regarded, has, at its core, that 3.0 code). So, 2.4, with some backports from that older 3.0 - would be a hammer. Backports such as products class, attribute variants, and so on. I'm not sure how many look at the CE (the community bootstrap code)...in that there is a cool Category_Tree class - this comes from v3. There is so much fantastic code in V3...osC could have been #1 cart easily, and I mean it would have hammered the other carts brutally.