CiviCRM Community Forums (archive)

There are two ways in which payment processors deal with recurring payments - they either take an instruction - i.e process $30 once a month or they retain the credit card information & retain it along with some sort of code and wait for you to trigger another transaction.

To my knowledge none of the second sort are implemented and it seems to me that people are avoiding those processor options because of the complexity of it. However, I also note that the work flow of civiPledge is very much similar to what is required for these sort of triggered transactions. (i.e. a transaction rather than an e-mail could be done in keeping with the pledge.)

I don't have someone wanting this right now but I thought I'd put it out there as a "when you are dealing with civipledge code could you think about adding some opportunity for a triggered payment processor to plug into" as I can think of at least one instance where this would have made the difference between someone adopting civi & putting it in the all-too-hard basket

@gardagh: Currently we are working on the direct debit integration into CiviCRM (CiviContribute). For further informations look at the issue on http://issues.civicrm.org/jira/browse/CRM-4138 and our preview on http://fuerstnet.de/en/direct-debit-payment-processor-for-civicrm.

At this point we haven't included recurring payments but we will do so if there are demand and resources for it.