On Sun, Nov 1, 2009 at 2:23 PM, Brandon Craig Rhodes <[email protected] > wrote: > > First: > > I am "-1" on destroying the cart. > I probably was not clear enough. This morning Lee Joramo drew a very useful diagram that shows what my proposal looks like. I just uploaded it to Google wiki, together with the email where I expose my ideas. Check it out at http://code.google.com/p/getpaid/wiki/NewOrderWorkflowProposal
> So, again, we should not destroy the cart until we know the customer has > succeeded in paying; and, second, when we do get payment notification we > shouldn't "destroy" the cart, we should just remove from it whichever > items were actually paid for, using the little list of items that PayPal > will send us back in their IPN message. I'm -1 about this because it doesn't fit my usecases (but I am aware I'm biased here) and because it seems harder to implement than necessary. > Second: > > I have a less strong opinion on creating an Order before they actually > leave the site. The issues would seem to be: > > Con > > * Orders are designed to hold information, but in this case there's > nothing to store except the fact that the user pressed "Checkout" and > left the site. You'd have all these orders sitting around with > nothing but an order number and a copy of a cart inside of them, > because the user reached PayPal and was annoyed with its interface and > decided not to check out after all. > I meant to ask for user info on our site before the payment, and have the paypal forms automatically filled with the data provided to us. > > (I don't know many store owners, I must admit, but rumor has it > that they tend to like customers to be as few clicks away from > finishing paying as possible!). This is why we should trat anonymous (no user/password) checkout as a first class citizen. In my experience, at least for the Italian users I'm used to and the kind of business I developed for, asking for a username/password is a thing that I need to avoid as much as possible. But, it seems to me that this mechanism uses space, time, and additional > complexity, in order to accomplish something that the off-site service > does anyway. > It does use space. I think store owners might be happy with the extra space requirements if it translates to a better user experience. But, I'm not an actual Store Owner, so I'm quite open to changing my > opinion here based on actual GetPaid users if they (or you) would like > to share more about how they actually use the service in practice. I'd like to hear more opinions about this too. What do you all think on this ML? > > We could then provide the "pay with paypal" button on the order > > summary page. > > Ah! I see! You are not advocating JavaScript, you're advocating > two-step checkout process: the person sees their cart and presses > "Checkout", then is shown their cart *again* and has to press "PayPal > Checkout" to actually go off-site. > Yes, I'm really positive this is not an issue. I never had the impression any of my users (I use the described approach in production, and it works well) had anything to complain about. > BTW, we should also fix the personal details form and separate "first > > name" from "surname": we can't programmatically split "Full name" when > > we pass it to paypal. > > I'm certainly not an expert on this area, but two objections immediately > occur to me: > > 1. Isn't the personal details page something that's a Plone-wide > standard and that we can't change? Surely we don't want that form to > change on the day that someone adds GetPaid to a site that's been > maybe running for years, and have to go back through and add two > names to all of their users before proceeding? > > 2. The first+last formula doesn't work everywhere in the world - nor > even with everyone in a large university. I think that's why Plone > has a free-form field. > > If PayPal needs first and last, I suspect that we will just have to do > our best using .split() and so forth with the normal Plone name field. > But, again, I could easily be wrong here! -1000: programmatically splitting name and surname can lead to weird results. I would never ever do that. > > One more issue: anonymous users can't see their own orders, so they > > wouldn't be able to pay with the described setup. > > Can they pay with my proposed setup? They would just click "Check out > with PayPal" and be immediately whisked off-site? > I'm actually proposing to change that, and ask for name/address before sending them to paypal. > > > We could solve this providing a token in the emails we send after the > > order is created; the token could be the md5 hash of the date and time > > of the order. ... What do you think? > > A strongly random UUID, not the date and time, is what is needed here > for each Order; but, aside from that, your idea is a very good one! > It's just like the Tracking links that lots of sites send out: because > no one else can guess a 30-character random string, the URL is > essentially private to whomever reads the email. That would be a nice > way for people (at least who type their emails correctly) to have a way > back to their Order. Plus, on the final Order page itself we could say > "to visit this later, bookmark..." and have the link there too. > Good, that should be some attribute on the order, randomly generated on order creation. This also leaves room for some improvement: in case we need the order url to expire, we could store an expiration date with the token and let the user ask for a new url in case it's expired, providing their email address. Silvio --~--~---------~--~----~------------~-------~--~----~ GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker) 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?hl=en -~----------~----~----~----~------~----~------~--~---
