The requirement is to be able to setup multiple payment processors that use different GoCardless accounts, e.g. one for a charity and one for a company.

Currently the extension assumes there is only one GoCardless payment processor.

Getting a tad confused getting this set up, in part because I'm not familiar with the GoCardless system, and in part because CiviCRM's payment processor approach allows for both a live and test mode and I'm working on a dev copy of the site so that this isn't going anywhere near production yet.

In terms of setting up the payment processor, as I read it I need two access tokens - one for live mode using the real GoCardless account, and one for test mode, using the sandbox GoCardless account (although for my testing right now I'm only really concerned with the sandbox account and test mode.

On webhooks, am I right in thinking that again two webhooks are needed, one for live mode and one for test/sandbox?

Also on the payment processor set-up page, I see fields (in both live and test) for "Site URL" and "Recurring payments URL", neither of which are prefilled, so is the site URL the address of my site's front page? And what's the recurring payment URL? (apologies if these come across as numpty questions, I'm new to recurring payments).

Lastly - minor point (I think) in your install/setup notes it states: "Select GoCardless Direct Debit from the Payment Method" but I don't see that option on my payment processor form?

Testing GC. Hoping you can confirm this all looks correct in terms of outcome.

I set up a page for recurring and entered 2 x weekly for £1 each from my UK account.

I did this on March 6th and got 2 receipts from GC

• You've set up a Direct Debit
• You've set up a Direct Debit subscription

What I see in CivICRM is:

Recurring Contribution

£ 1.00 | Every 1 week | March 12th, 2018 12:00 AM | 2 | In Progress

Contribution

£1 recurring
Received: March 12
Status: Pending (Incomplete Transaction)

In GC what I see is

Status = submitted
Description = Online Contribution: gocardless
Charged 12.03.18
Paid out 14.03.18

So this all seems to make some sense but I have two specific questions

• is it expected that I should get those 2 responses from GC? I would only expect one.

• is it expected that eg Weekly contributions always start on a certain day of the week (Monday)

I tried to answer these questions myself by reading

https://gocardless.com/direct-debit/timings/

and searching for info about receipts but didn't succeed

When running my tests against 5.19.1 I found them to be broken around membership dates.

This suggests something has changed in core.

I'm working on a new release to fix this.

I've done some testing with memberships around when ContributionRecur records exist, and it seems that its only when the membership is set to auto-renew, as @artfulrobot suggested.

The plugin currently creates GoCardless subscriptions and not payments (which are one off), so does not support non-recurring contributions. I'm hoping I can get that functionality working at some point, but for now, just leaving this issue here as a reference. Just in case anyone is worried, any non-recurring contributions won't get silently turned into recurring ones, the plugin just throws an exception.

Hi all,

It seems this extension is now being used by quite a few organisations. Yay!

If you use it please drop me a comment below..

It would help me to know quite how many - at the mo it's quite tricky to install (requires running composer, for instance), and I can make this easier by publishing a zipped releases. Also I can register it with CiviCRM for single click installs :-)

Also, if there's a group of orgs using it then the possibility for further development increases, e.g. if you all need feature X or bug Y squishing several of you could chip in to fund me to do it. As a small freelance developer I have to prioritise. Of course PRs always welcome too!

So, please do drop me a line below if you're using it. (apols that this means registering with github, hopefully not too much of a faff.)

Thanks,
Rich

GoCardless sends wordy webhooks like this:

Enough time has passed since the payment was submitted for the banks to return an error, so this payment is now confirmed.

But experience now shows that it's possible for this payment still to fail, resulting in a payments.failed webhook coming the day after:

The customer's bank wasn't able to pay the Direct Debit. This is almost always due to insufficient funds, but is occasionally used as a catch-all for other failures.

This is a bit embarrassing really - GC tells us "all is ok" and then says "no it's not". And the first one of those messages may be linked to receipts and memberships and who knows what!

Anyway, it results in CiviCRM having status Completed where actually it has now Failed.

I suppose this extension should just update it to Failed anyway?

When a user sets up a new direct debit mandate Civi creates a contribution record with a 'pending (incomplete transaction)' status. If the contribution is for a membership, then a matching membership record is created. This membership should also have a pending status. However in my tests, using Civi 4.7.29 on Wordpress, the membership is created with a 'New' status.

So, when the first payment is made, instead of activating the pending membership, the membership is in fact renewed.

I realise that this may be a CiviContribute issue and not a result of anything that this extension is doing, but wanted to log it here to find out if any other users of this extension are seeing the same thing, and also to raise awareness of it here.

I've installed extension in civicrm using Drupal and also I've added Gocardless Payment Processors with live and test webhooks secret and access keys but when I try to visit /civicrm/gocardless/webhook it shows me white blank page.

Can you please help me in this. @artfulrobot

Both of these are unique in each of civicrm_contribution and civicrm_contribution_recur.

I had hoped to use the invoice_id for the subscription but this won't work because it would lead to 2+ contributions being impossible(!)

Hey @artfulrobot,

Hope you are well!

I am trying to test this extensions but getting a white screen when I click on "Continue" button on contribution page. This should be redirected to gocardless gateway if I am right? There are no errors in the logs either for this.
Webhooks are working fine as checked on GC sandbox account.
Please can I ask what could be wrong here as no error is being displayed just WSOD.

CiviCRM version: 4.7.23
Gocardless extension version: 1.3-beta

Thanks!

The GoCardless payment processor can cause validation errors that affect other payment processors' config pages.

Currently just see

Error Sorry, we are unable to set up your Direct Debit. Please call us.

in the logs i see

completeRedirectFlowCiviCore: EXCEPTION before successfully setting up subscription at GoCardless: Invalid interval 'dayly', must be yearly/monthly/weekly

Would be helpful if that could show on screen. Note also 'dayly' should be 'daily' but i don't think that is causing any issues for anyone other than a spelling tyrrant ;-)

Now perhaps my testing will be successful by using Weekly not Daily.

Hey Rich,

We are getting the following:

"PHP message: PHP Fatal error: Call to undefined function getallheaders() in /var/www/..../httpdocs/sites/all/civicrm_extensions/uk.artfulrobot.civicrm.gocardless/CRM/GoCardless/Page/Webhook.php on line 31" while reading response header from upstream, client: , server: , request: "GET /civicrm/gocardless/webhook HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: " "

Issue is from: Call to undefined function getallheaders()
This appears to be a known nginx+php-fpm problem:
http://www.rawnet.com/labs/authorization-headers-in-php-using-fpm
https://stackoverflow.com/questions/13224615/get-the-http-headers-from-current-request-in-php
https://stackoverflow.com/questions/41427359/phpunit-getallheaders-not-work/41428728
https://www.popmartian.com/tipsntricks/2015/07/14/howto-use-php-getallheaders-under-fastcgi-php-fpm-nginx-etc/

Are you able to use a different method to be NGINX compatible?

Best

Jamie

A while back you wrote:

By the way, I'm also considering launching code to import direct from GoCardless - this won't help people using Veda's extension (because they'll already have records in CiviCRM) - but is useful for (a) people who have been using GC with another integration, or where Mandates etc. have been created outside of the CiviCRM processes but would like to be imported.

Originally posted by @artfulrobot in #4 (comment)

Do this progress? I'm setting up a new Civi and importing memberships that have existing GC DD's. I need to pull the data from GC to take on the existing mandates/subscriptions.

GoCardless Developers section reports back a 403 Forbidden.

Is there a file somewhere that I need to check or change there permissions to? If so, which file?

Many Thanks.

Created16th Apr 2018
Response code 403 Forbidden
Test false
URLhttps://xxxxx/civicrm/gocardless/webhook

Currently there is no error reporting and webhooks silently fail if they don't work out. As webhooks run without any user interaction there needs to be a way to alert admins of problems, or at least provide them with a way to check for problems.

Example cases:

1. If a webhook comes in for a payment on a subscription that doesn't exist in CiviCRM, this is ignored. Some people might want to check for this and get the contact and payment set up in CiviCRM (somehow) so that future contributions can be tracked.
2. If anything goes wrong responding to a webhook event then it is silently ignored. While this should be fairly rare, a scrupulous admin person would still want to be able to check for it.

Probably other cases.

This extension updates the membership directly using the API. I don't believe that it should do this. This extension should just handle the payments, the business logic around membership should be handled by CiviCRM.

I believe that this may be causing a number of issues with memberships:

• #27 Membership since date is getting changed
• start_date and join_date are overwritten on renewal
• end_date is extended twice on renewal (this extension extends the end date while the payment is pending, CiviCRM extends it again when the payment clears)

All of the business logic around membership is triggered when the extension makes API requests to completetransaction and repeattransaction when a webhook is received.

I spent some time looking at this extension during the UK CiviCRM sprint and was hoping to follow this up subsequently but haven't had the time yet unfortunately. If I get time, I would like to follow this up in future but in the meantime I wanted to at least record my understanding of the problem here.

I'm using this extension to support membership sign-up and renewal on a client site (running 4.7.27). So far it all seems to be working largely as expected, however we've noticed one thing in our initial round of live tests:

For members who are renewing their existing membership by setting up a DD (they were previously paying by other means), we are seeing that the 'member since' date is being updated such that it is the same as the 'start date'. As far as I can tell, for all of the live tests we've done so far, the existing membership was still within the grace period, and in those circumstances the 'member since' date should not change.

I realise that the extension probably doesn't directly interact at all with memberships, and that maybe this is due to a different Civi issue, but wanted to post it here nonetheless in case anyone can cast any light.

Hi

I'm working on a site where go cardless dd is installed on a membership page with paypal as the cc processor.

When I opt for m'ship and select go cardless it is creating the mandate as expected. When I view the contribution on Civi the payment is recorded as "Paid By: Credit Card" not Direct Debit.

This seems to have been happening for a few months the payment page has recorded dozens of DD payments as Credit Card, but they are all showing as pending incomplete transaction. The debits are all showing as being paid in the client's go cardless acct. Could it be because the payments show as Credit Card, not Direct Debit that they are not being updated when the payment is taken?

Direct Debit is set as the default payment instrument for the site, I can't figure out where in the contribution page this is over-ridden.

Have you come across an issue like this before? Do you have any suggestions where I could start investigating further?

Cheers

Craig

CiviCRM specifies a weekly membership/recur as "Every 7 day". But GoCardless doesn't understand that this is "Every 1 week". I had a similar problem in Smartdebit and ended created a (probably overcomplicated) function to map params:
https://lab.civicrm.org/extensions/smartdebit/blob/master/CRM/Core/Payment/Smartdebit.php#L508-521

When using a profile with a membership form the first name is not populated at GC.

Hi. On my test site I set up a new GoCardless direct debit on Jan 20. The GoCardless sandbox reports that as being set up. All good. GoCardless has since gone on to request the first payment (24 Jan) and confirm the payment (27 Jan), and the webhooks for all that appear to have been ignored by CiviCRM.

So what I have in Civi is a 'Pending (Incomplete Transaction' record with no information about whether a) the mandate was successfully created or b) whether any payment has been made.
The webhook URL that CoCardless has is
http://my.test.domain/?page=CiviCRM&q=civicrm/gocardless/webhook (it's a Wordpress site)

