CiviContribute Not Passing Correct $ amount to Payment Processor

[penguintrax]

We have a situation with a client that just came to light - Event Registrations and Contributions over a certain dollar amount (basically over $1000) are not being charged through Moneris properly. For example, we have a 3299.60 value transaction that only charged $3 to the credit card, and a 1649 transaction that only charged $1. I can't even describe the impact of this problem, but it's a non-profit that's now missing thousands of dollars in revenue.

Moneris says they are processing live transactions for the dollar amount passed to them, and I have successfully matched a Moneris transaction number to the CiviContribute record, so it appears that the problem is within CiviCRM.

We have previously run successful and problem-free transactions through the site and the only change to CiviCRM before this happened was the addition of the CiviDiscount extension. We are using CiviDiscount to allow admin assistants to pre-purchase registration 'blocks' for event attendees, then when the attendees are identified, they use a discount code to register themselves for the event.

Please let me know what other information I can provide to assist with troubleshooting this problem. I have not attempted to disable CiviDiscount and run a transaction as this is an ongoing registration and I don't want to lose the discount codes and their usage created to date.

Joomla 2.5.18
Civi 4.35

Note: we have not upgraded to the 4.4 stream as we are having ongoing issues on other sites with cron jobs, etc. however if an upgrade to 4.4 will resolve the issue, we will do it.

Thank you in advance for your assistance.

[Donald Lobo]

1. is this an english language site or is it french (or a language where the comma is used as a decimal separator)

2. since u r losing donations, i would disable cividiscount and see if it fixes that

3. since the money involved is considerable, i would strongly recommend hiring someone from our service providers listing and tracking and fixing the bug. please do provide the patch upstream for other folks

lobo

[Eileen]

This is probably not helpful for you right now but I hit the same thing with Stripe & came to the conclusion CiviCRM should be handling the $ locale before it passes the string to the payment processor - https://issues.civicrm.org/jira/browse/CRM-14011

Is the site currency in dollars?

[penguintrax]

Thanks Eileen.

Right now I replaced the comma with a space and waiting for the client to get the transaction report from the credit card processor to see if that fixed it.

Amounts are in Canadian dollars for this one.

[penguintrax]

This is probably not helpful for you right now but I hit the same thing with Stripe & came to the conclusion CiviCRM should be handling the $ locale before it passes the string to the payment processor - https://issues.civicrm.org/jira/browse/CRM-14011

Is the site currency in dollars?

Eileen,

is there some sort of patch that I could apply or change I could make to test this theory? The client is using Moneris for the Payment Processor. What I'm stymied by is that these are not CiviMember or CiviEvent transactions - they are straight up CiviContribute payment pages. I guess the CiviDiscount plugin is just hooking into things and causing the problem? Transactions work with CiviDiscount is disabled.

Using a space instead of a comma as a thousands separator did not resolve the issue.

Barbara

[m4olivei]

Hello,

I'm seeing the same issue on one of the sites I manage.  It has everything to do with the reported bug here:

https://issues.civicrm.org/jira/browse/CRM-14011

Which aptly points out that the current state of affairs for implemented payment processors is that the payment processor is responsible for removing money formatting before passing the amount off to the processor.  For Moneris, which ships with core CiviCRM, this is not done correctly, here is the conversion the Moneris class within CiviCRM attempts (civicrm/CRM/Core/Payment/Moneris.php):

Code: [Select]

...
'amount' => sprintf('%01.2f', $params['amount']),
...

When there is a "," in the input string, this will truncate the number to the amount before the ",", ie 1,000.00 becomes 1.00.  Essentially then, because all inputs coming into this function are formatted with a ",", all amounts greater than or equal to $1,000.00 get severely reduced.  Using the suggestion from https://issues.civicrm.org/jira/browse/CRM-14011, a solution would be to run the amount through CRM_Utils_Rule::cleanMoney before sending the amount to Moneris, ie replace:

Code: [Select]

    $txnArray = array(
      'type' => 'purchase',
      'order_id' => $my_orderid,
      'amount' => $params['amount'],
      'pan' => $params['credit_card_number'],
      'expdate' => substr($expiry_string, 2, 4),
      'crypt_type' => '7',
      'cust_id' => $params['contactID'],
    );

with

Code: [Select]

    // Take out non-numeric characters from the amount string before formatting to float
    $params['amount'] = CRM_Utils_Rule::cleanMoney($params['amount']);

    $txnArray = array(
      'type' => 'purchase',
      'order_id' => $my_orderid,
      'amount' => $params['amount'],
      'pan' => $params['credit_card_number'],
      'expdate' => substr($expiry_string, 2, 4),
      'crypt_type' => '7',
      'cust_id' => $params['contactID'],
    );

I'm testing that solution.  I should also note that they don't use CiviDiscount.  Also if I am right in this, then plugins/extensions are not an issue unless there is something impacting the amount string that gets passed to the CRM_Core_Payment_Moneris::doDirectPayment function.  If anyone can chime in on that, that would be great, as I'm not too familiar with the form processing system Civi uses, which makes it difficult to debug, even using Xdebug.

Thanks,
Matt

[m4olivei]

Note that my continued study and progress can be found in the corresponding issue:

https://issues.civicrm.org/jira/browse/CRM-14011

[penguintrax]

Matt,

For whatever it is worth, when I disabled and removed CiviDiscount, Moneris passed the correct amount forward for processing. I only saw the issue when CiviDiscount was enabled.

Will take a look at your results in the Issue Tracker, but it's going to be a hard sell with the client to try and use CiviDiscount again. They won't want to use live transactions to test and I've never been able to get the Moneris Test Environment to work for us.