On Thu, Sep 17, 2009 at 10:55 AM, Brandon Craig Rhodes < [email protected]> wrote:
> > I have some questions about check-out. > > When someone starts the GetPaid check-out process, an Order is created > that holds a reference to the current user's shopping cart. If the user > makes it through the wizard and pays for the order, then the code inside > of PloneGetPaid.browser.checkout.CheckoutReviewAndPay.makePayment() both > marks the Order as "authorized", so that the store owner knows to get > the goods ready to ship (or whatever), and also empties out the user's > shopping cart. > > My questions: > > 1. Mightn't it be better if the Order were responsible for emptying its > shopping cart - to which, I believe, it holds a reference - when it > sees that its state is moved to "authorized"? It seems rather clunky > for a mere browser view to be the key place, in all of GetPaid, where > the authorization of an order and the emptying of a cart are linked. > > Sounds good to me. > 2. Is the fact that the cart gets emptied when the Order is authorized > really a specific feature of PloneGetPaid in particular, or is this a > candidate for being moved, someday, out into a more generic GetPaid > module so that all GetPaid implementations in the future share this > behavior with Plone? > > Doesn't seem to be specific to the Plone product. > 3. Should the shopping cart really get simply emptied? It would seem to > me that an Order, upon creation, should make a copy of the current > Shopping Cart and carry that static lists of goods as the shopper > goes through the checkout wizard; otherwise, the user could be > changing the cart in another window in between checkout steps. > (Though maybe I'm being paranoid and there's no problem with each > step of the checkout seeing different cart contents?) Anyway, my > point is that the total amount shown above the "Make payment" form > might, by the time it's pressed, be out-of-date if the shopper has > added more items to their shopping cart in between bringing up that > make-payment view and actually paying. Imagine a shopper who starts > adding more items while their spouse is off in the other room getting > the credit card, for example. It seems to me that what the Order > should actually do is not to blithely empty the whole shopping cart, > but rather to subtract out of the shopping cart all of the items that > were just purchased. If the user went to the trouble of adding more > items beyond those already represented in the total they are paying > for, then making those items disappear silently seems rather > unhelpful. Instead, we should leave un-paid-for items in the cart in > case the user put them there deliberately and is planning another > visit to the checkout wizard to buy them. > > Do many of the offsite processors give you the ability to change the cart contents? Or is this more about the injection of contents via malicious use of a form? Either way, good to be paranoid here :). We don't want the store owners to have problems akin to sql injections many of the php-based systems suffer from vulnerabilities for. > That question might sound silly in the case of the built-in native > checkout processor, but I think it becomes more important with the > integration of off-site processors, because we can't quite control what > happens out there. Imagine what would happen if the off-site process > stalls for a while, or even if an XML message we're supposed to get back > announcing that the authorization took place is delayed minutes because > an IP route has temporarily failed. It could be three minutes later > that we get the signal that the purchase succeeded and was authorized, > and, in case the user has continued shopping in the meantime, it would > be nice to just remove from the cart all of the things they paid for, > rather than for new items they might have added. > > Agreed. Also, if they removed something from the offsite cart, that would remain in the cart (and not be part of the order). This may pose a more serious threat (ie reduce overall cost simply by removing line items and hope that the onsite cart thinks you bought them all offsite). > Of course, all of the above is predicated on the off-site processors > (whose better integration, you will recall, I am currently trying to > design) working pretty much the way the on-site one does: by touching > the cart only twice during the process, once to get a copy of the goods > that will be paid for, and then once to empty the cart when the purchase > succeeds. If we go with a different scheme, the above problem might not > arise. > > One solution, which I think is terrible, is to empty the cart right as > the user *starts* the off-site check-out process. This destroys all of > the buyer's hard work in case the redirection fails, or if there's a > glitch in their attempt to check out; they have to then re-build their > shopping cart all over again (or, more likely, abandon the idea of > buying from your store). > > Another solution would be to "freeze" or specially mark the current > items when check-out begins, so that they were distinct from any new > items added to the cart, and so that the user would have to be > deliberate (maybe by clicking on an "Start purchase over again" button) > if they wanted to start over with paying for those items. > > Hmm...that seems not so user friendly. I've often started a checkout and then navigated back somewhere in the site. Even today bought something on Amazon and right at last step realized I really wanted to see the exact prices of what was in the cart. There wasn't a way to navigate back so I had to leave checkout process. Perhaps instead we have some kind of locking based on the user having gone offsite for credit card processing? This could tie into the idea of tracking statistics on the shopping process (ie # of carts filled, started checkout, at which stage of checkout, completed checkout). Maybe the waiting for an offsite payment could just time out (I imagine lots of processors have a time out built in...). So a cart would be in a state of "offsite payment pending" till that expired and then it just went back to shopping/checkout started?? But, I think that both of these approaches - emptying the cart > immediately, or at least freezing the items inside - are small > disasters. I like how Amazon works: I fill a cart, I check out, and > anything left over because I added it in the meantime remains in my > cart. At any time I can leave the checkout process by returning to > Amazon's home page, and my shopping cart is sitting there safe and sound > with everything still in it. > > Agreed :) > So, while I'll entertain arguments for any of these approaches, I > suppose I'm really just looking for the go-ahead to (a) make > shopping-cart-emptying something that the Order does rather than that > the UI has to remember to do, and (b) make it selective, so that it only > removes from the cart the items that were purchased. > > Sounds great! =c > Any thoughts or objections? > > -- > Brandon Craig Rhodes [email protected] > http://rhodesmill.org/brandon > > > > -- Cofounder and CEO ifPeople - Innovation for People www.ifpeople.net t: 678-608-3408 130 Boulevard NE, #6 Atlanta, GA 30312 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "getpaid-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en -~----------~----~----~----~------~----~------~--~---
