search

artfulrobot / uk.artfulrobot.civicrm.gocardless

A CiviCRM extension providing GoCardless integration to handle UK Direct Debits.
GNU Affero General Public License v3.0
5 stars 18 forks source link

Adding support for the SEPA payment scheme #37

Open Upperholme opened 6 years ago

Upperholme commented 6 years ago

We're using this extension to support recurring membership payments, and it seems to be working successfully(despite some odd behaviour with respect to membership dates, but I don't think that is down to this extension), so many thanks for that.

The organisation that I'm working with now wants to respond to demand from people in the Eurozone who wish to become members. At the Civi end of things I guess we can enable the Euro as a second currency for the installation (although I'm aware that multicurrency support is pretty limited within Civi currently), and I can then set up a membership sign-up page to use Euros.

At the GoCardless end we ca get them to enable the SEPA scheme for the account alongside the BACS scheme.

So I guess the bit in the middle is ensuring that this extension understands what currency is being used for a given transaction, and therefore which scheme, and can pass that information on to GoCardless.

So the question is, does the extension as it stands support any of this, and if not, what would it take to make it SEPA-friendly, as well as BACS-friendly?

artfulrobot commented 6 years ago

Hi,

I don't think this should be too much work. I've implemented SEPA before with GC - it's much the same as DD, but it will just be a case of making sure what goes into CiviCRM is correct. "just"... :-)

I'd estimate there's 14 - 21 hours work to get it integrated with some tests. Feel free to get in touch by email (I think you have it) if you have funding for this.

That said there could be some gremlins somewhere, as you hinted at.

Rich

Upperholme commented 6 years ago

Thanks. I'm talking to the client about this and will email if they want to move forward with funding.

reswild commented 6 years ago

I think this is all you need to do in order to support Euro payments: https://github.com/reswild/uk.artfulrobot.civicrm.gocardless/commit/bfd6c82410690670bc3ff9220c461cd38c18f422

If you use CiviCRM payment pages, they will handle what goes into CiviCRM, so you just need to specify Euro instead of Pounds when doing the transaction.

Upperholme commented 6 years ago

And GoCardless sees the incoming request as Euro-specific and automatically routes it to the SEPA scheme rather than the BACS scheme?

reswild commented 6 years ago

GoCardless will use the SEPA scheme if you specify a country within the Eurozone. You can change country after you have arrived at gocardless.com, but it's best to include the country code as part of the prefilled_customer parameter when setting up the redirect flow.

I have set this up on my own site, but I'm using custom code for creating the payments instead of using the CiviCRM payment pages, so I haven't really checked yet how address information are passed from these.

Also, you need to conatact GoCardless first, and ask them to turn on SEPA support on your account before any of this will work.

Upperholme commented 6 years ago

Useful, thanks. We have SEPA support turned on by GC, so from what you are saying if we can get this extension to collect and pass the country code to GC, and maybe the currency, it will use the SEPA scheme to handle the payment.

reswild commented 6 years ago

You do need to pass the correct currency to GoCardless, or you will get an error, but my patch above should take care of that.

I can make another patch for filling in the prefilled_customer parameter. At the moment I'm just passing along our members primary address in CiviCRM, but it would be more appropriate to use either the default billing address, or register an address for each subscription.

artfulrobot commented 6 years ago

Yep, this looks about right to me. Thanks @reswild

I think we also need the webhook to look out for the currency in confirmed payments and pass that into the created contributions.

Pre-filling the GC redirect flow form is a good idea, however I want to keep this as flexible as possible. Specifically I want to be able to use the payment processor without needing to use Civicrm contribution (etc) pages. This is why the functions are structured as they are, taking data by input parameters. It also makes testing cleaner.

None of that should get in the way of using prepopulating the GC forms, but thought I'd explain the principle and approach I've used.