Payments module needs to be abstracted properly

1 view
Skip to first unread message

Jeremy Shipman

unread,
Jul 16, 2009, 2:13:30 AM7/16/09
to Silverstripe Ecommerce
Hi guys,

Most of you are probably aware that the payments module was taken out
of the e-commerce module. Unfortunately the payment module remains
heavily coupled with the e-commerce module.

I think that seperating payments from ecommerce is a good move because
it allows payment methods can be used for other non-ecommerce things.

However, I think the way the payments module is abstracted at the
moment isn't the best way. It currently requires the use of a
DataObjectDecorator to link a payment to an order. The decorator also
overrides the Payment onBeforeWrite method to update the order status
when a payment is successful. The decorator also overrides the
redirectToOrder method to send the user to their account page, showing
their completed order.

If you are using the Payment module soley with the eCommerce modlue,
then this approach is fine. However if you are like me, and want to
use the payment module for eCommerce AND other things, you are stuck
because the decorator has tied all payment objects to be used with
eCommerce.

I propose some standardised callback methods be required for systems /
modules that make use of the payments module.

We need a way to link payment(s) to an entity that can be paid for.
(an order, event registration, software download, etc)
We need a standardised way to update that entity, and or/redirect to a
page relating to that entity after payment is made.


I think this is a pretty significant issue that needs attention.
Ecommerce seems so darn messy at the moment. I look forward to the day
it is nice and tidy. I'm trying to get it to a usable state for a
client website.

Let me know your thoughts.

Cheers,

Jeremy
Reply all
Reply to author
Forward
0 new messages