Contribution page creates a wrong amount and probably payment processor use this wrong amount

changed the description

@eileen, @JoeMurray, @bgm - would you have a look at this? Is this by any chance related to #2394 (closed)?

added triaged label

@DaveD mentioned #2195 in the (similar) ticket #2446 (closed)

It looks to me like a conversion to float is happening somewhere in order to change the xxx99 to xxx9875. We tried to fix core several years ago to get rid of that except in places where there was division and maybe multiplication. What is the payment processor here? It may be causing this to occur.

How the decimal point slides at the same time is mysterious to me.

I see MySQL conversion from decimal to float to decimal in versions 5.7 and 8.0 may result in some loss of accuracy when you get near 15 digits https://dev.mysql.com/doc/refman/5.7/en/type-conversion.html . The figures above have in the erroneous result 14 digits before the decimal and two after. Maybe there is an operation in a query causing this result...as I recall previously we were only checking the php in the codebase.

This issue is about the moving of the decimal point (which is set to comma ,). The payment processor used is the dummy payment processor.

This one is not related to #2446 (closed). #2446 (closed) is about the money drop down custom fields and with not selecting the right option upon edit but showing the right value anyway. This issue is really about amounts changing during the payment process on a contribution page.

@jaapjansma is this only replicable with a really long number?

changed the description

I had another look at this issue at the problem also occurs when you enter an amount of 12,987654321 The comma is the decimal separator. So basically one needs to enter more digits after the decimal and comma as a decimal separator.

It is caused by this line https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution/Confirm.php#L2776

In the function processConfirm in the class CRM_Contribute_Form_Contribution_Confirm by the line $paymentParams['amount'] = CRM_Utils_Rule::cleanMoney($paymentParams['amount']);

Here is more context around the line.


if (!empty($form->_paymentProcessor)) {
        $contributionParams['payment_instrument_id'] = $paymentParams['payment_instrument_id'] = $form->_paymentProcessor['payment_instrument_id'];
      }

      // @todo this is the wrong place for this - it should be done as close to form submission
      // as possible
      $paymentParams['amount'] = CRM_Utils_Rule::cleanMoney($paymentParams['amount']);
      $contribution = CRM_Contribute_Form_Contribution_Confirm::processFormContribution(
        $form,
        $paymentParams,
        NULL,
        $contributionParams,
        $financialType,
        TRUE,
        $form->_bltID,
        $isRecur
      );

Basically what the cleanMoney function does is removing the comma (decimal separtor) and suddenly the amount is changed.

@eileen, @colemanw or @mattwire does any of you how to solve this? I am not sure whether the call to cleanMoney needs to happen as I would assume that the amount in the function has already been validated and sanitized.

@jaapjansma no the clean money should be removed - as the code comment suggests - this sort of double cleaning used to happen a lot - hence we switched to 'clean once clean early' - that line obviously fell into the 'this is really scary lets just add a comment instead of changing it' but if it is causing a bug then it must go

I have added a PR which removes the call to CRM_Utils_Rule::cleanMoney.

See https://github.com/civicrm/civicrm-core/pull/19807

Contribution page creates a wrong amount and probably payment processor use this wrong amount

Child items ...

Activity