Issue Details (XML | Word | Printable)

Key: CRM-4138
Type: New Feature New Feature
Status: Closed Closed
Resolution: Fixed/Completed
Priority: Minor Minor
Assignee: Rajan P Mayekar
Reporter: Osito Blanco
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
CiviCRM

Direct Debit instead of Credit Card

Created: 17/Feb/09 08:38 PM   Updated: 17/Oct/10 07:23 PM
Component/s: CiviContribute
Affects Version/s: 2.1.4
Fix Version/s: 3.0

Time Tracking:
Original Estimate: 2 days
Original Estimate - 2 days
Remaining Estimate: 2 days
Remaining Estimate - 2 days
Time Spent: Not Specified
Remaining Estimate - 2 days

File Attachments: 1. GZip Archive archive.tar.gz (52 kB)
2. Text File civicrm-2.2.2-direct-debit-form.20090504.patch (34 kB)
3. Text File civicrm-custom-20080217.patch (34 kB)
4. JPEG File direct debit form.jpg (14 kB)



 Description  « Hide
I recently started working with CiviCRM. For a project I need a contribution type different from the credit card system, which is called direct debit (mor Informations: http://en.wikipedia.org/wiki/Direct_debit). At least in Germany direct debit seems to be more accepted than credit cards.

If somebody wants to do a direct debit transaction he just need to fill in his name (name of Account Holder), the Bank Account Number, the Bank Identification Number and maybe the bank name (the name of the bank is not necessarily needed but it's quiet common that you also have to type in the name of your bank -- a better way is to automatically show up the name when the Bank Identification Number is provided, but at least in Germany this means the site operator needs to update the bank identification numbers every 3 months).

Now I started to adapt CiviCRM for this new method. Therefore I introduced a new variable "payment_type" with the values 1 (PAYMENT_TYPE_CREDIT_CARD) and 2 (PAYMENT_TYPE_DIRECT_DEBIT). I have not implemented the value 3 (to use both if the payment processor will provide both methods).
The next step was that each time where he credit card was used I had to check which payment type we are currently using. If it is PAYMENT_TYPE_DIRECT_DEBIT we show the direct debit input fields and process the direct debit.

I have seen that there are Payment Instruments But I'm not sure if I can use payment instruments for my purposes. If it is so, we can use the variable payment_instrument_id in space of payment_type.

I haven't implemented the direct debit for CiviCRM 2.2, but I'll do this soon. I also haven't Implemented the functionality for other modules which are using payments processors (event registration). It also will be done later. First I want to start this issue in hop that it makes into core for 2.3.

 All   Comments   Work Log   Change History   FishEye      Sort Order: Ascending order - Click to sort in descending order
Osito Blanco added a comment - 18/Feb/09 01:33 AM
The patch also contains a way that the payment processor could set the contribution status to pending instead of complete.

(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.

Osito Blanco added a comment - 18/Feb/09 03:00 AM
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

Osito Blanco added a comment - 05/May/09 10:59 PM
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

Donald A. Lobo added a comment - 30/Jun/09 10:57 AM

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

Osito Blanco added a comment - 30/Jun/09 12:26 PM
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&lt;/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.

Donald A. Lobo added a comment - 30/Jun/09 01:15 PM

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

Donald A. Lobo added a comment - 02/Jul/09 08:33 PM

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 :)

Kurund Jalmi added a comment - 16/Jul/09 07:11 AM
Batch move to verification

Yashodha Chaku added a comment - 16/Jul/09 11:56 AM
assigning for 3.0 QA

Yashodha Chaku added a comment - 09/Nov/09 06:30 AM
assigning for 3.1 verification

Rajan P Mayekar added a comment - 11/Dec/09 05:26 AM
Working only in Contribution.

Osito Blanco added a comment - 09/Sep/10 12:54 AM
There are still some forms that don't have the direct debit fields. See: http://issues.civicrm.org/jira/browse/CRM-6797

Reinhard Mayr added a comment - 17/Oct/10 07:23 PM
A patch regarding missing fields in Contribution, Membership, Renew Membership: CRM-6955