doPayment vs doDirectPayment and $0 payments - regression, bug or feature?

As per https://github.com/iATSPayments/com.iatspayments.civicrm/issues/362 it appears that the switch from doDirectPayment to doPayment can result in $0 transactions being sent to payment processors.

@mattwire has kindly provided some code to handle the issue in this extension, but I wonder if it was intentional, and if so why, and if it should be documented somewhere.

Or whether doPayment should be smarter?

added comp:CiviContribute comp:Payments sig:unverified-bug labels

Thanks for reporting @AlanDixon. I think maybe @JoeMurray could know more about this.

@AlanDixon yeah I think somewhere way back it was decided that payment processors might want to do something with $0 transactions so it was left to the payment processors to do an early return - ie

if (!empty($params['amount'])) {
  return;
}

Has always been in the parent doPayment & winds up being copied to the child

Okay, so I think you're claiming "feature", which I can see the argument for.

But I think you've got an extra exclamation mark in your code. I assume this is because the feature was very exciting!

Flagging this for future documentation ...

@AlanDixon yeah perhaps one of those features that got added because 'it might be useful' - which is the definition of a hard-to-maintain feature as you are hitting (I think I've learnt the less about this sort of thing somewhere along the way)

Sorry, I am not feeling able to help on this. Thankfully I have forgotten more about disputes about $0 tansactions than I can remember. My overriding sentiment is I just want the code to work, and I wish we had had a standard that said $0 transactions have been supported never, nowhere, or always, everywhere.

I think they were removed then put back given some pushback, maybe from dgg. And there were issues with member payments and event payments. But mostly it's like a zombie problem that never really disappears.

Thanks for this - the background, even murky, is useful.

And the correct conclusion for payment processors is: core is ambivalent about whether it should send $0 payments to a payment processor, so best to handle them explicitly, especially when upgrading your code to using doPayment (from the old doDirectPayment).

removed sig:unverified-bug label

added triaged label

So...what do we do with this ticket then?

This needs to be documented. Probably somewhere here (https://docs.civicrm.org/dev/en/latest/extensions/payment-processors/create/) at the same time as:

financial#141 (closed) financial#135 (closed)

added needs:docs need update label

Hi,

Thank you for raising an issue to help improve CiviCRM. As you may know, this issue has not had any activity for quite some time, so we have closed it.

We would like you to help us to determine if this issue should be re-opened:

• If this issue was reporting a bug, can you attempt to reproduce it on a latest version of CiviCRM?
• If this issue was proposing a new feature, can you verify if the feature proposal is still relevant? Did it get the concept-approved label? Have other people also shown interest? Could it be implemented as an extension?

If the answer to either question is yes, please feel free to comment or re-open the issue. Please also consider:

• Is it something that you could help implement, either by sending a patch or hiring someone who can?
• Would you be willing to fund the work, either through a CiviCRM partner, or the Core Team?

Thank you for your help and contributions to CiviCRM.

P.S. This is an automated message, see infra/gitlab issue 20. We understand that automatic responses are annoying, but given the number of open issues as the project evolves, we need a bit of help to triage and prioritise the most relevant issues.

closed