Financial issueshttps://lab.civicrm.org/dev/financial/-/issues2019-12-17T22:10:48Zhttps://lab.civicrm.org/dev/financial/-/issues/47Payment Instrument not set on Pending Contributions' payments when marked "Co...2019-12-17T22:10:48ZJonGoldPayment Instrument not set on Pending Contributions' payments when marked "Completed".There's an inconsistency in how payments are recorded in CiviCRM depending on how you mark them completed.
#### Scenario 1
* Record a pending contribution for a contact with whatever payment instrument you like.
* Complete the payment b...There's an inconsistency in how payments are recorded in CiviCRM depending on how you mark them completed.
#### Scenario 1
* Record a pending contribution for a contact with whatever payment instrument you like.
* Complete the payment by selecting **More » Record Payment** and entering the payment.
* Click the **pencil** to edit the resulting payment. Everything looks fine.
#### Scenario 2
* Record a pending contribution for a contact with whatever payment instrument you like.
* Complete the payment by selecting **Edit** and changing the contribution status to **Completed**.
* Click the **pencil** to edit the resulting payment. The payment instrument is blank. Moreover, any attempt to change the payment instrument results in a fatal error (similar to core#264). See below.
The backtrace below seems like a symptom of the root cause, which is in the second step (changing the contribution status) not the third step.
```
CiviCRM_API3_Exception: "Mandatory key(s) missing from params array: payment_instrument_id"
#0 /example.org/sites/all/modules/civicrm/CRM/Financial/Form/PaymentEdit.php(213): civicrm_api3("FinancialTrxn", "create", (Array:9))
#1 /example.org/sites/all/modules/civicrm/CRM/Financial/Form/PaymentEdit.php(181): CRM_Financial_Form_PaymentEdit->submit((Array:5))
#2 /example.org/sites/all/modules/civicrm/CRM/Core/Form.php(489): CRM_Financial_Form_PaymentEdit->postProcess()
#3 /example.org/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Submit.php(74): CRM_Core_Form->mainProcess()
#4 /example.org/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Submit->perform(Object(CRM_Financial_Form_PaymentEdit), "submit")
#5 /example.org/sites/all/modules/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Financial_Form_PaymentEdit), "submit")
#6 /example.org/sites/all/modules/civicrm/CRM/Core/Controller.php(351): HTML_QuickForm_Page->handle("submit")
#7 /example.org/sites/all/modules/civicrm/CRM/Utils/Wrapper.php(113): CRM_Core_Controller->run()
#8 /example.org/sites/all/modules/civicrm/CRM/Core/Invoke.php(283): CRM_Utils_Wrapper->run("CRM_Financial_Form_PaymentEdit", NULL, NULL)
#9 /example.org/sites/all/modules/civicrm/CRM/Core/Invoke.php(84): CRM_Core_Invoke::runItem((Array:14))
#10 /example.org/sites/all/modules/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:3))
#11 /example.org/sites/all/modules/civicrm/drupal/civicrm.module(345): CRM_Core_Invoke::invoke((Array:3))
#12 [internal function](): civicrm_invoke("payment", "edit")
#13 /example.org/includes/menu.inc(350): call_user_func_array("civicrm_invoke", (Array:2))
#14 /example.org/index.php(22): menu_execute_active_handler()
#15 {main}
```https://lab.civicrm.org/dev/financial/-/issues/45Custom fields ignored when searching in "Accounting Batch" mode2019-02-11T21:15:55ZJonGoldCustom fields ignored when searching in "Accounting Batch" modeSteps to replicate on a sandbox server:
* Go into Custom Fields, set **How long have you been a donor?** to be searchable.
* In **Find Contributions**, use **How long have you been a donor?** as a search criteria. Note correct results.
...Steps to replicate on a sandbox server:
* Go into Custom Fields, set **How long have you been a donor?** to be searchable.
* In **Find Contributions**, use **How long have you been a donor?** as a search criteria. Note correct results.
* Go to **Contributions » Accounting Batches » New Batch**. Perform the same search. The custom field criterium is ignored.https://lab.civicrm.org/dev/financial/-/issues/44Modifying contribution amount records a fake payment for difference2019-06-20T19:11:11ZAndie HuntModifying contribution amount records a fake payment for difference1. Create a contribution for $50 on the back end, leaving the status as `Completed` and the payment method as `Check`.
2. Edit the contribution to be $70.
3. Go back to view the contribution and see that a new $20 payment by check has be...1. Create a contribution for $50 on the back end, leaving the status as `Completed` and the payment method as `Check`.
2. Edit the contribution to be $70.
3. Go back to view the contribution and see that a new $20 payment by check has been recorded.
There's no way to remove the $20 payment, though you can edit the payment method and so forth.
I suspect this is a consequence of partial payments not being fully implemented for contributions, but the effect is unexpected and undocumented.
Another, more troubling outcome:
1. Create a contribution for $100 on the back end, setting the status as `Pending` and leaving the payment method as `Check`.
2. Record a $90 payment with cash.
3. Edit the contribution amount to be $150.
4. Go back to view the contribution and see that there is now a $50 payment by check with the status "partially paid".
5. Go to record a payment and see that the balance owed is $60. Record that payment with EFT as the payment method.
6. See that the contribution now has three payments, for $90 (Cash), $50 (Check), and $60 (EFT) despite only being for a $150 contribution. A "Record refund" link appears, but clicking it causes an error:
> Sorry but we are not able to provide this at the moment.
Finally, fake negative payments can be recorded:
1. Create a contribution for $100 on the back end, leaving the status as `Completed` and the payment method as `Check`.
2. Edit the contribution to be $70.
3. Go back to view the contribution and see that a new -$30 payment by check has been recorded.https://lab.civicrm.org/dev/financial/-/issues/43Find Contributions searches on inaccurate, redundant payment fields2020-07-09T00:48:18ZAndie HuntFind Contributions searches on inaccurate, redundant payment fieldsThis problem is somewhat related to dev/financial#37 in that there are redundant payment-related fields on the contribution record. That issue covers a record updating problem--when the contribution record isn't updated accurately to re...This problem is somewhat related to dev/financial#37 in that there are redundant payment-related fields on the contribution record. That issue covers a record updating problem--when the contribution record isn't updated accurately to reflect the payment information. This issue is that the Find Contributions search looks only for the value in the contribution record.
When there are multiple payments by check, the check number field on the contribution is updated to have both numbers, separated by a comma. So, the check number is `111,222` if the first check is `111` and the second is `222`. Searching for a contribution with check numbers `111` or `222` will yield nothing, but searching for `111,222` finds it. Obviously this is a bug, but it might properly be considered a bug in search--the search should look among the payments, not the value on the contribution.
Again, like dev/financial#37, the real solution is to ditch the redundant fields. However, in the meantime we should stop relying upon them.
It appears that card number works properly:
* Record contribution, pending pay later (setting payment method to be `Credit Card` to sidestep the problem in dev/financial#37)
* Record payment for part of the amount, payment method `Credit Card` with the card ending in `1234`
* Record payment for the remainder of the amount, payment method `Credit Card` with the card ending in `6789`
* Find contributions, payment method `Credit Card`, card number `1234`, retrieves the contribution.
* Find contributions, payment method `Credit Card`, card number `6789`, retrieves the contribution.
Since there is no card number on the contribution, the search is forced to work the right way.https://lab.civicrm.org/dev/financial/-/issues/41PSD2 support needed for PayPal by Sept 20192019-07-22T22:24:16ZAndrew WestPSD2 support needed for PayPal by Sept 2019PayPal will require PSD2 support by September 2019 - in Europe, anyway (https://www.paypal.com/uk/webapps/mpp/psd2). So Civi will need to support SCA via 3-D Secure when using PayPal - Website Payments Pro (and presumably for any other p...PayPal will require PSD2 support by September 2019 - in Europe, anyway (https://www.paypal.com/uk/webapps/mpp/psd2). So Civi will need to support SCA via 3-D Secure when using PayPal - Website Payments Pro (and presumably for any other payment methods where Civi hosts the payment fields). In practice I think this'll mean an intermediary page after payment, where people can verify their card details.
We are happy to chip in on development of this, but we can't fund it entirely.https://lab.civicrm.org/dev/financial/-/issues/39Authorize.net doesn't support MD5 hashing at the end of the month2019-07-02T14:40:29ZJonGoldAuthorize.net doesn't support MD5 hashing at the end of the monthI just saw this on [Stack Exchange](https://civicrm.stackexchange.com/q/28025/12). It seems rather urgent, since it will be a breaking change for users. I'm guessing that February 1st we'll see a lot of questions about this on Stack Ex...I just saw this on [Stack Exchange](https://civicrm.stackexchange.com/q/28025/12). It seems rather urgent, since it will be a breaking change for users. I'm guessing that February 1st we'll see a lot of questions about this on Stack Exchange.
> Authorize.Net is phasing out the MD5 based transHash element in favor
> of the SHA-256 based transHashSHA2. The setting in the Merchant
> Interface which controls the MD5 Hash option will be removed by the
> end of January 2019, and the transHash element will stop returning
> values at a later date to be determined.
>
> Merchants utilizing this feature will need to work with their web
> developer or solutions provider to verify if they are still utilizing
> MD5 based hash and if still needed to move to SHA-256 hash via
> Signature Key.https://lab.civicrm.org/dev/financial/-/issues/38Support paying refunds2020-12-05T20:23:27ZJoeMurraySupport paying refundsSee https://lab.civicrm.org/dev/financial/wikis/Refunds-via-payment-processorsSee https://lab.civicrm.org/dev/financial/wikis/Refunds-via-payment-processorsJoeMurrayJoeMurrayhttps://lab.civicrm.org/dev/financial/-/issues/37Can't search by check number for checks entered with "Record Payment"2021-10-19T05:02:37ZJonGoldCan't search by check number for checks entered with "Record Payment"Someone reported this [on Stack Exchange](https://civicrm.stackexchange.com/q/27989/12), and it's pretty easy to replicate with their steps: "when you edit a pending pay later contribution, add a check number, change status to complete a...Someone reported this [on Stack Exchange](https://civicrm.stackexchange.com/q/27989/12), and it's pretty easy to replicate with their steps: "when you edit a pending pay later contribution, add a check number, change status to complete and then i go to search contributions, enter the payment method and search by check number i get no result."
`check_number` is a field both in `civicrm_contribution` and `civicrm_financial_trxn`. I suspect this is for historical reasons rather than anything anyone considers correct in 2019.
* To solve the immediate issue, "Find Contributions" should search the check number field of related financial transactions rather than the contribution itself.
* I think there's a strong argument that `civicrm_contribution.check_number` should be deprecated altogether, but that's a much larger issue.https://lab.civicrm.org/dev/financial/-/issues/32Authorize.net Fees Not Reflected In Civi2019-01-12T19:07:11ZguyiacAuthorize.net Fees Not Reflected In CiviWhen credit card payments are made using the Authorize.net payment processor packaged natively in Civi, the credit card fees are not fed back from Authorize to Civi, and as a result do not show up in Civi. This was brought forward by one...When credit card payments are made using the Authorize.net payment processor packaged natively in Civi, the credit card fees are not fed back from Authorize to Civi, and as a result do not show up in Civi. This was brought forward by one of my clients (Helena Carvalho of AHCC) during the accounting integration presentation at CiviCamp Hartford, and confirmed by Brian Shaughnessy right after the presentation.https://lab.civicrm.org/dev/financial/-/issues/30Date filter on searching personal campaign pages2018-10-12T07:26:46ZmvuDate filter on searching personal campaign pagesWhen searching for personal campaign pages, we implemented a date filter, where you can search for any active personal campaign pages, that were active during this period of time:
![image](/uploads/6fe01b3760b06d8c847aea1186a6e9cc/imag...When searching for personal campaign pages, we implemented a date filter, where you can search for any active personal campaign pages, that were active during this period of time:
![image](/uploads/6fe01b3760b06d8c847aea1186a6e9cc/image.png)
Can we make a PR into core?https://lab.civicrm.org/dev/financial/-/issues/25event registration: support partial payments when constructing contribution2020-02-17T04:43:01Zlcdwebevent registration: support partial payments when constructing contributionThe contribution BAO add method supports two parameters that can be used to create a contribution with a partial payment: partial_payment_total and partial_amount_to_pay.
I'd like to modify CRM_Event_Form_Registration::processContributi...The contribution BAO add method supports two parameters that can be used to create a contribution with a partial payment: partial_payment_total and partial_amount_to_pay.
I'd like to modify CRM_Event_Form_Registration::processContribution() to add support for these parameters. Doing so would enable hook based modifications to pass a partial payment amount (e.g. to support a "deposit" amount on an event registration). There should be minimal impact on existing functionality as those params are not actively used. We would simply support them if they are passed to that function.
(looking for concept approval)lcdweblcdwebhttps://lab.civicrm.org/dev/financial/-/issues/20Online PayNow 'overcharges' partially paid contributions2023-06-16T09:30:23ZMonish DebOnline PayNow 'overcharges' partially paid contributionsJust noticed that when using the Pay Now functionality from the contact dashboard it does NOT take in account partially paid contributions.
Instead, a payment screen for the full contribution is shown. This can lead to overcharging peop...Just noticed that when using the Pay Now functionality from the contact dashboard it does NOT take in account partially paid contributions.
Instead, a payment screen for the full contribution is shown. This can lead to overcharging people and does not add to the fragile trust relationship we (and many non-profits) have with their donors & participants. Therefor I qualified it as a major issue.
I think the desired behavior is that the payment screen would show the build up of the total like now (it uses the price set where applicable) and under all that the required (remaining) payment should be shown (and used for the payment).
Online Pay Now functionality was introduced here:
https://issues.civicrm.org/jira/browse/CRM-19263
We use it by mailing the constructed link to our users with outstanding contributions, like:
https://mysite/civicrm/contribute/transact?reset=1&id=7&ccid=1234&cs=355345fdgda60b2d1a89f22fc643b&cid=4321
I added a screenshot of the contribution that was partially paid (20 paid out of a total of 50), and the corresponding Pay Now screen showing and charging 50, and a mockup of how it should be shown (or at least it should charge the remaining 30 and not the full 50)
Original JIRA ticket : https://issues.civicrm.org/jira/browse/CRM-21700jitendrajitendrahttps://lab.civicrm.org/dev/financial/-/issues/18Proposal - Money formatting2021-03-24T01:03:07Zmattwiremjw@mjwconsult.co.ukProposal - Money formattingWe need to look at a better approach to formatting money within CiviCRM. It should properly handle currencies, decimal places, "1000" separater (ie 1,000.00 and 1.000,00).
Some approaches:
- Money formatting functions: https://github.c...We need to look at a better approach to formatting money within CiviCRM. It should properly handle currencies, decimal places, "1000" separater (ie 1,000.00 and 1.000,00).
Some approaches:
- Money formatting functions: https://github.com/civicrm/civicrm-core/pull/12055
- Allow higher precision decimals to be entered so tax can be calculated correctly: https://github.com/civicrm/civicrm-core/pull/10641
- MoneyPHP?
cc @eileen This is a tracking issue so I can close down PRs.https://lab.civicrm.org/dev/financial/-/issues/13PayPal Express recurring notifications don't work for test transaction2023-11-23T07:32:26Zcarbar1103PayPal Express recurring notifications don't work for test transactionI set up a PayPal Express payment processor and a contribution page to take donations, both recurring and one-off. When taking one-off donations, everything worked as expected. However, for recurring donations, the initial contribution...I set up a PayPal Express payment processor and a contribution page to take donations, both recurring and one-off. When taking one-off donations, everything worked as expected. However, for recurring donations, the initial contribution remained pending and PayPal IPN reported a 500 error.
I managed to track down the issue to the handlePaymentExpress() method in the CRM/Core/Payment/PayPalProIPN.php file.
At around line 578, it does this:
` $result = civicrm_api3('contribution', 'getsingle', array('invoice_id' => $input['invoice']));
`
Unfortunately, this only works for live contributions. I fixed this by changing where it retrieves the recurring contribution from
` $contributionRecur = civicrm_api3('contribution_recur', 'getsingle', array(
'return' => 'contact_id, id',
'invoice_id' => $input['invoice'],
));
`
to
` $contributionRecur = civicrm_api3('contribution_recur', 'getsingle', array(
'return' => 'contact_id, id, is_test, payment_processor_id',
'invoice_id' => $input['invoice'],
));
`
and changed line 578 to
` $result = civicrm_api3('contribution', 'getsingle', array('invoice_id' => $input['invoice'], 'contribution_test' => $contributionRecur['is_test']));
`
However, the contribution still remained pending. The other error was a few lines further down:
` $paymentProcessorID = self::getPayPalPaymentProcessorID();
`
This returned the wrong processor id, so I changed it to do this
` $paymentProcessorID = $contributionRecur['payment_processor_id'];
`
I have no idea if these changes will break anything else, but they seem to work for me
Regards,
Carl