|
We also wrote a payment processor which we called DrupalDirectDebit because this payment processor works with a self developed payment gateway (which is actually a drupal module). Attention: This module stores sensible data (bank account data from clients) in drupals database. But this is just one way you can implement a direct debit payment processor and is determined by our current project and not by the direct debit method itself.
I attached an archive which includes: - the first patch (civicrm-custom-20080217.patch) - the payment processor (*/DrupalDirectDebit.php) - the payment processor install file (addDirectDebitPaymentProcessor.php) (if you prefer to apply all this files with only one patch use the file: civicrm-custom-20080217-all.patch) - the drupal module direct_debit (to use the drupal module you may need the bank identification numbers from the http://www.bundesbank.de/download/zahlungsverkehr/bankleitzahlen/20090607/blz_20090309.txt and the pears Payment_DTA Package from http://pear.php.net/package/Payment_DTA ... If you only want to test the payment processor you properly won't need this files.) For detailed information to the payment processor and the direct_debit module look at http://fuerstnet.de/en/direct-debit-payment-processor-for-civicrm This is the Patch to get the direct debit form working with civicrm 2.2.2 ... for more informations read the comments before and check: http://fuerstnet.de/en/direct-debit-payment-processor-for-civicrm
ideally we'd like to see a patch which does not store the debit number in the DB at all. its too big a security issue to store locally The last submitted patch is this one <a href="http://issues.civicrm.org/jira/secure/attachment/11559/civicrm-2.2.2-direct-debit-form.20090504.patch">civicrm-2.2.2-direct-debit-form.20090504.patch</a> from 05/May/2009
This patch does not include the functionality which stores the debit numbers in the DB. This Patch only extents the input form to collect the direct debit data. How the data will be processed depends on the payment gateway. The development of just one possible gateway could be followed on this page: <a href="http://fuerstnet.de/en/direct-debit-payment-processor-for-civicrm">http://fuerstnet.de/en/direct-debit-payment-processor-for-civicrm</a> Is there no chance to get this into the 2.3 version? I was waiting for some feedback, I'm not sure what are the further steps and what informations do you need to speed up this issue. I prefer finishing this issue immediately instead of waiting for 2.4 and patching all new 2.3 releases. Please set the "Fix Version" back to 2.3 like Kurund Jalmi did on 18/Feb/2009. Thanks. good idea to include the patch to allow folks to include direct debit fields but not include a processor implementation. lets get that into core for 2.3 Ok, merged and reworked all the patches into trunk. I have not exposed the credit/debit payment type field since we dont have any payment processor support for this as yet, but this should help you going and minimize changes needed osito, If you can do a checkout from trunk and test it out and ensure that all patches work as advertised that would be great thanx for doing all the ahrd work. the patch set was nice and clean :) assigning for 3.1 verification
Working only in Contribution.
There are still some forms that don't have the direct debit fields. See: http://issues.civicrm.org/jira/browse/CRM-6797
A patch regarding missing fields in Contribution, Membership, Renew Membership: CRM-6955
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(I'm not sure, should this be a sub-task?)
Therefore I have modified CRM/Contribute/BAO/Contribution/Utils.php. There I receive the a variable from the form object, which could be set by the payment processor ($form->_params['contribution_status_pending']). If we we want to set this status to pending we have to set its value to true - so we call CRM_Contribute_Form_Contribution_Confirm::processContribution with the parameter $pending == TRUE.
At least I hope that it can be done like this.
Later I have to call other functions to set the status to completed / canceled / failed. At the moment I'm not sure which functions I have to call to reach this. I think somehow like its done by the class CRM_Core_Payment_BaseIPN.