forked from silverstripe-archive/silverstripe-payment
Home
jedateach edited this page Apr 2, 2012
·
25 revisions
A solid payment module means that SilverStripe apps can be payment-enabled very quickly. A standardized payment library means that payment types can be swapped out at will. No need to rewrite code.
Read more about this fork of the payment module.
- Make payment for any data-object in SilverStripe.
- Must work across multiple modules.
- Provide a standardized API for any payment gateway/processor/connector. (eg: paypal,worldpay,paymentexpress,cheque)
- Centralized place to store and choose from different payment types.
- Re-occurring payments system/interface.
- Total paid / total outstanding functions for an object.
- Making partial payments.
- Outgoing payments.
- Processing partial or full refunds - if the gateway allows.
- Ability to configure a different set of payment types for different modules / purposes within the same SS install.
- If specific payment type is uninstalled, the db values can still be used.
- Make a deferred payment - store credit card details, and trigger the transaction at a later date. Could either be provided by gateway, or Payment module (requiring mega security).
- http://lifeinide.blogspot.com/2010/12/multi-payment-gateway-module-for-zend.html
- http://framework.zend.com/wiki/display/ZFPROP/Zend_Service_Payment
- http://pear.php.net/package/Payment_Process
- SS extension page: http://silverstripe.org/payment-module/
- Forum discussion: http://silverstripe.org/payments-and-payment-gateway-apis/
- All 'payment' related discussion on the ss core dev group: https://groups.google.com/forum/#!searchin/silverstripe-dev/payment
- Payments Module Changes Proposal
- There is a google group specific to payment module here, however it is seldom used.