Chaos - who wouldn't love that? ;)
* PayPal: > > This also provides its own @@getpaid-checkout-wizard, but the view > simply does an immediate redirect to PayPal. > > OPEN QUESTION: Like with Google Checkout, the question is, why? > Because it was easier than overriding the "Checkout" buttons? Or > because the extra step lets a few last variables and parameters be > put into place before the customer arrives at PayPal? I guess this is just because there were no 1) proper hooks 2) proper documentation how to create payment processors. See also one PayPal comment below. Little related to this open question PayPal and some other payment processors did (still do?) order handling in a bit wrong order by not destroying the cart on completion or destroying the cart prematurely when the checkout button is pressed. So, there you have it! No fewer than six separate techniques are used > in GetPaid payment processors for what are really amounts to four > separate situations: > > 1. Off-site processors that provide their own checkout wizards > (Google Checkout, ClickandBuy, PagSeguro, PayPal) PayPal and Google Checkout support also more tightly integration with the existing web site without 1) taking the user away from the site 2) managing the order on the payment processor site. The current plug-ins don't use them, however. Multiple Payment Processors > --------------------------- > > The "multiple payment processors" branches seem focused on processor > categories 3 and 4, as given in the above list: the processors that > require GetPaid to ask for the credit card number on-site. Multiple payment processor branch also should support off-site processors. Since off-site processors like PayPal need the action initiated by a form submission, the current multiple payment processor setup simply creates a prefilled form with hidden inputs and submits it using Javascript. I am not sure whether this is the best practice and promoted by PayPal, but it provides very easy integration for those crappy websites built with PHP :) > For these, > it introduces a new registration system. Instead of simply registering > themselves as providing IPaymentProcessor, these new-style payment > processors would have to actually use a custom ZCML registration that > looks like: IPaymentProcessor interface should have not references to the user-inteface or Plone (Products.PloneGetPaid) so that other Zope frameworks (BFG, Grok) can use it. > <paymentprocessors:registerProcessor > name="..." > i18n_name="..." > selection_view="..." > review_pay_view="..." > thank_you_view="..." > settings_view="..." > /> > > I am not sure what I think about special ZCML declarations; it seems to > me like the same information could be provided much more simply through > the adapter-registration mechanism we already use, and that class > properties with names like "thank_you_view" and "settings_view" would do > a fine job of pointing at the views that the payment processor wanted to > provide, without needing any ZCML. But that's probably my Grok > background showing through, and maybe there are view configurations done > behind the scenes here that I've not studied yet. Well... I thought everything in Plone should be configured through ZCML nowadays... are we redesigning the system *again*? ;) ZCML is teh shit, but "Grokking" packages is not widely available or well-enough documented to be used with Plone yet. We are barely getting rid of things *before* ZCML. Also note that the list of active payment processors is stored in portal_properties.payment_processor_properties. Very old fashioned, but Witchert recommended this practice in some plone-...@email, because 1) settings are very visible in ZMI 2) settings can be changed even if the payment processor breaks the site user interface. Everything could be done using adapter and actually I think that's a preferred method. It should quite trivial to change getpaid.multiplepaymentprocessors to use adapters internally instead of managing its own registry. On the other hand, the registry is very easy to read and understand, instead of hunting down adapters with "some parameters" and "stored somewhere". When adapters are used internally, payment processors opt-in to using Grokked packages if they want to depend on Grok. Also, I suggest adding "layer" attribute to ZCML declaration. This way payment processor customizations could be site specific by using a policy product layer. > That, of course, just leaves categories 1 and 2 as problems. multiplepaymentprocessor branch should handle those case as well. I think it's just matter of having more view hooks available (checkout button,etc.). > What if this list was something built dynamically? What if the default was something like a series of views like this: Could we use those Plone browser layers here somehow? It is the recommended practice to do site customizations. > 100 'checkout-address-info' > 200 'checkout-select-shipping' > 300 'checkout-payment-method' > 400 'checkout-review-pay' I was thinking of rewriting getpaid.wizard first to have support for reordering and dynamic step conditions (now hardcoded in Products.PloneGetPaid.checkout), but it was little too much work for just one shop. >Maybe inequality invariants would be better than static numbers; but >static numbers work pretty well for the Ubuntu package managers who >build all those /etc directories, I'll note. But whichever way we >established order among the steps, the act of building the list >dynamically could have several advantages. Note that static numbers are not enough, but you will need to disable or enable pages depending on the external conditions. E.g. show checkout-payment-method if len(payment_processors) >= 2. > * It's neat for users to be able to choose among payment processors > like AuthorizeDotNet and PayFlowPro, that both plug in right at the > end of the normal checkout wizard. But what about off-site services >that provide their own wizards, like Google Checkout? Should users >be able to choose between Google Checkout and AuthorizeDotNet? Yes as there might be demographic reasons for this. For example, the shop could use a local bank processor (off-site) and global PayPal. >The usability question that is raised is this: > the choice between AuthorizeDotNet and PayFlowPro can be asked right > at the end of the wizard, before the credit card information is >demanded. I might be thinking little different here, but this is actually the easiest usability question I have faced :) 1. In real-world the payment is done just right before you are leaving the shop as the last thing of your shopping experience 2. Thus, the payment method shoul be chosen as the last step of the wizard because people are familiar with this best practice To support my rationale, all major webshops are doing the payment method as the last choice. If you need to see example, try registering a domain in GoDaddy. > Again, a usability question: do store owners deserve the right to >avoid a "click here" screen by having the cart "Checkout" button say > "Check out with Google Checkout" and go right there? Conversely: > should every off-site processor support, if the store owner wants >it, a separate "click here to leave" screen that follows the normal >"Checkout" button instead of subverting it? Yes as there might be order customizations which offsite payment processor can't handle. > I assume that users partway through the checkout process with > PayFlowPro should be able to back up and re-start with Google > Checkout if they suddenly realize that's what they want to do? The cart and checkout wizard information should be preserved as session data until the checkout is complete. >As usual, given the size of this email and the questions it asks, I'll >wait a day or two so that people have time to digest it and respond. >Then, unless the responses really surprise me and merit debate and >discussion, I think my next step will be to try inventing and >documenting - but maybe not implementing until I get feedback on the >draft documentation? - a straightforward registration scheme that >supports all the kinds of payment processor we've got. I'll call the >draft "How to Write a Payment Processor", with the idea that we focus on >exactly that: what will payment processors look like to the person who's >*writing* them, in a way that's flexible enough to support the whole >spectrum of techniques we've listed above. As starting point for the documentation I already tried to scape together something to getpaid.paymentprocessors README. I and my colleagues may support the effort, but we cannot invest into this very heavily, since we are not actively in ecommerce business and we have just one getpaid projects thus far. Cheers, Mikko -- Mikko Ohtamaa http://www.twinapex.com - Python professionals for hire --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
