|
Thursday 24 June 2004 7:38:02 am
trunk\kernel\shop\paymentgateways\doc\examples\paypal\paypalgateway.html Hi, I just found out that you published a payment gateway abstraction interface. Well, I have the following questions adn noticed possible problems. I guess others might have them too. It would be nice if you could answer them.
1.) Current Development
trunk\kernel\shop\paymentgateways\doc\examples\paypal\paypalgateway.html
As mentioned in the doc from above all gateway adoptions have to be placed inside an extension.
Following questions resolve out of this issue:
- Who is suppossed to manage the gateways?
- Will the extension ezpaypal reside in the trunk or on the pubsvn? Can you place it there?
- When should the community start to bring up implementations upon this interface layout? Excluding/including ezpaypal?
2.) Future Development
Payment gateways have different abilities.
They can be used for single item purchases, subscriptions, refunds, payouts
Some payment gateways also have capabilities that have a higher interact with the system like AVS (Address Verifiction Service).
Important:
At current design the eZPaypalGateway includes code that makes it only useable with eZOrders (single item purchase only).
I would highly recommend introducing a layout that can reflect those ablilities.
- How do you think should those adoptors reflect those capabilities/abilities of payment gateways?
- How will eZ handle handle those issues in the future?
Current state:
eZPaymentGateway
(parent)->eZRedirectGateway
(parent)->(parent)->eZPaypalGateway (single Item only)
My Suggestion could look like this:
eZPaymentGateway
(parent)->eZAuthorizeNETGateway ( is very abstract, but powerfull )
(parent)->eZPaypalGateway ( is very abstract, but powerfull )
-hold definitions does the actual/avialable processing near to the gateway.
-e.g Paypal has SingleItem,Subcription,Refund and others
eZGatewayProcessing (processes and action like bill customer, signup customer(for subcriptions) )
(parent)->eZSOAPGatewayProcessing
(parent)->(parent)->eZAuthorizeNETSingleItemProcessing ( single Item )
(parent)->(parent)->eZAuthorizeNETSingleItemProcessing ( subscription unmanaged! )
(parent)->(parent)->eZPaypalRefundProcessing ( refunding )
(parent)->eZRedirectGatewayProcessing
(parent)->(parent)->eZPaypalSingleItemProcessing ( single Item )
(parent)->(parent)->eZPaypalSubcriptionProcessing ( subscription managed! - IPN ) eZPaymentGateway::execute() <- Gets data about type of process and selceced Gateway
Processing Callbacks:
eZPaymentGatewayCallback <- Gets data about the seleced Gateway gives it to eZPaymentGateway to find the callback type ( single Item ) and it will be processed by e.g. eZPaypalSingleItemProcessing
Conclusion:
I do not see how the current design does respect other needs of a payment gateway, it should be changed. I think we will double of code if we continue like this. If you respect those needs now, you won't have to rewrite lots of code in the future.
Looking for a new job? http://www.xrow.com/xrow-GmbH/Jobs
Looking for hosting? http://hostingezpublish.com
-----------------------------------------------------------------------------
GMT +01:00 Hannover, Germany
Web: http://www.xrow.com/
|