All of the webhook records in the GC dashboard indicate either "timed out or other failure" or "204 No content".

In my site's GoCardless log I'm seeing:
Jan 27 11:02:33 [error] Webhook 2017-01-27:11:02:32 Failed event. Reason: The access token you've used is not a valid live API access token
(not sure what this means, as the payment processor is set up to use https://api-sandbox.gocardless.com/)

My sense is that what I'm doing wring here is something obvious, so I'll go through all my settings in anticipation of slapping myself in the face. If anyone can help expedite that and tell me where I'm gonig wrong that would be great.

I'm looking at the Membership Extras extension from compucorp with a view to using it with this GoCardless extension. From what I've read, I'm hoping that it would enable me to have an annual membership and offer a monthly direct debit payment. Right now, in order to offer a monthly, or quarterly payment option, I need to have my membership period aligned with the payment period, making my membership types more complicated than would ideally be the case.
Before I get stuck into that, I was wondering if anyone else is already successfully using these two extensions together, and if so, whether my assumption is actually implementable?

I am using civicrm_webform (7.x-4.19) in Drupal (7.52) and have a webform which uses a Contribution page on CiviCRM 4.7.30.

The GoCardless payment processor fails with the following notice:

Notice: Undefined index: description in CRM_Core_Payment_GoCardless->doTransferCheckoutWorker() (line 122 of /var/www/vhosts/my.site/dev/sites/all/extensions/uk.artfulrobot.civicrm.gocardless/CRM/Core/Payment/GoCardless.php).

I have tried to simply set the $params['description'] value by hard-coding it, but that led to the following error being displayed:

We can't load the requested web page. This page requires cookies to be enabled in your browser settings. Please check this setting and enable cookies (if they are not enabled). Then try again. If this error persists, contact the site administrator for assistance.

Error type: Could not find a valid session key.

I'm guessing that the description is used to create the session key, so changing it in CRM_Core_Payment_GoCardless::doTransferCheckoutWorker breaks it.

Does anyone have any ideas? Thanks.

This is an issue to keep me focussed on my reason for writing it: a client needs this up and running by Nov 2016.

Therefore my primary interest (and all I'm paid to do) is to get the functions that they need implemented and production-ready. My personal interest is in making something really useful for the CiviCRM community at large, but this is a lower priority.

Here's what I need to have working by launch:

1. Be able to integrate with Contribution Pages for the purposes of regular giving. (i.e. specifically: not for membership, not for one-offs)
2. Be able to implement with a custom form (outside of CiviCRM's usual Contribution Page workflow). Therefore the "doing" functions need to be outside of CRM_Core_Form classes.
3. Have sensible references stored to enable manual and automated reconciliation between GoCardless and CiviCRM (i.e. store suitable GoCardless ids in CiviCRM's invoice_id and trxn_id fields)
4. Have successful payments automatically recorded in CiviCRM as contributions against a recurring contribution record, using the GoCardless webhook.
5. Have failed payments automatically recorded too, using the GoCardless webhook.
6. Have expired/cancelled mandates/"subscriptions" (that's GoCardless speak) cancel the recurring payment record in CiviCRM, using the GoCardless webhook.
7. Have all functionality automatically testable using phpunit4 CiviCRM style tests.

These are my essentials, however it is my goal to have more features and I'll be doing my best to write code in a way that enables that.

We're getting reports from a few users saying that they are seeing an error - we think this must be after they've completed the GoCardless form and are being redirected back to our site. This is leading to them repeating the process, which in turn is leading to the creation of multiple mandates, which an admin is then having to clean up.

An initial response from GC support states:

"I've taken a look into your account and I can see that you're using your own website integration to create and manage your payments.

We haven't seen any timeout responses with the requests that have been sent through over the past few days, which suggests that there may be an issue when your customers are being redirected back to your website when they complete their details (but the mandate and payments are being submitted successfully in the background).

I'd suggest double checking with your developers to see whether they can look further into the redirect flow you have set up."

I'm looking in to the log files at my end to see what I can find, and will update accordingly.

I'm looking to implement this on a new site where we need to collect postal address information into the CiviCRM database. The GoCardless form on their site also collects address information. If I use a profile on my Civi contribution page that includes address fields etc, it looks like none of this currently gets passed to GoCardless when the user is redirected to the form on their server, with the result that the user enters data twice.
Is this avoidable, either by enabling the user to enter all of the required data into the Civi form before going off to GoCardless, and passing that data into the GoCardless form, or alternatively by getting the data into Civi from GoCardless once the user has submitted the form at that end?

Currently payments come in and update recurring contribution and contribution records but do not update memberships. This is important for anyone using Direct Debits for memberships.

when I try a transaction I'm just getting a white screen after the confirmation page, and in the logs I'm seeing that vendor/autoload.php isn't available, which then leads to a fatal error. Should Composer be pulling in this file? I've installed Composer in the extension directory according to the README file, so I'd sort of assumed that at some point it would download the GoCardlessPro PHP library?

This is an edge case to do with cancellations close to the time the first payment completes; such that the first payment actually completes after the cancellation(!)

1. supporter creates mandate.
2. GoCardless creates a payment
3. supporter (or admin via GoCardless website) cancels mandate
4. GoCardless successfully takes payment

This results in:

• One Failed Contribution record
• An "In Progress" Contribution Recur record.

But it should result in:

• one Completed Contribution
• a Cancelled Contribution Recur record.

Why it fails

When a mandate cancelled webhook is processed, the contrib. recur record is cancelled and so is any pending contribution.

When a payment confirmed webhhok is processed, it:

• finds the recur record and updates it to In Progress.
• looks for a pending contribution (there wasn't one because it was marked Cancelled)
• looks for the first (by date) completed contribution (there wasn't one) to set as the original_contribution_id field.
• calls repeat transaction API, but this will throw an exception if there isn't an original contribution. (nb if we don't provide original contribution id then the repeattransaction API looks up the last one by ID that is completed - this would result in the same thing)

solution A

1. Assumption: GoCardless will not create a payment if the mandate is cancelled.

2. Implement the payment created webhook - this would have to find the pending contrib, set its trxn_id.

3. Change the processing of payment confirmed webhook to look up the contribution by the trxn_id - whether that payment is Cancelled or Pending.

4. Only update Contrib Recur to In Progress if it is not already that, and then before making the change do a GC API lookup to check it's not been cancelled.

solution B

Change processing of the mandate cancelled webhook so that it does not cancel the pending contribution record. This would mean that the recur record showed cancelled while the payment remained pending. Presumably then GC would either send a payment confirmed event, or a payment cancelled/failed - which should both be fine.

As with solution A, it needs: Only update Contrib Recur to In Progress if it is not already that, and then before making the change do a GC API lookup to check it's not been cancelled.

I think solution B is better on the grounds that it is simpler.

I've built automatic tests in and I'll be testing it myself and with my client. But as we all know, it takes many people to test an open source project.

If you can offer to test it in any way please add a comment below describing what you can offer. Note I'm one person with a lot on, but I'll try to keep on top of things.

While I'm experienced in unit and integration tests, I'm fairly new to CiviCRM's particular way of implementing tests. I'll share this info here in case anyone else might otherwise be, ahem, caught out: Running the automated tests will obliterate your database. Jus' sayin'

Hi @artfulrobot . This is the only issue I've found in the extension review so far. It's not a requirement, but I recommend addressing it, as it can help translators to give non-English speakers a better experience.

Extension developers are asked to pass the second 'domain' argument in ts() function calls, to help translators distinguish between core terms and extension-specific terms. Reference: https://docs.civicrm.org/dev/en/latest/translation/extensions/#for-developers-correct-usage-of-the-ets-function Extensions built with newer versions of civix can use the E::ts() method to save some keystrokes and avoid typing that second parameter every time.

If someone fills in a CiviCRM Contribution form and clicks through to the GoCardless external website but then abandons the process, CiviCRM is left with a "Pending"/incomplete Contribution and Contribution Recur record.

However, if they complete the process, the contrib and contrib recur records still show this in their status, until the first payment has been successfully claimed, at which point the recur record is set to status: "In Progress"

It might be clearer for CiviCRM admins to see the recuring contribution set to "In Progress" at the time that the mandate and subscription were successfully set up, since then any "Pending" records that are older than an hour or so could be assumed to be abandoned processed, and could be ignored (or have their status set to cancelled or such).

Would this help you? Does anyone want this feature? Might anyone want to contribute to making it happen? I think there's perhaps 3 hours work in it, including updating the test code, documentation etc.

Running Civi 5.8.2 on Drupal, and latest release of this extension. DD payments are working, and in summary contributions page are listed, but no "payments" are shown when drilling down. (see attached screen capture). All one-off contributions made by PayPal or Stripe are shown correctly, just not recurring ones. This means that when running GiftAid process, these contributions are rejected, presumably as no payment can be found. Table civicrm_contribution seems to have a complete record for these DD payments..

As part of our testing this I set up a Recurring Contribution for £1 weekly for 2 weeks.

Here are the entries in GoCardless

as you can see, the payments are continuing to be made, which is also what shows in my bank account :-( and on my Contribution Tab

civicrm_contribution_recur correctly shows the 2 installments. It has no End Date. Should it have had this set when the recurring payment was initially set up?

Can you pls advise on how to get this fixed. Many thanks

Hi,

I'm having an issue with one of our client sites using this extension with CiviCRM Contribution Pages.

They're getting contributions that aren't showing as recurring, and when I look at the data the recurring contribution data is missing.

Is there anything that you think could be responsible for this? It doesn't seem to happen every time.

Use a test-drive contribution page set up for a £1 membership that runs for 7 days. Got taken to the GC sandbox where I filled in the form using my details and the dummy bank account data. That all appeared to be successfully accepted, and got taken back to my development site to the 'thank-you' page, where the error message was displayed: "Error: Sorry, we were unable to set up your Direct Debit. Please call us."

Nothing logged in my PHP error log, and nothing recorded in my GC sandbox account. Any insight/pointers most welcome.

I set everything up as outlined in the docs.

Tried a live test, with my real bank details.

I got redirected to Gocardless and then it redirects me back to my website but with a failure message:

"Error Sorry, we were unable to set up your Direct Debit. Please call us."

Any ideas? How can I debug this?

Found following in the error log

PHP Fatal error: Call to undefined function GuzzleHttp\Handler\curl_reset()

Searched and found it is related to php version

Is there any alternative for people using old version of php?

Thanks
Kajan

Currently this extension disables the sending of receipts. I'm not quite sure of the rationale behind this particularly as this can be controlled per contribution page.

This is the relevant section of the code:

https://github.com/artfulrobot/uk.artfulrobot.civicrm.gocardless/blob/1.8/CRM/GoCardless/Page/Webhook.php#L202

As it says in the comment, if there is a requirement for receipts to be disabled it would be better to do this via a setting so that it can be turned on or off per site rather than hard-coded.

I'd be interested in hearing from others about whether they feel this is needed at all, if we should allow sites to control this via the setting on the contribution page or if we need a setting for this extension.

Veda built what looks like an excellent extension for another bureau, SmartDebit, in their UK Direct Debit extension. Later they added in some minimal support for GoCardless. There were several technical reasons why it was necessary to start over with a new extension.

However it would be great to provide a migration (automated or by other instructions) so that people who have DDs set up using that can migrate over, benefiting from the automatic updates via webhook functionality.

The good news

Is that this extension should (not tested) automatically pick up and start filling out your database with Contributions for your Recurring Contributions set up with Veda's extension.

Payment processor/instrument

id/name of the payment processor and payment instrument. I'm not sure this really matters, but it probably should matter and might do one day.

Catchup

Anyone who has DDs set up through Veda's extension will have the situation that they have one Pending contribution against the DD. This extension will, on receiving a payment webhook will find this Pending contribution and will assume that this is the first payment on the DD and set the date accordingly. This might not be what you want, and anyway, hopefully you have contributions before this to back-fill.

trxn_id on the initial Contribution is set to the subscription ID. This probably won't cause confusion except if anyone implements any further integration based on this extension's expectation that trxn_id refers to a payment.

You can fix both of these by

1. Remove the trxn_id from the Pending contribution (which might not be Pending any more if you've manually changed that).
2. Do an import of payments to-date against the recurring payment (is this a standard feature of CiviCRM's import?)

Hi,

thanks for creating this - looks like it will be great! However, I've set up the payment processor in Civi, am pretty sure access tokens and TEST webhook secret are correct and match what I've entered on GoCardless, webhook are being received, but so far the GC Subscription ID is not being stored in the Civi TransID for the "forward-dated" payment.

The log shows several webhook messages received from GC, but these are ignored:

Jun 26 13:20:02 [info] Ignored unimplemented webhook event id: 'EV000Q990R7D6Z' resource: 'mandates' action: 'created'

Jun 26 13:20:02 [info] Ignored unimplemented webhook event id: 'EV000Q990S54EE' resource: 'subscriptions' action: 'created'

Jun 26 13:20:02 [info] Ignored unimplemented webhook event id: 'EV000Q990TDQGS' resource: 'payments' action: 'created'

Jun 26 13:20:02 [info] Ignored unimplemented webhook event id: 'EV000Q990VTSEB' resource: 'subscriptions' action: 'payment_created'

Shouldn't the SBxxxx Sub ID be written into the Civi payment record when it is first created, so that when the payment is actually made the GC webhook can identify it?

Best wishes

Tom

I've been testing this for my organisation's Civi install using the test mode. It all seems OK from a user-facing angle. But looking at the GoCardless developer console the webhook history shows 200 OK responses from Civi with the a response body containing the following:

 <span class="status-fatal">Sorry, due to an error, we are unable to fulfill your request
at the moment. You may want to contact your administrator or service provider with
more details about what action you were performing when this occurred.</span>
    <div class="crm-section crm-error-message">You do not have permission to access this page.</div>

The site in question is running Civi on top of WordPress, not Drupal. I'm just wondering whether anyone has any advice on what permissions I need to grant to who to get this working. (If this is a consulting question, I will check with my org if we have the cash to pay to get this working.)

I'm coming back to this after some time away form it, and pleased to see that newer releases have been made with more features. Thank you!
Given that my client runs paid events and has a history of members paying with one-off payments each year, I'm planning to implement this alongside a Paypal Standard processor so that we can continue to use that for event payments and for those that perhaps don't want to get into a direct debit scenario for their membership.
I'm also aware that some time back on another project I tried to run two payment processors side by side and they both broke as a result, so thought I'd ask here if anyone has had any experience - positive or otherwise - of running the GC extension alongside another payment processor.
Thanks for any feedback.

Have tried installing on a test machine and a production/live site, on which both the vedaconsulting module and other payment processors had been installed. I haven't got this payment processor to work properly yet. But slightly worrying is that if I attempt to uninstall this artfulrobot extension on the live site, the live site goes down with a HTTP 500 error; one of the PHP files in this extension is expected and missing. Fortunately I was able to us drupal drush to re-enable the extension.
I think this is a self inflicted problem. But what I would really like to be able to do is clean up these two civicrm installations and remove all traces of previously installed (payment processor) extensions, and start again. Reading elsewhere that it appears to be very difficult. I have compared my test civicrm database pre and post extension installation. Installing an extension inserts records in various tables and it's not clear to me, without going through the code and may be even stepping through the code, how the database is changed. I should have taken a database snapshot before i started! Any thoughts about cleaning up gratefully received.

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?

I'm getting payments being updated in Civi as Completed, and all seems well except that the GoCardless fee is not being updated in Civi - the Fee Amount is 0.00 and the Net Amount is the same as the amount donated. Is this as expected?

I'm not sure how CiviCRM handles this, or should handle this, for something like a Direct Debit. Does it 'Complete' one ContributionRecur record and create another to describe the new arrangement? What happens at GoCardless in terms of subscription IDs?

Needs a plan.