Skip to content
This repository has been archived by the owner on Jun 25, 2021. It is now read-only.

GoCardless fees not sent by GC so not recorded in CiviCRM #19

Open
TomCrawshaw opened this issue Jul 6, 2017 · 8 comments
Open

GoCardless fees not sent by GC so not recorded in CiviCRM #19

TomCrawshaw opened this issue Jul 6, 2017 · 8 comments

Comments

@TomCrawshaw
Copy link
Contributor

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?

@TomCrawshaw
Copy link
Contributor Author

Update. I got the following from GoCardless, which explains why Fee & Net Amount are not being set correctly:

"At present we don't provide fee information through the API, either via webhooks or against payment resources.

I do believe that adding a Fees endpoint is in discussion, so I'll pass your feedback on. At present, you'd need to calculate locally using the payment amount. "

Making this calculation is quite easy, but there is no neat way to set the fee calculation except by modifying Webhook.php case by case - any plans to change this?

@artfulrobot
Copy link
Owner

Hi Tom,

I don't have a plan to change this as I don't need it :-) and implementing code for a particular pricing structure adds a further thing that can break in future if/when they change things - e.g. if GC introduced a premium account with different fees users of this extension might expect it to know about this. I think it's safer to wait until GC actually tell us what fees they've taken, then develop the feature to record that in CiviCRM.

Rich

@artfulrobot artfulrobot changed the title GoCardless fees not being deducted from Civi GoCardless fees not sent by GC so not recorded in CiviCRM Jul 11, 2017
@TomCrawshaw
Copy link
Contributor Author

TomCrawshaw commented Jul 12, 2017 via email

@artfulrobot
Copy link
Owner

Yeah, the clients of mine who use this don't use CiviCRM for their accounts (in fact there's often a bit of tension between finance types and CRM types in terms of who has the authoritative data!), so they just need to know the gross income, but I take your point. PRs welcome :-)

@artfulrobot
Copy link
Owner

Just to note: shortly after musing that GC might change their pricing structure, they did, for new clients. So now we genuinely can't tell what fees were taken until the API tells us this.

@artfulrobot
Copy link
Owner

artfulrobot commented Nov 16, 2018

I think GoCardless might now include transaction fees in the data they hold on payments, so this becomes a possibility.

Actually, while you can access this from the GC website, it seems they have not made this available in their API model

They had this to say on the matter to someone else. Hints that there may be a backwards after-the-event way of adding the information in via a payout hook. This means your net income in CiviCRM will go up and then down! Hmm, not very satisfactory.

@aydun
Copy link
Contributor

aydun commented Sep 2, 2020

In the thread @artfulrobot referenced someone has posted code to get the fees from a 'paid out' event webhook. As I read it, GC are saying the actual fee is complicated and not known until it is paid out, but even then, refunds need handling as there are many types of PayoutItem

It looks like we could update the fees for the majority of payments but some more esoteric situations could add a lot of complexity.

@artfulrobot
Copy link
Owner

@aydun yes. We could implement the webhook to catch payments that change status to paid out (I think that's a thing), and then it could try to fetch/calculate the fees and update the contribution accordingly. There'd still be a lag, but the whole GC thing is very laggy anyway (i.e. 'pending' initial contribs for 5 working days), much to the annoyance of fundraisers everywhere!

PRs welcome.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants