I've just posted a new release for the iATS payment processor extension, with improvements and bugfixes, mostly for the ACH/EFT (direct debit) function.
The details about the release are here: https://github.com/iATSPayments/com.iatspayments.civicrm/releases/tag/1.2.7
You would think that taking money over the web without the use of a credit card wouldn't be so hard in this world of international financial transactions? But it turns out that it is.
Of course, the idea is very enticing - your constituents want to support you, let's allow them to do that without having to pay so much money to the credit card companies. If we can do that on a recurring basis, we're getting to the holy grail of fundraisers everywhere.
And if you've been around for a while, you'll know that this technique is used frequently in the off-line world - you ask a donor for a void cheque and sign a card and then you can set up the direct debit (apologies for my North American bias here - the details would be different in other parts of the world).
The challenges compared to credit cards in the on-line version come from:
1. Legal framework.
When you pay by credit card, you're actually passing the risks of the transaction over to the credit card company. If things go wrong, you're legally entitled to not pay them. So that means an on-line transaction with a credit card is a different beast from a direct debit transaction, where there is no legal intermediary. Of course, that legal intermediation comes at a cost, which is why we're having this conversation.
2. Interface Localisation.
Credit cards are international, so the information you put into a form is the same all over the world. With direct debit, the format and language of how to describe your account is specific to the country. So for example, in Canada we talk about transit numbers and bank numbers, whereas in the US there's something called a routing number. Yes, and even the names and acronyms of what we are talking about are different (ACH, EFT, Direct Debit ..).
3. Financial Localisation.
As a consequence of 1., each country is responsible for the rules governing a direct debit transaction. These include rules that govern the required documentation for setting up an EFT. It also means a more complicated process of settling the transaction - it could take a week until you know whether the transaction has gone through for sure. In Europe, they have rules called SEPA, and in the UK, they have their own special direct debit process. You can see some of what this looks like here: http://en.wikipedia.org/wiki/Direct_debit
Because of all this, the direct debit code in CiviCRM and from the payment processors themselves are not as developed and the whole integration process is somewhat frontier-like.
That should give you a sense of why there aren't a lot of CiviCRM direct debit payment processors out there.
Comments
Thanks for that interesting post. In Germany, direct debit payments have long been very widespread and commonly used. The introduction of SEPA this year was a big pain for everyone, as it was kind of chaotic and made the dd process more complicated.
However there is one positive aspect: Now we have a common standard (kind of - most EU-countries still have exceptions...) and thanks to the work of project60 we know have a SEPA-DD integration with CiviCRM. Even better:
Starting with the next release (planned for late July) you will be able to enable SEPA-DD payments via a CiviCRM payment processor - meaning that you can enable DD-Payments on any CiviCRM-Page that support payment processors (such as event registrations or personal campaign pages.
In case anyone is interested in this, feel free to contact me.
Best Regards
Fabian
Thanks for your note. When I started working on my project, I looked at the SEPA-DD project and it looked unfinished and overwhelming, which in retrospect is exactly what I'm trying to convey with this post - i.e. Direct Debit is hard, particularly compared to a credit card payment processor.
In writing the iATS direct debit code, I discovered some quietly lurking civicrm support code for direct debit that appeared to have been written a few years ago and then abandoned, but still in CiviCRM, a kind of dark fiber ... I also noticed that the SEPA extension didn't use it, which is perhaps because SEPA is a more ambitious project.
In fact, what I'd love to see is a high-level technical description of SEPA. Not so much a sales pitch, or a long list of acronyms, but an idea about how it fits into the existing ecosystem and what the challenges are. For example, do you need some kind of back end service (i.e. like a credit card payment processing company?). Or is the financial system in Europe so open that you can actually do the backend processing within your extension?
Hi,
Indeed, quite a beast that SEPA is. to clarify, there is a payment processor and Systopia and I are working on putting everything back in one place (since week should be done)
the payment processor registers the bank account details (IBAN and BIC) and it generates a pdf mandate sent to the donor.
ex: https://dons.wikimedia.fr/civicrm/contribute/transact?reset=1&id=74
We are going to have a session at civicon london on that topic, you should come!
So the solution so far is to generate the monthly file from civi and download it on your computer.
The file format is standard and is (mostly, we had a lot of head banging on that one) and should work from all the sepa countries.
Then you upload the file to your bank, and each bank has a different system, but in general, you upload the file and if you are lucky, you just have to confirm you do intend to debit x accounts for a total of y euros. if not, you have an error message that gives an information that something is not correct somewhere in the file (with about that level of details).
I agree with you that such a description woud be very useful. As it may also become a bit lenghty for a comment on your post I will try to write a separate blog post or add a site to the project60 wiki asap (and link it here). I will however try to sum up the most important aspects of the workflow here very briefly:
Everybody - feel free to approach me if you have questions about details. As soon as there is a more detailled description of the workflow and technical aspects I will also link it here.
Hey Alan,
Thanks for sharing this thoughts. As I have experience with SEPA DD (European standard), the Norway Direct Debit system and the old Dutch Direct Debit System (Automatische Incasso) I have a few comments.
1. Legal framework: there is always a legal framework, even with DD through the bank. You have your legal framework with your bank, your constituents with their banks, the banks of you and your constituents with each other and usually your legal framework of your country. Even when your constituents pay you in cash (bringing it to your office) you have legal frameworks
2. Interface localisation: this could be the easiest part (for automatisch incasso it was, for SEPA Direct Debit is a bit more difficult, but not neccesarly too difficult. And my experience with the Norwegian Direct Debit OCR was quite easy. However civi does not provide an easy framework to expert contribution to a format a bank understand and I can understand why because every bank has its own interface so you have to create an export for every bank. So this brings me to the main point do not think too big and too global but think of the end user, your clients. Do they have a need to export direct debits to the bank? If so just develop a custom export functoinality for your clients bank (and don't get distracted by making this globally compatible with every bank.
3. Again this part 2 of the process it is reading bank statements from the bank in your local format. It depends what information they include and what you can do with that. So again this is a matter of every bank its own format. In the Netherlands we used to have a format called MT940 which almost every bank (at least the bigger ones) implemented. However we now have SEPA and SEPA allows bank to somehow customize the standard format. So again within SEPA you have to develop for every bank your own importer and exporter.
My last comment is about recurring payments there is a recurring payment extension available which makes it possible to set up direct debits, you can specify the amount, the interval, financial type etc and it will create pending contributions x days ahead. You can expotr the pending contributions to your bank for direct debit and after a while you import your bank files and set the status to completed or failed. This assumes you have developed the export and the import functionality for your banking system.
Thanks for your notes, it's great to know that others have been working on this issue as well.
But your notes are actually on quite a different tangent from the iATS extension and my post.
In a nutshell: all the difficult things that SEPA and your notes are talking about are NOT part of my extension, they are part of the service provided by iATS (who charge a fixed processing fee per transaction for that).
So as I'm noting here: even just the user-facing bits that are analogous to the credit card processing (the legal framework from the user's point of view, and the form they fill in) are already more difficult than a credit card payment processor.
What you're talking about, and what SEPA addresses, is the backend processing afterwards. Which is what this iATS solution is avoiding by getting it as an externally provided paid service.
Both models are potentially useful and appropriate under the right circumstances.
Conclusion: Taking money on the web without credit cards or an external processing service is even harder!
It took me a while but as promised you can find a more detailled description of various aspects of the SEPA-DD <--> CiviCRM approach of project60 here: http://wiki.civicrm.org/confluence/display/CRM/CiviSEPA
The following sub-page focusses of the integration with CiviCRM: http://wiki.civicrm.org/confluence/display/CRM/Integration+of+SEPA+DD+in+CiviCRM
There are also sub-pages for SEPA-Basics (which also explain some design-decisions) and technical specs (allthough most technical issues are addressed on github).
Everyone, free to contact me if there are any further questions or comments.
Regards
Fabian