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. 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? 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. 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. 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. 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. 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. Any thoughts or objections? -- Brandon Craig Rhodes [email protected] http://rhodesmill.org/brandon --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
