Closed michaelmcandrew closed 3 years ago
It was definitely helpful to see the CiviCRM ids in GoCardless when we were first testing the integration.
Metadata is supported by GC on
Key-value store of custom data. Up to 3 keys are permitted, with key names up to 50 characters and values up to 500 characters.
Because of the 3 key limit, I propose to use the key civicrm
and then we have 500 characters to use for a JSON object that would include:
contactId
contributionRecurId
membershipId
(if applicable)Currently we don't track mandates directly in CiviCRM, but we do store subscription IDs (contributionRecur.processor_id
) and payment IDs (contribution.trxn_id
).
I think a sensible proposal would be:
Thoughts?
That sounds sensible to me. I don't think there is a need to store data on the individual payments.
I'm in two minds about storing it as JSON though. I think this could make it less easy for non-technical users to understand. I guess I'd need to see how it looked in practice within GoCardless.
@wmortada if we use all three fields up, we've not left any room for future changes. I think JSON's pretty readable- I know I'm technical, but it only adds a few " and {} to pretty standard english construct like colour: red, height: tall People who are looking at this are already aware of some pretty technical stuff (contact IDs for example).
Yes, you are probably right. I don't have a strong feeling about it.
Cheers for chipping in though @wmortada - always appreciated!
We inherited a client site that was running a customised version of GoCardless 1.7. One of the customisations was to enable recording of the CiviCRM contact ID in the GoCardless UI, which the client found useful. We're now upgrading to a non customised version of 1.9 but would quite like to add the feature to record CivICRM IDs in GoCardless since it seems useful for others as well, I'm thinking that this might be a useful addition to the extension.
Rich says:
I took a quick look and it wasn't clear to me how to access the contact or contribution recur id in
::completeRedirectFlowWithGoCardless()
.Some background on the motivation.
I think that the code was necessary for the client because they were transferring direct debits from an old provider and the contact ID was useful to cross check which mandates were in GoCardless already.
In my experience with Stripe it is handy for debugging in development (and also when things go wrong in production).
For reference, in case it is useful, here is the (AGPL) code that had been implemented to update the mandate in the customised extension. Important to note that this code was broken and not actually doing what they wanted it to do (I think the reference to worldpay is some copypasta).