CiviCRM Community Forums (archive)

I have a client migrated to CiviCRM from Raiser's Edge. They get a bunch of their recurring contributions via something they call "EFT" (electronic funds transfer), which I think is the same as "Direct Debit" in CiviCRM, though I'm not sure. Is there any functionality associated with Direct Debit, analogous to what payment processors do for Credit Cards? I found:

http://forum.civicrm.org/index.php?topic=6521.0

which I think means not yet, but I might be confused...

The payment gateway (IATS) we're using does have an interface/API for what they call "Direct pay batch" processing, which means if I can provide a list of banking info and amounts each month from CiviCRM, I can upload it through this "API" and process it. This would require the banking information to reside within CiviCRM, which isn't so great, but maybe that's how it always works with Direct Debit?

okay, thanks.

the api from IATS also assumes you're holding on to the banking information, since you need to resubmit it each time it goes through.

without any extra code, i could just put the banking info into some custom fields, use a custom search to generate the batch file, upload it manually and then import the results.

for the client, this isn't too different from what they do now.

what makes sense for them in terms of new civicrm functionality might be:

1. having those banking fields in some kind of core table, including the amounts that the individuals are wanting to contribute each month/week/etc. [like the recurring donations format, i guess].
2. the ability to automate the generation and upload of the batch table to IATS, and then generation of the individual contributions in CiviCRM based on the results.

I agree that the bit about putting banking information on line is a problem, you certainly don't want CiviCRM to be a known holder of valuable financial data since it'll make it more of a known target for attempted break-ins. I wonder if there might be PKI type solution to allow encrypting of all the sensitive stuff via a password that would need to be entered during the upload of the batch table? Which would then need to be manually triggered to allow the password to be entered?

Does this sound like a generally useful model?

excellent to hear about crypt being already in use.

i think an appropriate security requirement would be that access to the database contents only would never provide you the secure data, so i'd even be inclined to not store any unencrypted field, or the users private key, in any fields. Though it might make it less friendly to use.

in terms of the cron requirement - i was thinking there'd be none, that action would only be taken with these fi,elds on demand. So it would look like this:

1. administrator would enable the functionality and enter/generate private/public key.

2. administrator would enter banking data + amounts for constituents. The amounts could stay unencrypted, and maybe some of the banking data could too.

3. the only transactions associated with the info would happen on demand, by the administrator, i.e. on the day of the month they choose, they'd go into  civicrm, click on a 'run direct debit batch', get a summary of what is about to happen, and then click on confirm, which would require them to enter their private key before it ran - the private key would be used for the decryption of the fields and a batch file would be generated and uploaded to the payment processor, results recieved, etc.