When trying to use the "change billing details" option in a membership, a there was some problem updating the billing details error message, as shown in the screenshot:
With a step-by-step debugging session, I found that CRM_Core_Payment_Smartdebit::updateSubscriptionBillingInfo isn't properly reading the subscription reference:
In particular, it's receiving the subscription reference in the $params array as ddi_reference but reading it as subscriptionId. The consequences I've found are:
Hi @mattwire, is this issue affecting you, too? If not, what versions are you using? My hunch is that this might be happening because I'm not using the right selection of versions.
as shown here, this finally relies in CRM_Contribute_BAO_ContributionRecur::getSubscriptionDetails,
The issue here, as I see it, is that this function is using the processor_id field, rather than the trxn_id which is the field that's actually populated (or at least has been). Here's what I mean:
For a long time we had a problem with cancelling subscriptions because of these two parameters (trxn_id/processor_id). That was fixed around about 5.19 with the introduction of doCancelRecurring().
A "fix" for smartdebit is to populate both trxn_id/processor_id and to provide an upgrader that does that for existing ones.
But I would really like to see some work towards sorting this out properly in core - can you open a lab issue to discuss? This comment can be used as reference: dev/financial#57 (comment 19168)
I can see a potential solution by copying processor_id to trxn_id in CRM_Contribute_Form_ContributionRecur::getSubscriptionDetails() and dropping trxn_id if we can verify that it's not being used by any processors (we could have a temporary mapping of trxn_id -> processor_id when saving as well).
I've just been making some tests by adding the processor_id to some recurring contributions and trying to update their billing details.
Before setting the processor_id I was getting the error described above. But after setting it, although the URL build by CRM_Smartdebit_Api::requestUpdate now seems correct, I'm now getting a 500 error from SmartDebit:
I'll be posting more details as I advance with the research.
My requests are now working although I'm not yet getting a successful message after the change is done. But, at least, this should restablish the communication between Smart Debit and CiviCRM, when updating billing details.
What I've done, so far, is:
populate processor_id in recurring contributions from the trxn_id when the first was NULL,
change the way variables where being passed in PUT requests.
This second I did it by changing this switch, leaving it as follows:
@capo I have merged the fixes but not yet the new API - see 33427409
I don't want to merge a new API until we have a proper fix ready for CiviCRM core/this extension that actually populates the processor_id in the first place - @capo what do you think?
@capo It looks like smartdebit have restricted how POST params can be sent. Previously we were passing some as URL parameters for PUT/POST but that no longer works - so might be the source of your 500 errors? Please test with the latest master branch as I've simplified / refactored the POST/PUT to be consistent with the API docs here: https://apidocs.smartdebit.co.uk/