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

Sorry, there was an error contacting the payment processor GoCardless. #74

Closed brucec909 closed 3 years ago

brucec909 commented 4 years ago

I'm trying to set GoCardless up with CiviCRM in Drupal. I have the gocardless extension installed okay, and have successfully managed to set up some test payments which GC is happily processing every month.

But since updating Drupal and Civi, it's all stopped working - every time I try to add a new member/payment I'm told: Sorry, there was an error contacting the payment processor GoCardless.

I've looked over the php and drupal logs and found nothing useful – or at least, nothing that's useful to me. Do you have any idea what might be going on? Or at least any thoughts on where I might start looking? Thank you.

Upperholme commented 4 years ago

The GoCardless extension should be writing its own log file inside your ConfigAndLog folder. That may help cast some light.

brucec909 commented 4 years ago

Thank you for the suggestion – there is indeed a GoCardless log file in ConfigAndLog. I've looked, though, and there doesn't seem to be anything relevant in it.

Upperholme commented 4 years ago

I guess the next question is what versions of Drupal/CiviCRM were you using when it was working, and what have you upgraded to? Can you roll back?

artfulrobot commented 4 years ago

@brucec909 It seems strange that there's nothing relevant in the log file, since the line of code that writes to that file is directly after the error you saw. It should write a line with "CRM_Core_Payment_GoCardless::doTransferCheckoutWorker exception" in it?

Is there anything in that file? What's the permissions - is the user that CiviCRM (PHP) runs as able to write that file?

brucec909 commented 4 years ago

Okay...

First – perhaps I was too hasty to write off the log file contents as not relevant. It contains the following line:

"[error] CRM_Core_Payment_GoCardless::doTransferCheckoutWorker exception: The access token you've used is not a valid live API access token"

followed by some extensive detail.

I shall start digging from there – many thanks for your help so far!

brucec909 commented 4 years ago

So I learned from the responses to another question here to ensure that I've specified different webhook secrets for Live and Test payments. I've checked, and the secrets are definitely different, but attempts to set up new payments still fail. And beyond that suggestion I can't find anything else to suggest why it might not be working.

@Upperholme - thank you for the ideas. I could in theory roll back the versions. At present it's a test setup, so I could in fact uninstall and start over from scratch if necessary, and I might end up doing that yet. I'd just prefer to find a less drastic solution if such a thing exists. We want to get this thing live as soon as possible...

Any further suggestions gratefully received.

artfulrobot commented 4 years ago

@brucec909 ok, sounds like you're getting somewhere. Nb. you can also learn about how to use it in the readme which includes some explicit information about that topic. It's not as well structured as it could be - but documentation is often unfunded - once people get it working they tend not to contribute any more!

I'd say there would not be any benefit from rolling back your database - it's a simple configuration change in the Payment Processor admin page (and possible at GC if you put the same secret for live and testing there).

brucec909 commented 4 years ago

Thanks. Momentarily I thought I might be getting somewhere too!

Sadly it appears not. I've checked and double-checked the configuration at both ends. Even created a new GC access token in case that was the problem. I now have different access tokens and different secrets for Live and Test payments – but still the same outcome. When I send a test webhook from GC it works perfectly, but when I try to submit the subscription form in CiviCRM I get the error. (see attached).

Perhaps interestingly, CiviCRM lists the newly created memberships as though they had been processed properly despite having given me the error. There's no indication in GC's logs of it having received anything from Civi.

I'm starting to suspect that either I'm missing something really obvious, or something has become irrevocably broken by updating Drupal and CiviCRM.

I did notice this suggestion in the other thread I referred to earlier:

"In your ConfigAndLog/gocardless log file look for the line that says completeRedirectFlowCiviCore: called with details: ... that should include a parameter test_mode set to either 0 or 1. If you're doing test payments it should be a 1."

Might it be relevant that this line is not present in my GC log file? For instance, might that suggest that the process is failing before a certain point which might in turn help to narrow down the possible causes?

gc_error

