Hi Mikko, Thanks for helping us understand the differences between the multisite branch and the no overrides branch. My understanding is we really just need some more feedback on how it is set up, feedback on how clear the documentation for creating a payment processor is, and the design that was used. We've had little other testing that I know of, so thanks for your comments. I'm testing on a site with one onsite and one offsite. We have implemented 2 processors with the offsite interfaces based on Brandon's branch (NMI and authorize.net).
In discussing the use cases, we didn't know of any that would require multiple onsite payment processors. In my experience, the kinds of providers that let you do onsite usually involve a monthly fee, so site owners are unlikely to subscribe to more than one (cheaper to pay one to add a particular credit card service, like American Express or Discover, than to have an entire different service). However, I see how this could raise an issue if a Purchase Order or Bank Order implementation is made using the same infrastructure. It would probably behave like an onsite processor, and then it may not be possible for a merchant to have both a onsite payment and offline payment. Hopefully what is there can be modified to account for this potential use case. Also, the button alignment needs some work on the cart screen and portlet :) -chris On Sun, Nov 15, 2009 at 6:24 AM, Moo <[email protected]> wrote: > More issues: > > One cannot present paymeny processor options as a schema reference > (options_interface). They payment processor must be able to customize > its own form view as zope.schema cannot be used to express all form > use cases (custom widgets and so on...). > > -Mikko > > > I just went through Brandon's work. Looks nice to me, though there are > > some show stopping issues. > > > > The offsite payment processor interface was empty. It is very > > difficult for third parties to implement payment processor unless > > interfaces are documented with the required precision. > > > > If I read the core correctly there can be just one on-site payment > > processor. Also, the wizard step to choose payment processor is > > missing. > > > > As is, this work is useless for many use cases, like > > > > * Having a wire payment processor > > > > * Choose between credit card and wire payment > > > > * Choose between different on-sites processors (imagine different > > processor for different credit cards) > > > > What's the status of the future of Brandon's work? In > > multiplepaymentprocessor support for these use cases exist. > > > > I am willing to help to merge multiplepaymentprocessor branch with > > brandon and brandon branch with trunk if > > > > 1) Community "decision making process" sees this as a necessary > > requirement for the future > > > > 2) There is someone else willing to put hours on the issue > > > > -Mikko > > -- > 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]<getpaid-dev%[email protected]> > > For more options, visit this group at > http://groups.google.com/group/getpaid-dev?hl=en?hl=en > -- Cofounder and CEO ifPeople - Innovation for People www.ifpeople.net t: 678-608-3408 130 Boulevard NE, #6 Atlanta, GA 30312 -- 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
