$0 transactions: Error: There is a problem with the payment gateway. If the problem continues please contact support. #362
Comments
|
Hi Rob - you can't submit $0 to a Payment Processor. In fact for iATS minimum is $1 as $0.10 would cost more in transaction fees than the $0.10 would bring in. I would recommend you create a separate Contribution page to handle Gift Memberships [and don't hook up a Payment Processor on that page]. |
|
Thanks. Obviously sending a $0 transaction to a payment processor is pointless, but the scenario needs to be handled appropriately by the extension. It worked prior to 1.74. And it worked with FirstData. Seems like there should be logic in the extension that if the amount is zero, the function should just return true (or whatever value makes sense). It's not a simple enough scenario to use a different form. CiviCRM actually handles it nicely. If a discount code results in a transaction amount of zero, the payment section collapses/disappears and the form just gets submitted. The iATS extension needs to do this as well. I'll send you a URL you can try via Mattermost so you can see how it should work. |
|
As a general statement, it's clear that a 0$ transaction shouldn't be sent to a payment processor. My assumption is that civicrm code shouldn't be invoking the payment processor extension code if the amount is $0, and I believe that has been the case in the past. But the first pay code does work differently, and it's possible that the mix of discount codes w/ first pay is generating a $0 request to the payment processor code and perhaps the extension should be handling those explicitly. On the other hand, we do have lots of clients using first pay and this is the first report, so it might be core code related as well. |
|
I'll tell you everything I know. We were long time users of FirstData payment processors using the core settings for them. But it's unmaintained and has gotten flaky so we switched to iATS in early December. We were using 1.72 of the extension. I can confirm that our gift memberships worked fine. Peggah at iATS confirms that we are using First Pay. We are still using CiviCRM 5.13, as we have been stuck on php 5.6 for a while. As of mid-March we have solved the php 5.6 problem and can switch to php 7.x and the latest CiviCRM whenever there's a quiet moment, but that moment hasn't come yet. So CiviCRM 5.13/php 5.6 has been a constant throughout our experience. I upgraded to v1.74 of the extension on March 31 to deal with the cryptogram error, as I mentioned earlier. Soon after, we started getting this error message. I can confirm that 1) we have no reports of that error prior to the upgrade, 2) we started getting reports of errors after the upgrade, 3) searching our contribution records, there are no instances of successful "free memberships" since March 31, 4) I have run real transactions simulating the gift process, and adding a $1 donation to the gift process results in a successful transaction, and 5) adding nothing to the free membership ($0) results in the failure. The only thing that's changed has been upgrading to v 1.74 from 1.72. |
|
Thanks for the extra details. There was a 'rebasing' of the extension in that upgrade, deprecating some old methods. I suspect that might be the issue considering you're running such an old civi version. Here's a summary: Strategically, I'd suggest you prioritize upgrading your civi version before anything else, that's a security concern that you don't want to expose any longer than you have to. I do recall in an older version of civicrm that it used to generate 0$ membership contributions and no longer does. |
|
Thanks. Could I ask you to humor me, and test this? Create a contribution page with a membership section, using a priceset, and a membership that costs $0 and see if you can complete the "transaction". I did just that, and it still failed. So it doesn't appear, at least, to have anything to do with the discount code. My calendar is full so doing the upgrade now, with all the requisite testing of our extensions, would be a problem. And I am not even sure it will solve the problem. |
|
I am also encountering this issue. It looks like the switch from doDirectPayment to doPayment is the source of the issue. I am seeing this on a Wordpress 5.7.1 with PHP 7.4 and CiviCRM 5.36.1- no plugins or additional extensions are turn on |
|
Since we are using totally different versions of CiviCRM it seems very unlikely to be a core issue. The only commonality is a new version of the iATS extension. |
|
The reason we had to switch from using
|
|
Yeah - doPayment has a check for $0 contributions but it isn't catching in our cases. |
|
I suspect there may be some missing mapping between |
|
@tommybobo - thanks for figuring that out! |
|
@KarinG Sorry for the confusion the $propertybag isn't in use until 5.38. I tested the alpha with no change in result. I am wondering if the Payment is being sent to iATS before the check is even done. -- I am not seeing the error for no billing address when I submit a zero dollar transaction with only an email. |
|
I've opened an issue regarding the same problem here #356 - it was just closed w/o any real resolution. |
|
|
|
@tommybobo - ah I see what you mean now -> this casting '$propertyBag = \Civi\Payment\PropertyBag::cast($params);' was only introduced very recently and not in a release. I've asked Matt to see if/how he handles $0 with Stripe Extension.
|
|
It is not to do with propertyBag but because the switch to doPayment overrides the original method on CRM_Core_Payment and we have to re-implement the 0 amount ourselves. |
|
Awesome - thanks Matt! 🎉 @tommybobo -> can you please test Matt's PR #363 (Matt says he has not tested it yet) |
|
I am getting this error.
|
|
Posted to civicrm issue queue here: https://lab.civicrm.org/dev/core/-/issues/2589 |
|
Would be any further movement performed here in regards of https://lab.civicrm.org/dev/core/-/issues/2589#note_58998 please? |
|
I've created a PR here: Testing welcomed. |
This works for me, even in CiviCRM 5.13. I tested both $0 and $ > 0 transactions. Thank you for coming through with a fix for this problem. |
|
@tommybobo -> can you please test Alan's alternate PR -> #364 - It's super simple and very effective. If you can confirm that it works we'll merge it in. |
|
@KarinG |
We recently upgraded to the iATS extension v1.74 in order to deal with #326 "cryptogram" error. Previously we were on a slightly older version maybe 1.72?
We have run into a problem where $0 transactions result in an error:
Error: There is a problem with the payment gateway. If the problem continues please contact support.
$0 transactions happen when a 100% discount code is used using CiviDiscount. A "gift" membership, in our case.
We didn't have a problem with these as far as I know prior to 1.74.
Suggestions?
The text was updated successfully, but these errors were encountered: