Jeremy Shipman
unread,Jul 16, 2009, 2:13:30 AM7/16/09Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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