Recurring payments after first payment are not recorded as contributions in civicrm

[tomm]

Users are able to create memberships and recurring payments are set up successfully in gocardless, but only the first payment is recorded as a contribution in civicrm and subsequent payments do not appear in civi (but do appear in gocardless). I'm not sure if this is a bug or if it is a configuration issue.

In the developer settings of gocardless I have not filled in the option "WebHook URI". Could this be the issue?

I'm using the following plugin versions:

Gocardless (uk.co.vedaconsulting.payment.gocardlessdd) Enabled 1.1 Payment Disable Smart Debit (uk.co.vedaconsulting.payment.smartdebitdd) Enabled 2.1.1 Payment Disable UK Direct Debit (uk.co.vedaconsulting.payment.ukdirectdebit) Enabled 2.3.4 Module Disable

[Kajakaran]

@tomm This is additional feature. At the moment, We create only mandate in Civi once mandate is created in gocardless. We don't handle subsequent payments.

[artfulrobot]

In GC speak, this extension does two things:

1. Provides the "redirect flow" for setting up customer, customer bank account and mandate objects.
2. It then sets up a subscription GC object against the mandate.

It's important to understand that a mandate alone does not bring you money :fearful: and you need the subscription too.

In CiviCRM I'm less sure but it seems to create a recurring contribution set to Pending and one contribution record set to Pending (Incomplete Transaction). It also does some clever stuff to link it in with a membership, if that's how it was used.

The statuses of those records in CiviCRM are then unaffected by anything further to do with this extension, as far as I can see.

[Upperholme]

Trying to understand this one: Am I correct in saying that if a user buys a membership using the GC direct debit and agrees to a recurring debit in order to keep their membership up to date, although this extension will enable them to set up that direct debit mandate with GC (which is great), and make the first payment, it knows nothing about any subsequent payments and therefore Civi does nothing about recording those subsequent payments or renewing the membership?

[Kajakaran]

@Upperholme At the moment, we don't handle subsequent payments or renewing the membership

[tomm]

I'd like to work on getting this missing support. However, I don't have funding, and the civi code generally, and payment integration code particularly, is such an intense horror show that I'm balking at doing this on my free time.

[artfulrobot]

I am working on this now.

I initially forked this GC extension code but then started from scratch because this current code is so entangled with ukdirectdebit (#16) and also is not built with civix - I'm guessing it was built before that amazing tool was written. It's created as a payment type extension, but nowadays extensions are encouraged to all be modules instead as this gives the possibility to add whatever features are required, e.g. API objects, Reports, Forms, PaymentProcessors, ... Totten's "gut feeling" was that a new extension better than trying to convert.

Also looking at what the current code does I want to make some changes to the IDs that are stored in CiviCRM (currently the trxn_id field on the contribution and recurring contribution records are set to the subscription Id. Stripe uses the invoice_id for this, which makes more sense to me since one subscription will have multiple separate transactions over time.) so that they may be of more use in the GoCardless interface. It would be good to discuss this (@veda-consulting @deepak-srivastava), I've just started work on it - chat.civicrm.org?

I am going to implement GoCardless webhooks so that when payments are made they get put into CiviCRM.

Finally, my new extension will separate out the doing code from the UI code, which means you can also access the GoCardless functionality from outside the core CiviCRM contribution pages flow (as well as in the contribution flow). This is because I want to use custom forms that result in GC Direct Debits being setup.

I'll keep you posted. I funding to develop some of the above and I will obvs focus on the needs of my client and put a bit of free time into a reasonable community effort.

[Upperholme]

This is great news Rich. I'm no developer, but would be very happy to do what i can to help this along, by way of testing, documentation, etc. Let me know.

[reswild]

I'm happy to help with a new CiviCRM extension for GoCardless. At the moment I'm using a custom built Drupal module for processing GoCardless signups and webhooks, but I have been wanting to get this into a more standard CiviCRM workflow. I did look at the Veda Consulting extension, but I also came to the conclusion that it would be better to start fresh with a new extension.

[artfulrobot]

@Upperholme @reswild @tomm This is great, thanks for support. You can follow my progress at https://github.com/artfulrobot/uk.artfulrobot.civicrm.gocardless