artfulrobot commented 4 years ago

If there's no completeRedirectFlowCiviCore: called with details... in your GC log file then either the log file is not writable or the function is not called - the code to write to the log is the first line in the function.

From the screenshot, it looks like you have other validation errors on the form - which would explain it not being called.

Also, if the error you're seeing in the logs is "The access token you've used is not a valid live API access token" but you're doing a test then it sounds like you have your test credentials in the live payment processor config.

To test you should have

You cannot - for example - stuff test keys/secrets into the live payment processor.

?

brucec909 commented 4 years ago

Well... working on the basis that the log file is writable (since it is being written to!), then we have to assume the function is not being called.

I take your point about the significance of the word 'live'. However, I'm quite sure I don't have my live and test credentials mixed up. I defintely have my test key and secret under the test payment processor, and I'm definitely using the forms in 'test drive' mode.

What other validation errors are you suspecting on the form, based on my screenshot? If you mean the 'You are completing the form on behalf of someone else' message, then that's exactly what I'm trying to do, entering their details on the form as per this screrenshot.

Indeed I've established through trial and error (presumably this is of some significance) that the failure only occurs when I try to submit the form on behalf of someone else. It appears to work more or less as expected if I submit while logged in to the relevant Civi account.

Might this be by design? (We collect paper mandates from our members, and it's important to our workflow that the data from those paper forms can be entered by our admins on their behalf).

Thanks again for your patience and help.

verity_hayes_01

Upperholme commented 4 years ago

Sounds like you have successful test transactions as long as you don't mess about with the form. I'd say that's a result.

brucec909 commented 4 years ago

I agree! Result!

But all the same, I'd love to figure out whether what I'm trying to do can actually work...

artfulrobot commented 4 years ago

Might this be by design? (We collect paper mandates from our members, and it's important to our workflow that the data from those paper forms can be entered by our admins on their behalf).

I'm sure you've checked the legality of that in the UK. (I don't mean to scare you and I'm not a lawyer.)

Back to GC, I don't understand why this would make much of a difference, though. It looks like what's happening is that at some point in the process, CiviCRM/this extension is forgetting that you're in test mode and is trying to complete test redirect flows with the live GC API endpoint.

It would be good to get this nailed down and fixed but it's not going to be a small task.

brucec909 commented 4 years ago

Ha! Well, the law isn't my department either, but the way I understand it, as long as we have a signed paper mandate we are allowed to transfer the details manually into a database.

Anyway, I'll let others worry about that – for now I just want to try and get it working!

I'm more than happy to try and get it sorted, both because we would benefit directly and for the greater good of it, and I'm not daunted by the scale of the task. (It's not like I have to go out or anything since I'm on coronavirus lockdown!) But I'm not sure where to start looking. Can you give me a clue?

artfulrobot commented 4 years ago

This is the function that is used to generate the redirect flow https://github.com/artfulrobot/uk.artfulrobot.civicrm.gocardless/blob/1.9.2/gocardless.php#L133

Redirect flows are explained here: https://developer.gocardless.com/api-reference/#core-endpoints-redirect-flows

In a nutshell

  1. ask GCAPI for a redirect flow
  2. store some details
  3. send the user to the redirect URL (returned from (1))
  4. once user completes that, we're sent the redirect flow ID back (which we intercept at https://github.com/artfulrobot/uk.artfulrobot.civicrm.gocardless/blob/1.9.2/gocardless.php#L143 )
  5. look up the redirect flow by its ID, attempt to "complete" it (sets up the mandate)
  6. set up subscription within the mandate and update CiviCRM's records.

seems you're stuck on (1). I'd fire up xdebug and put a breakpoint on in https://github.com/artfulrobot/uk.artfulrobot.civicrm.gocardless/blob/1.9.2/gocardless.php#L133 and step through to see what's happening - I think what's happening is that it's using the live API server for test credential (or the other way around).

artfulrobot commented 3 years ago

Closing as I've not heard back for 6 months or so. Feel free to reopen.