Initial multiple payment processor support has now landed

[Mikko Ohtamaa]

Hi all,

I have now added support for multiple payment processors in GetPaid. It somehow works with synchronous payment processor (getpaid.nullpayment) and asynchronous payment processor (getpaid.paypal).

Please follow instructions here: http://pypi.python.org/pypi/getpaid.paymentprocessors/0.1

Updated packages :

Products.GetPaid (multiplepaymentprocessors branch)
getpaid.paymentprocessors (trunk) https://getpaid.googlecode.com/svn/getpaid.paymentprocessors/trunk
getpaid.nullpayment (multiplepaymentprocessors branch)
getpaid.paypal (trunk)

Open questions:

- How asynchronous payment processor should manage its order and cart? I was bit lost trying to figure this out. Especially 1) when order is created 2) when order is authorized 3) When user cart is emptied

Other open issues found in getpaid.paymentprocessors readme http://pypi.python.org/pypi/getpaid.paymentprocessors/0.1

--
Mikko Ohtamaa

[Michael Dunstan]

On Tue, Jun 30, 2009 at 1:27 AM, Mikko Ohtamaa<mi...@redinnovation.com> wrote:
> - How asynchronous payment processor should manage its order and cart? I was
> bit lost trying to figure this out. Especially 1) when order is created 2)
> when order is authorized 3) When user cart is emptied

The Google Checkout payment processor empties the cart once it
receives a call back from the google checkout server that the payment
has been completed. (That's an incoming HTTPS request from the google
servers to the plone server.)

The usability feature of that is that the user can use their back
button to go back to the shop (or follow the links on the google
checkout review page) and still have their cart intact.

Meanwhile the Google Checkout processor for getpaid does not yet
bother with orders. Google checkout itself provides order management.
However if a site allows the shopper to chose from several processors
then it could make sense for someone to add in order support for that
processor too. (That would not be particularly hard to do. The
mechanical parts of receiving the notifications are already
implemented.)

--
Michael Dunstan

[Tim Knapp]

On Mon, 2009-06-29 at 16:27 +0300, Mikko Ohtamaa wrote:
> Hi all,
>
> I have now added support for multiple payment processors in GetPaid.
> It somehow works with synchronous payment processor
> (getpaid.nullpayment) and asynchronous payment processor
> (getpaid.paypal).
>
> Please follow instructions here:
> http://pypi.python.org/pypi/getpaid.paymentprocessors/0.1
>
> Updated packages :
>
> Products.GetPaid (multiplepaymentprocessors branch)
> getpaid.paymentprocessors (trunk)
> https://getpaid.googlecode.com/svn/getpaid.paymentprocessors/trunk
> getpaid.nullpayment (multiplepaymentprocessors branch)
> getpaid.paypal (trunk)
>
> Open questions:
>
> - How asynchronous payment processor should manage its order and cart?
> I was bit lost trying to figure this out. Especially 1) when order is
> created

When displaying the button for the redirect to PayPal getpaid.paypal
creates an order, 'authorizes' it (and stores the order) and then
redirects to PayPal for payment. The cart is destroyed prior to the
redirect (I'm just the messenger in this case as the code wasn't
implemented by me; perhaps Michael's implementation may be better
here?).

> 2) when order is authorized

As above, this is done as part of the display of the 'Pay Now' button.
As an aside, when the successful payment notification (IPN in PayPal
speak) comes back from PayPal the order is marked as 'PAYED'.

> 3) When user cart is emptied

The cart is available to the user until they click the checkout button
upon which it is destroyed (as mentioned above).

Thanks,
Tim

[Mikko Ohtamaa]

The Google Checkout payment processor empties the cart once it
receives a call back from the google checkout server that the payment
has been completed. (That's an incoming HTTPS request from the google
servers to the plone server.)

Also please see this critical bug discussion regarding the destruction of a cart:

http://code.google.com/p/getpaid/issues/detail?id=209&sort=priority&colspec=ID%20Type%20Status%20Priority%20Release%20Component%20Summary%20Owner

The bug might be triggered by the way how cart is destroyed. Someone with heavy Zope experience could investigate - I think my own time is little limited and I am not yet ascended  to the land of Zope gods.

-Mikko

 

The usability feature of that is that the user can use their back
button to go back to the shop (or follow the links on the google
checkout review page) and still have their cart intact.

Meanwhile the Google Checkout processor for getpaid does not yet
bother with orders. Google checkout itself provides order management.
However if a site allows the shopper to chose from several processors
then it could make sense for someone to add in order support for that
processor too. (That would not be particularly hard to do. The
mechanical parts of receiving the notifications are already
implemented.)

--
Michael Dunstan

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

[Michael Dunstan]

On Tue, Jun 30, 2009 at 8:41 PM, Mikko Ohtamaa<mi...@redinnovation.com> wrote:
> Also please see this critical bug discussion regarding the destruction of a
> cart:
>
> http://code.google.com/p/getpaid/issues/detail?id=209&sort=priority&colspec=ID%20Type%20Status%20Priority%20Release%20Component%20Summary%20Owner

I've managed to create a detailed list of the minimal steps required
to recreate that problem:

http://code.google.com/p/getpaid/issues/detail?id=209#c33

--
Michael Dunstan

[Mikko Ohtamaa]

I've managed to create a detailed list of the minimal steps required
to recreate that problem:

 http://code.google.com/p/getpaid/issues/detail?id=209#c33

Please see new comments.