Financial issueshttps://lab.civicrm.org/dev/financial/-/issues2020-08-31T02:50:30Zhttps://lab.civicrm.org/dev/financial/-/issues/118Proposal - move source & received date to near the top on ContributionView form2020-08-31T02:50:30ZeileenProposal - move source & received date to near the top on ContributionView formI realise that any UI changes generally fall apart on discussion / scope creep so I want to keep this proposal very specific & I'll either procede with it or not based on up & down votes - the Proposal is to move the Source & Received da...I realise that any UI changes generally fall apart on discussion / scope creep so I want to keep this proposal very specific & I'll either procede with it or not based on up & down votes - the Proposal is to move the Source & Received date fields to the top on the contribution view screen
**Proposed location**
(note moving the payment summary into where Total Amount sites is is in the screenshot out of scope for this proposal)
![Screen_Shot_2020-02-15_at_2.45.54_PM](/uploads/8d5c9f99236ba679e7c550986dc764c1/Screen_Shot_2020-02-15_at_2.45.54_PM.png)
**Current location**
(note the double Total Amount is a bug which I will look at once https://github.com/civicrm/civicrm-core/pull/16531 is resolved as the technique will be part of the solution if agreed)
![Screen_Shot_2020-02-15_at_2.26.31_PM](/uploads/14d9e729c34efe642d66bffa26568b68/Screen_Shot_2020-02-15_at_2.26.31_PM.png)
Rationale - I think the 'what & when' about a contribution is key at-a-glance information & it should be near the top (possibly above financial type too). The other detail is increasingly weedsy payment information - & I feel further down makes sensehttps://lab.civicrm.org/dev/financial/-/issues/105Proposal: Add in payment_processor-{payment processor type} class attribute t...2020-05-28T06:44:33ZseamusleeProposal: Add in payment_processor-{payment processor type} class attribute to Radio HTMLWhen more than one payment processor is included on a contribution or event form. a set of radio buttons is added to set the payment processor to use. There is an issue in that each radio input uses the same name - payment_processor_id t...When more than one payment processor is included on a contribution or event form. a set of radio buttons is added to set the payment processor to use. There is an issue in that each radio input uses the same name - payment_processor_id the only difference is that the id of each radio button includes the payment processor.id However that doesn't give you any idea what the type is so hypothecitally if you had a PayPal and say Eway Procesors or PayPal and Pay Later option and wanted to theme the PayPal option using a PayPal button there is no obvious way of determining which is Paypal. The proposal would be to add in the payment processor type name in as a class so it was like payment_processor_type-{type name} as a class to the radio so that5.24.0seamusleeseamusleehttps://lab.civicrm.org/dev/financial/-/issues/112Add FormRule to force user to remove "&" from both "Billing First Name" and "...2019-12-19T08:39:04ZKarinGAdd FormRule to force user to remove "&" from both "Billing First Name" and "Billing Last Name" fields**Issue:**
First Name field can be filled out as e.g. "Jon & Mary";
That "&" can cause issues with Payment Processors when it's passed on as part of the Cardholder Name - resulting in rejecting properly entered Credit Card information....**Issue:**
First Name field can be filled out as e.g. "Jon & Mary";
That "&" can cause issues with Payment Processors when it's passed on as part of the Cardholder Name - resulting in rejecting properly entered Credit Card information.
Credit Card Payments with iATS Payments will get a REJ:23 failure code when the Cardholder name contains a "&" - I did some research to see if this is iATS Payments' specific, but I don't think it is.
I found e.g. CartPay -> also has error codes ERROR: 54043: "The Billing Firstname contains invalid characters."
I also found SagePay has such error codes - for every single text field actually:
```
"5037 : The Delivery Address contains invalid characters.","5037 : The Delivery Address contains invalid characters."
"5038 : The Delivery Phone contains invalid characters.","5038 : The Delivery Phone contains invalid characters."
"5039 : The Delivery City contains invalid characters.","5039 : The Delivery City contains invalid characters."
"5040 : The Billing Surname contains invalid characters.","5040 : The Billing Surname contains invalid characters."
"5041 : The Billing Firstname contains invalid characters.","5041 : The Billing Firstname contains invalid characters."
"5042 : The Billing Address1 contains invalid characters.","5042 : The Billing Address1 contains invalid characters."
"5043 : The Billing Address2 contains invalid characters.","5043 : The Billing Address2 contains invalid characters."
"5044 : The Billing City contains invalid characters.","5044 : The Billing City contains invalid characters."
"5045 : The Billing Phone contains invalid characters.","5045 : The Billing Phone contains invalid characters."
"5046 : The Delivery Surname contains invalid characters.","5046 : The Delivery Surname contains invalid characters."
"5047 : The Delivery Firstname contains invalid characters.","5047 : The Delivery Firstname contains invalid characters."
"5048 : The Delivery Address1 contains invalid characters.","5048 : The Delivery Address1 contains invalid characters."
"5049 : The Delivery Address2 contains invalid characters.","5049 : The Delivery Address2 contains invalid characters."
"5050 : The Billing Address contains invalid characters.","5050 : The Billing Address contains invalid characters."
"5051 : The Contact Number contains invalid characters.","5051 : The Contact Number contains invalid characters."
"5052 : The Customer Name contains invalid characters.","5052 : The Customer Name contains invalid characters."
"5053 : The Email Message contains invalid characters.","5053 : The Email Message contains invalid characters."
"5054 : The Cardholder Name contains invalid characters.","5054 : The Cardholder Name contains invalid characters."
"5055 : A Postcode field contains invalid characters.","5055 : A Postcode field contains invalid characters."
"5056 : The Contact Fax contains invalid characters.","5056 : The Contact Fax contains invalid characters."
```
This Image illustrates -> issue (on the left) -> no issue (on the right). Of course the checkbox for My billing address is the same as above is what copies the First Name and Last Name fields down into the Cardholder name bits. The form rule can look for "&" and then tell the user to remove it. Note the user can still leave "Mark & Karin" in the Name and Address Profile. But we would prevent it from going into the Billing details.
![image](/uploads/bd1131f6790be6d085fe3962d4017ffa/image.png)https://lab.civicrm.org/dev/financial/-/issues/186Accounting entries incorrect in a number of cases... especially with pending ...2023-05-01T17:18:33ZJamie Novick - CompucoAccounting entries incorrect in a number of cases... especially with pending refunds and overpaymentsFirstly - sorry for the wall of text. This has ended up being a much longer piece of analysis than expected but I thought I should share it so that we can agree a way ahead.
This all started as we were looking at the best way to impleme...Firstly - sorry for the wall of text. This has ended up being a much longer piece of analysis than expected but I thought I should share it so that we can agree a way ahead.
This all started as we were looking at the best way to implement refunds for a payment processor. Some work was done here to discuss this: https://lab.civicrm.org/dev/financial/-/issues/87 but I can see this stalled somewhat - probably due to some of the issues I'm going to discuss here.
# Background: The problems with the contribution status field
Just for complete disclosure I hate the CiviCRM contribution status field. Hopefully everyone already knows that. I've probably started discussions on getting rid of it at every CiviCON and documented this on every financial gitlab ticket. It is the biggest blocker we have to reaching an accounting implementation that aligns to standard concepts of accounting.
Why is that?
We appear to have 2 use cases for it, both of which are undocumented.
1. For users to quickly change whether the amounts owed are
a) expected to be paid or
b) are paid.
2. To reflect the payment status of the contribution
i.e. whether the total sum of the line items is >, < or = to the net amount paid in or refunded on that contribution (this is important and I’ll come back to it)
This is a bit of a problem as it’s all a bit chicken and egg! If the user changes the status we need to understand whether we should be creating payments or not (or creating refund payments or not), and if the user records payments or refund payments we need to update the status to something meaningful and consistent.
The following is an analysis of the allowed contribution status changes from and to that a user can perform:
**Table 1:**
- Black = Option hidden
- X - Val = Option shown but user cannot change to it as we have a validation message
- Y (black) = Option shown, user can select this and I don’t see issues with accounting that occurs
- N/A = Couldn’t test
- Y (red) = Option shown, user can select this and there are issues with accounting that occurs
![Screenshot_2021-09-15_at_15.33.12](/uploads/8db825597f091f0bf34d590b38b2ed2f/Screenshot_2021-09-15_at_15.33.12.png)
I’d note that it’s a bit confusing to users to see a value in the dropdown they can’t use. I think we should just hide values they cannot select as this would be much clearer for them.
We end up with some very strange and in some cases incorrect behaviour when allowing users to change the status in a "partially paid" and "pending refund" scenarios:
**Table 2:**
![Screenshot_2021-09-15_at_15.47.11](/uploads/827aafd531d7dbe54866b8237758ce42/Screenshot_2021-09-15_at_15.47.11.png)
# Ground Rules
As such I would like to suggest some ground rules to work towards:
1. The only time a user can change the status of a contribution should be when it has no payments or refunds attached to it.
2. Once a payment has been received we manage everything through either the line item editor or the “change selections” on the event form or "record payment” or “record refund”. If any changes to each are made to any of these we recalculate the contribution status based on one set of rules:
The rules to calculate the contribution status should be:
**Table 3:**
![Screenshot_2021-09-15_at_15.38.43](/uploads/b77e518446862474f4e6823e045e11a3/Screenshot_2021-09-15_at_15.38.43.png)
Delving deeper, there are a number of situations within CiviCRM that do not confirm to this currently and instead we end up with a status this is confusing for the user:
(Note this is not be a comprehensive list - just to give some examples).
**Table 4:**
![Screenshot_2021-09-15_at_15.39.45](/uploads/3a9e238f9ec1071de6b056c543c68522/Screenshot_2021-09-15_at_15.39.45.png)
# Specific Scenarios
This all said there are some specific use cases that we need to consider and have appropriate workflows for:
Table 5:![Screenshot_2021-09-15_at_15.40.49](/uploads/a922e2c0f5a52b92adba895c5fd89654/Screenshot_2021-09-15_at_15.40.49.png)
# Actions:
As such I think the actions could be:
1. Agree to the "ground rules" for the contribution status field above so we are all working towards a common goal.
1. I think we should hide values they cannot select as this would be much clearer for them. i.e. all items that are marked as “X-val” in the table above. Perhaps we can refactor the code that show/hides the options to a central place.
1. I think we should change the way the status field is calculated to use the business logic suggested in Table 3 above in all cases. This shouldn’t be something that extensions should take care of but should be calculated any time a contribution haas it’s line items / financial transactions changed. Obviously I don’t know what this means from a code perspective and I assume this would be a significant refactor but I think we could clear up a lot of business logic by doing so.
1. Discuss and agree which of the options from table 5.1 are suitable and then agree the UX for this.
1. So that we can then remove the option to make the status changes as per table 1: 3f, 4e, 4f without degrading users ability to do the things they need.
I actually think if we do these things we can consider CiviCRM’s accounting to be “correct” if not completely intuitive (at least for now).
@mattwire @eileen @KarinG @JoeMurrayhttps://lab.civicrm.org/dev/financial/-/issues/84Making the poor performance associated with the creditnote_id field opt in r...2021-03-31T02:07:56ZeileenMaking the poor performance associated with the creditnote_id field opt in rather than opt outSometime before the joys of Lexim code was introduced to Core to add a creditnote_id to any contribution whose status was changed to Refunded, or Cancelled (later Chargeback was added).
This fitted a specific use case - the numbers pe...Sometime before the joys of Lexim code was introduced to Core to add a creditnote_id to any contribution whose status was changed to Refunded, or Cancelled (later Chargeback was added).
This fitted a specific use case - the numbers permitted a prefix & had to be sequential. However, anecdotally most large sites have hacked it out because the performance is so bad.
During the Barcelona sprint a [patch was merged](https://github.com/civicrm/civicrm-core/pull/15232) making it possible to install [an extension](https://github.com/greenpeace-cee/at.greenpeace.creditnope) to opt out of having a credit note sloooowwwly calculated.
However, in the world of Lexim use-case specific functionality should be OPT IN rather than opt out. Ie it should be the case that you need to install an extension to GET the slow behaviour not to NOT get it.
This is also a good test case for the general practice of moving functionality out of core into an extension. Here are the steps I believe are required
1) Determine where the code interacts with core. I did this & determined that all the places where createCreditNoteID is called from other than Contribution.create are not hit & I added a [pr to deprecate them](https://github.com/civicrm/civicrm-core/pull/15492) & fix the one place where it is hit. As a result of this the only interaction required would be in the pre_hook so we don't need to add a hook to generate this field (per https://lab.civicrm.org/dev/core/issues/1308) - this is a good thing as the assumption that credit notes & contributions would not be many to one is flawed & we don't want to bake this into core - we want to get it out of core
2) Create an extension that can be installed to add the credit note id in the pre hook.
3) Get the extension reviewed & approved for automatic installation
4) Add this new extension so it is installed on upgrade for existing sites - this step will require some input from @totten on how to do it & not knowing how is a blocker but probably getting the extension ready is a necessary pre-step & is probably only a couple of hours of work
Also we should consider this proposed performance improvement https://github.com/civicrm/civicrm-core/pull/15235https://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/27Paypal recurring IPNs don't work under some circumstances2018-07-24T05:11:09Zmattwiremjw@mjwconsult.co.ukPaypal recurring IPNs don't work under some circumstancesCurrently you can setup recurring payments using the Paypal Standard processor, but after the first IPN is processed subsequent IPNs do not get processed because the IPN code does not fully implement code to do so.
By replacing the call...Currently you can setup recurring payments using the Paypal Standard processor, but after the first IPN is processed subsequent IPNs do not get processed because the IPN code does not fully implement code to do so.
By replacing the call to completetransaction with one to repeattransaction we have working recurring IPNs for paypal standard.5.5.0https://lab.civicrm.org/dev/financial/-/issues/203False-positive duplicate detection caused by webform not passing correct par...2024-01-16T19:36:50ZAllenShawFalse-positive duplicate detection caused by webform not passing correct parameters to Authorize.net - it needs to pass contributionID(Joinery internal reference: "Trello#142: Membership Application and Payment Process Not Working")
From what I understand so far, it seems there's a well-thought effort to use propertybag to standardize parameter names in payment proces...(Joinery internal reference: "Trello#142: Membership Application and Payment Process Not Working")
From what I understand so far, it seems there's a well-thought effort to use propertybag to standardize parameter names in payment processors. Here's one area where this effort seems incomplete and easily improved:
There are a few places in `CRM_Core_Payment_AuthorizeNet::doPayment()` where directly accessing `$params` could (and does) cause problems; it seems right to switch these to `$propertybag`. (BTW I think that usage of `propertybag` in the context of alterPaymentProcessorParams hook is still not appropriate, so I'm not suggesting changes to that usage within this method.)
**Specific observable problem:**
(I can create a more detailed and stripped-down recipe if needed, but hoping to avoid the effort.)
- On a site with: D7, civicrm 5.49.5, webform_civicrm.module, and contributiontransactlegacy extension
- We have a webform which accepts membership signups, payable through the core Authorize.net payment processor.
- Payments made through this webform are actually transacted in Authorize.net, but the user is given the error, 'It appears that this transaction is a duplicate. Have you already submitted the form once? If so there may have been a connection problem. Check your email for a receipt from Authorize.net. If you do not receive a receipt within 2 hours you can try your transaction again. If you continue to have problems please contact the site administrator.'
- FWIW I have observed that the below corrective measure fixes this problem for this site.
**Why this error happens:**
- `CRM_Core_Payment_AuthorizeNet::doPayment()` calls `$this->checkDupe($authorizeNetFields['x_invoice_num'], $params['contributionID'] ?? NULL)` (see [line 171](https://github.com/civicrm/civicrm-core/blob/a1278f71bd804c8013600793916a692b4345e4a2/CRM/Core/Payment/AuthorizeNet.php#L171)) to detect a duplicate transaction.
- However, `$params['contributionID']` is undefined. (On the other hand, `$params['contribution_id']` is defined, as is `$propertyBag->getContributionID( )`).
- Since `checkDup()` gets a NULL value for `$contributionId`, it always thinks the contribution is a duplicate, so we get the above error message.
**Corrective measueres**
1. Seems like the intent of `propertybag` is to clear up exctly this kind of naming inconsistency. I suggest changing Line 171 to use `$propertyBag->getContributionID( )` instaed of `$params['contributionID']`.
2. [Line 146](https://github.com/civicrm/civicrm-core/blob/a1278f71bd804c8013600793916a692b4345e4a2/CRM/Core/Payment/AuthorizeNet.php#L146), which tries to read `$params['is_recur']` and `$params['contributionRecurID']`, is probably also a good candidate for similar cleanup?
Should I go head with a PR or is more discussion needed?https://lab.civicrm.org/dev/financial/-/issues/196Proposal: Account for new Mastercard regulations for recurring contributions2022-09-20T17:19:38ZJonGoldProposal: Account for new Mastercard regulations for recurring contributionsThere's an article here:
https://www.allaboutadvertisinglaw.com/2021/11/new-mastercard-requirements-for-subscription-and-negative-option-billing-models.html
But here are the highlights:
* Must send a confirmation email at the time of en...There's an article here:
https://www.allaboutadvertisinglaw.com/2021/11/new-mastercard-requirements-for-subscription-and-negative-option-billing-models.html
But here are the highlights:
* Must send a confirmation email at the time of enrollment that includes the terms of the subscription and instructions on how to cancel the subscription
* Send a receipt after every successful billing attempt that includes instructions for how to cancel this subscription (this can be instructions to call customer service)
* Provide an online cancellation method (similar to unsubscribing from emails) – that can be instructions to call customer service
* For any subscription/recurring payment plan that bills a cardholder less frequently than every six months, the merchant must send a notification at least seven days prior to the billing date that includes the terms of the subscription and instructions on how to cancel the subscription
* Merchants have until Sept 21, 2022, to meet this requirement.
It seems like `civicrm_contribution_recur.is_email_receipt` should be ignored if the card type is Mastercard. It also seems like a new Scheduled Job is necessary for folks who have recurring contributions that are less frequent than six months.https://lab.civicrm.org/dev/financial/-/issues/181Update billing details fails when no State/Province entered2022-09-16T21:08:32ZlarsssandergreenUpdate billing details fails when no State/Province enteredUpdate billing details gives "Page could not be loaded" on submit if the user has not entered a State/Province. In some cases, it is valid for a user to not enter a State/Province if they live in a country that does not have states. This...Update billing details gives "Page could not be loaded" on submit if the user has not entered a State/Province. In some cases, it is valid for a user to not enter a State/Province if they live in a country that does not have states. This works as expected on contribution pages, etc, but not on the update billing details page. Tested on 5.35.2.
I will have a look at how this is handled for contribution pages and port the solution to update billing details, at some point.https://lab.civicrm.org/dev/financial/-/issues/163Fully remove contributionTypeID2020-12-23T11:07:08ZeileenFully remove contributionTypeIDThere are few remaining references in the code to very-old-legacy contributionTypeID
This seems to be passed out to payment processors and assigned to the templates in some cases
I feel like we could remove these in 5.34 and simply com...There are few remaining references in the code to very-old-legacy contributionTypeID
This seems to be passed out to payment processors and assigned to the templates in some cases
I feel like we could remove these in 5.34 and simply communicate the fact via the dev-digest and release notes.5.34.0https://lab.civicrm.org/dev/financial/-/issues/162Simplify decision as to whether to use a pdf on emails2023-09-05T04:20:10ZeileenSimplify decision as to whether to use a pdf on emailsCurrently the code that determines whether to attach a pdf for membership emails only attaches it as a pdf if the tax amount is non-zero
This seems both confusing and pointless - the proposal here is to send as a pdf as long as
1) is_...Currently the code that determines whether to attach a pdf for membership emails only attaches it as a pdf if the tax amount is non-zero
This seems both confusing and pointless - the proposal here is to send as a pdf as long as
1) is_email_pdf is true and
2) invoicing is enabled
I feel like 1 and 2 could be separated but they are currently linked so I would suggest any proposals to change that are a follow uphttps://lab.civicrm.org/dev/financial/-/issues/157Proposal - if payment_processor_type does not define url_site_default then do...2020-12-04T08:47:08ZeileenProposal - if payment_processor_type does not define url_site_default then do not present url_site on Processor formWhen you go to create a new processor there is a field for the site_url (& some other urls) which I generally don't think it's good to have users fill in and would rather suppress. I think it should be suppressed based on payment process...When you go to create a new processor there is a field for the site_url (& some other urls) which I generally don't think it's good to have users fill in and would rather suppress. I think it should be suppressed based on payment processor & while I could make a case for using a supportsUserDefinedUrl method I think we could get away with either
1) don't display the field if payment_processor.site_url_default is empty or
2) don't display the field is payment_processor.site_url_default is 'null' or some other magic value
We aren't currently doing any 'supports' checks on the form & it feels like this is probably something used primarily by older processors so I lean towards 1 being enough
@mattwire @KarinG @adixon @artfulrobot @andrewhunt thoughtshttps://lab.civicrm.org/dev/financial/-/issues/154Sales Tax not added to total when memberships include donations that are sepa...2024-02-27T01:17:44ZeileenSales Tax not added to total when memberships include donations that are separate transactionshttps://civicrm.stackexchange.com/questions/37923/sales-tax-not-added-to-total-when-memberships-include-donations-that-are-separathttps://civicrm.stackexchange.com/questions/37923/sales-tax-not-added-to-total-when-memberships-include-donations-that-are-separathttps://lab.civicrm.org/dev/financial/-/issues/144Figure out if core processors actually work.....2022-05-19T22:31:00ZeileenFigure out if core processors actually work.....The processors we currently ship with core are
| Processor | status|
| ------ | ------ |
| Authorize.net | works/tested |
| Elavon| broken? |
| Eway| works/tested/ converted to an extension |
| FirstData| broken? (Reported as working by...The processors we currently ship with core are
| Processor | status|
| ------ | ------ |
| Authorize.net | works/tested |
| Elavon| broken? |
| Eway| works/tested/ converted to an extension |
| FirstData| broken? (Reported as working by Brian Civi Version not mentioned) |
| PayflowPro| broken? (Reported as working as of 5.19 by Nicholas) (As of 5.38 Migrated to a core extension with unit tests) |
| PaymentExpress| definitely broken / removed|
| PayJunction| broken? |
| Paypal| works/tested |
| Realex| likely works, have seen gitlabs |
I think we should try to find out about the ones that might be broken with a view to either
1) bring them under CI & move to an extension (per Eway) OR
2) remove them from core
Other than pinging people like @lcdweb to see if they use any my other idea is to add a check or preUpgrade message to try to get people to let us know.
@seamusleehttps://lab.civicrm.org/dev/financial/-/issues/141Define return parameters for doPayment2023-03-11T00:09:20Zmattwiremjw@mjwconsult.co.ukDefine return parameters for doPaymentSee #135, https://github.com/civicrm/civicrm-core/pull/18150 and https://github.com/civicrm/civicrm-core/pull/18178
We need to clearly define what the return parameters for `doPayment()` should be as it's important, it's unclear and it'...See #135, https://github.com/civicrm/civicrm-core/pull/18150 and https://github.com/civicrm/civicrm-core/pull/18178
We need to clearly define what the return parameters for `doPayment()` should be as it's important, it's unclear and it's not defined anywhere.
My proposal:
* `doPayment($params)` returns an array.
* It must contain:
* **`payment_status_id`**: **(deprecated)** Numeric value of `Contribution Status` option value Completed or Pending. Eg. 1. Must be set but make sure you set `payment_status` as well because this value will be ignored in the future.
* **`payment_status`**: Text field - Either `Completed` or `Pending`.
* It may contain (and the code that calls `doPayment()` will update these values on the contribution/payment:
* **`trxn_id`**: The transaction ID from the payment processor. This will be recorded in the `Contribution.trxn_id` field and the `Payment.trxn_id` field. We do not return `order_reference` here because that is usually filled in by an IPN callback from the payment processor if required.
* **`fee_amount`**: The amount (in same currency as contribution) of the fee taken by the payment processor for processing the payment.
Historically `$params` was passed by reference. This is deprecated and only the return values should be used.
Ping @eileen @artfulrobot @KarinG5.49.0https://lab.civicrm.org/dev/financial/-/issues/134Contribution confirmation page should not display the name of payment processor2020-09-17T22:57:49Zagileware_pengyiContribution confirmation page should not display the name of payment processor![wording](/uploads/7cf554e3f2ff597d6b001de83e4d299a/wording.png)
The text can simply be: **Click the Continue button to complete the contribution**
[See this line](https://lab.civicrm.org/dev/core/-/blob/master/CRM/Core/Payment.php#L6...![wording](/uploads/7cf554e3f2ff597d6b001de83e4d299a/wording.png)
The text can simply be: **Click the Continue button to complete the contribution**
[See this line](https://lab.civicrm.org/dev/core/-/blob/master/CRM/Core/Payment.php#L602) for where it comes from.
Agileware ref: CIVICRM-1496https://lab.civicrm.org/dev/financial/-/issues/130Standardise payment processing2021-05-17T20:44:55ZeileenStandardise payment processingThis is a meta issue for getting more standardisation and clearer best practices in place for payment processing.
Many of our preferred practices are not new but are not clearly & consistently documented and processors that people copy ...This is a meta issue for getting more standardisation and clearer best practices in place for payment processing.
Many of our preferred practices are not new but are not clearly & consistently documented and processors that people copy are not modelling them well.
The key goals at this point are to
1) [model best practices in our core processors](https://lab.civicrm.org/dev/financial/-/issues/132)
2) ensure our docs are up-to-date on best practice
3) build a list of urls of payment processors & create tickets against them to implement the best practices
4) get payment processor writers to subscribe to this meta-issue for updates.
5) start the process of moving the unused core processors to extensions & then entirely out of core.
- done for eway, PayflowPro
6) start to add deprecation notices to functions we do not recommend. Note that these should only show on dev environments as we recommend live sites set appropriate php error level settings. We should make a decent start on 1-4 above in the next 1-2 months and then get more serious about this one
**Best practices to implement in core & promote**
1) All processors should implement doPayment and not doDirectPayment, doTransfer. In order to make this change they need to do 3 things
a) rename the existing function
b) set ```$result['payment_status_id']```
e.g ```$result['payment_status_id'] = CRM_Core_PseudoConstant::getKey('CRM_Contribute_BAO_Contribution', 'contribution_status_id', 'Completed');```
c) handle $params['amount'] == 0 (generally return at that point, setting payment_status_id)
d) throw exceptions on failure - do NOT return CRM_Core_Error
2) Handle the settings bag
Processors should make their code able to handle the settings bag. The settings bag works like an array except that
1) - some array functions don't work - eg array_merge()
2) - it standardises input.
In order to prepare processors should
1) Add the line ``` $propertyBag = PropertyBag::cast($params);``` as the first line it doPayment to ensure that they are consistently working with a propertyBag object
2) replace array functions with functions that work on the property bag - eg replace empty() checks with $params->has('recurProcessorID')
Note that we will add to this as we convert core processors & identify the difficulties.
3) Not extend BaseIPN & work to eliminate that class. currently we recommend processors implement ```handlePaymentNotification()``` rather than have an IPN class per se but the core processors don't do that. We should model 'good behaviour' in our core processors & document. Currently our core processors are a bit nasty - subtasks on this are
- Getting a clear api/ expectations for cancel & failed payments out of BaseIPN
3) Use guzzle not CURL & use GuzzleTestTrait to add tests. Note that we should focus on moving weird ones like FirstData outside of core but it's proven very easy to switch A.net over & we want to model this https://lab.civicrm.org/dev/financial/-/issues/143https://lab.civicrm.org/dev/financial/-/issues/129"billing address is the same as above" doesn't show/hide billing address fields2023-11-23T07:37:19ZJonGold"billing address is the same as above" doesn't show/hide billing address fieldsTo replicate on the demo server:
* Add a profile to a contribution page that has all the required fields to expose the "billing address is the same as above" checkbox ("Name and Address" works).
* Load the page.
* Click the checkbox.
Ex...To replicate on the demo server:
* Add a profile to a contribution page that has all the required fields to expose the "billing address is the same as above" checkbox ("Name and Address" works).
* Load the page.
* Click the checkbox.
Expected behavior:
* Checking/unchecking the box should show/hide the billing fields.
Actual behavior:
* No change.
It's not a JS error because JS is still firing.https://lab.civicrm.org/dev/financial/-/issues/128To be Autorenew or not to be - that's the question2023-11-23T07:19:54ZKarinGTo be Autorenew or not to be - that's the question**Purpose of this Lab issue is to **
1. document the various places/switches in Core with references to Membership Autorenew
2. review them and try reach consensus on how these switches should work under various conditions, like e.g.
*...**Purpose of this Lab issue is to **
1. document the various places/switches in Core with references to Membership Autorenew
2. review them and try reach consensus on how these switches should work under various conditions, like e.g.
* [ ] a) what should happen if a contribution in the recurring contribution series linked to the Membership failed?
* [ ] b) what should happen if there is a conflict -> Membership not configured to renew Automatically, but there are line items with references to that Membership?
* [ ] c) etc.
3. propose tangible small iterative steps forwards
@seamuslee @mattwire @justinfreeman @eileen
I'm going to start with 1!