Re: Cart ID Duplication
This WebDNA talk-list message is from 2001
It keeps the original formatting.
numero = 36722
interpreted = N
texte = We 've abandoned the purchase command for this reason-the error message confuses and annoys the heck out of people. Now, if they understood the mechanics of how browsers (and the internet in general for that matter) function, you'd have half fighting chance. But they don't, so you have to make it as idiot proof as possible.FWIW, we're testing the following system:1) On a shopper's first visit, set a session cookie to [cart] 2) Record all the order info to orders.db, inlcuding the [cart]. This is done with [replace], so they can do all the fiddling they want before they checkout for good. We use Payflow Link from Verisign, which sends us a variable user1 that tells whether the transaction has been successful or not. We use this in place of the purchase command for the above listed reasons 3) If user1 returns T (in other words, a valid order has been made), we set a cookie that is exclusive to the user. This cookie is recorded in orders.db. Then, when a shopper returns next time, we test for this cookie, which autofills the forms with their pertinent data from orders.db. 4) This frees us, as far as I can tell, from caring which cart # they use. They can use one from a previous order, one from last week Wednesday, or from five minutes ago. We're cart agnostic! 5) On the top of every page (and I mean EVERY page), we have placed an include file that checks the shopper's cart against the database. If they are a returning customer, i.e., if the [GetCookie RegularUserID] tests positive, they can use any cart they want - either a new one or one from one of their previous orders. If they are new shopper, we check their cart number against the database, and if the regular customer test fails, yet they have a cart number that's recorded in the database, they are issued a new cart number.It's worked well in testing so far. Anyone see any glaring holes in the logic??Will Starck Product and Technical Support Staff NovaDerm.com http://www.novaderm.com techs@novaderm.com 800-378-1740----- Original Message ----- From: Mark Derrick
To: WebCatalog Talk Sent: Tuesday, June 26, 2001 11:59 AM Subject: Re: Cart ID Duplication > on 26/6/01 5:20 pm, Bob Minor at bob@cybermill.com wrote: > > > On 6/26/01 11:10 AM, Donovan Brooke wrote: > > > >> This appears to be a cart cache thing. I am new to WebCat but just wanted to > >> say that I am having a similar issue on our development site. The remove > >> lineitems > >> button we have sometimes removes and sometimes doesn't. I think there are a > >> couple > >> cache things going on. Maybe server, maybe browser. A quick search (cart > >> cache) > >> in the archives brings up many related posts. Here is one: > > I use the this process to help the customers. > > > > Customer visits site, gets a cart, completes the purchase and lets say > > bookmarks the thankyou page. I delete the cart file, but store all the data > > in a database. > > > > They then return using the bookmark. They add things to the new cart which > > has the same number as the old cart. When they are ready to check out they > > click the check out button. I test to see if the cart is in the database if > > it is I redirect them to the another page like this > > shoppingcart2.tpl?file=[cart] then on shoppingcart2.tpl I copy the data from > > one file to another [movefile > > from=shoppingcarts/[file]&to=shoppingcarts/[cart]] and redirect them to the > > checkoutpage.tpl?cart=[cart]. You can even check to make sure cart is unique > > to your database and do it again if its not. > > > > Now they have a new cart number without ever having known they had a > > duplicate and they go about there merry way sending me more money. > > > > Robert Minor > > Director of Internet Services > > What about the scenario where someone is deep-linking to your site > (annoying, but they do do it!), and within the URL that they've embedded in > their link is a cart ID? > > You then get several different people all coming to your site with the same > cart ID? > They get all the way until the point where they're ready to confirm the > purchase, only to be told that the cart has already been submitted, and > awaiting approval > > Although this isn't the problem we're currently have, it has exactly the > same problem. > > > ------------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > Web Archive of this list is at: http://search.smithmicro.com/ ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/
Associated Messages, from the most recent to the oldest:
We 've abandoned the purchase command for this reason-the error message confuses and annoys the heck out of people. Now, if they understood the mechanics of how browsers (and the internet in general for that matter) function, you'd have half fighting chance. But they don't, so you have to make it as idiot proof as possible.FWIW, we're testing the following system:1) On a shopper's first visit, set a session cookie to [cart] 2) Record all the order info to orders.db, inlcuding the [cart]. This is done with [replace], so they can do all the fiddling they want before they checkout for good. We use Payflow Link from Verisign, which sends us a variable user1 that tells whether the transaction has been successful or not. We use this in place of the purchase command for the above listed reasons 3) If user1 returns T (in other words, a valid order has been made), we set a cookie that is exclusive to the user. This cookie is recorded in orders.db. Then, when a shopper returns next time, we test for this cookie, which autofills the forms with their pertinent data from orders.db. 4) This frees us, as far as I can tell, from caring which cart # they use. They can use one from a previous order, one from last week Wednesday, or from five minutes ago. We're cart agnostic! 5) On the top of every page (and I mean EVERY page), we have placed an include file that checks the shopper's cart against the database. If they are a returning customer, i.e., if the [GetCookie RegularUserID] tests positive, they can use any cart they want - either a new one or one from one of their previous orders. If they are new shopper, we check their cart number against the database, and if the regular customer test fails, yet they have a cart number that's recorded in the database, they are issued a new cart number.It's worked well in testing so far. Anyone see any glaring holes in the logic??Will Starck Product and Technical Support Staff NovaDerm.com http://www.novaderm.com techs@novaderm.com 800-378-1740----- Original Message ----- From: Mark Derrick To: WebCatalog Talk Sent: Tuesday, June 26, 2001 11:59 AM Subject: Re: Cart ID Duplication > on 26/6/01 5:20 pm, Bob Minor at bob@cybermill.com wrote: > > > On 6/26/01 11:10 AM, Donovan Brooke wrote: > > > >> This appears to be a cart cache thing. I am new to WebCat but just wanted to > >> say that I am having a similar issue on our development site. The remove > >> lineitems > >> button we have sometimes removes and sometimes doesn't. I think there are a > >> couple > >> cache things going on. Maybe server, maybe browser. A quick search (cart > >> cache) > >> in the archives brings up many related posts. Here is one: > > I use the this process to help the customers. > > > > Customer visits site, gets a cart, completes the purchase and lets say > > bookmarks the thankyou page. I delete the cart file, but store all the data > > in a database. > > > > They then return using the bookmark. They add things to the new cart which > > has the same number as the old cart. When they are ready to check out they > > click the check out button. I test to see if the cart is in the database if > > it is I redirect them to the another page like this > > shoppingcart2.tpl?file=[cart] then on shoppingcart2.tpl I copy the data from > > one file to another [movefile > > from=shoppingcarts/[file]&to=shoppingcarts/[cart]] and redirect them to the > > checkoutpage.tpl?cart=[cart]. You can even check to make sure cart is unique > > to your database and do it again if its not. > > > > Now they have a new cart number without ever having known they had a > > duplicate and they go about there merry way sending me more money. > > > > Robert Minor > > Director of Internet Services > > What about the scenario where someone is deep-linking to your site > (annoying, but they do do it!), and within the URL that they've embedded in > their link is a cart ID? > > You then get several different people all coming to your site with the same > cart ID? > They get all the way until the point where they're ready to confirm the > purchase, only to be told that the cart has already been submitted, and > awaiting approval > > Although this isn't the problem we're currently have, it has exactly the > same problem. > > > ------------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > Web Archive of this list is at: http://search.smithmicro.com/ ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/
Will Starck
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
Errata: WCS Newbie question (1997)
Subtotal Not Calculated on Invoice.html (1998)
REALLY need a hand (1999)
Running 2 two WebCatalog.acgi's (1996)
Weird Math (2000)
Search results templates (1996)
WebCat Classes (2000)
WebCat2b13MacPlugIn - [include] (1997)
Sorry I didn't pay attention-but ??? (1997)
Categories (2000)
Text data with spaces in them... (1997)
Less than or equal to........ (1997)
forming a SKU (1999)
[sendmail] and [formvariables] (1997)
Return records from another (1997)
creator code (1997)
Re2: frames & carts (1997)
Problems passing [SKU] with $Replace in 2.0 (1997)
Multiple Passwords (1997)
Security Question (1997)