Reviewed Brandon's work: some suggestions

[Moo]

Hi,

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

[Moo]

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

[Christopher Johnson]

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

--
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 getpa...@googlegroups.com
To unsubscribe from this group, send email to getpaid-dev...@googlegroups.com

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

[Marton Schimcsig]

Hi,

On Nov 15, 2:59 am, Moo <mi...@redinnovation.com> wrote:
> Hi,
>
> 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.

The wizard step is not needed here.
The checkout process should be done with as few click from the buyer
as possible. This is important point for the shop owners.
With paypal standard, you get a checkout button from the payment
provider and put it on your site anywhere, allowing the customer the
start the payment immediately. Later the payment processor can be
asked and/or will notify the shop about the transaction.

With paypal express checkout, you have to ask the paypal server for a
token, before you can generate the checkout button, so the extra step
in checkout process after selecting paypal is needed.
The current paypal module in trunk works with paypal standard.

> 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)
>

In Brandon's branch you can use offsite processors and onsite
processor together, the buyer can choose between them during the
checkout.
However the offsite button rendering is done with black magic, a
refactoring would be nice.

> What's the status of the future of Brandon's work? In
> multiplepaymentprocessor support for these use cases exist.

I'm just trying out multiplepaymentprocessors branch, which offsite
payment processors should I test with? Currently only see the onsite
nullpayment.

> 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
>

+1


> -Mikko

Cheers,

Marton

[Mikko Ohtamaa]

>
> I'm just trying out multiplepaymentprocessors branch, which offsite
> payment processors should I test with? Currently only see the onsite
> nullpayment.

Currently there should be

* PayPal (not sure which branch was correct)

* Luottokunta (Finnish credit card processing)

* Verkkomaksut (Again, Finnish generic payment processor)

Also I think there is one special processor for making real purchases
without doing the actual payment, for internal purchases of the store
owner.

Cheers,
-Mikko

>
>
>> 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
>>
>
> +1
>
>
>> -Mikko
>
> Cheers,
>
>  Marton
>

> --
> 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 getpa...@googlegroups.com
> To unsubscribe from this group, send email to getpaid-dev...@googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/group/getpaid-dev?hl=en?hl=en
>



--

Mikko Ohtamaa
Managing director, Red Innovation Ltd.
+358 40 743 9707
www.redinnovation.com
Every problem is solvable if you can throw enough energy drinks at it

[Christopher Johnson]

Back to this initial comment, I'm wondering how it is that you would
handle a wire payment. Would this basically be like an onsite
processor but not actually collect any billing information? ie the
user enters in their general info (first page) and then just gets a
review screen (no additional info necessary). Then once complete the
user would go make a wire payment outside the website (and the site
admin would need to update the finance workflow after wire received).

Sorry for slow on this...we don't process this way (ever, that I know
of), in the states, so trying to understand.

Cheers,
Chris