Financial issueshttps://lab.civicrm.org/dev/financial/-/issues2021-07-07T08:47:08Zhttps://lab.civicrm.org/dev/financial/-/issues/150civicrm/payment/form url got empty currency argument in backoffice live CC form2021-07-07T08:47:08ZMonish Debcivicrm/payment/form url got empty currency argument in backoffice live CC formThis affects iATS Payments ACH/EFT payment processor which renders the payment block based on currency chosen. Here are the steps to replicate:
1. Install and enable [iATS paymentextension](https://github.com/iATSPayments/com.iatspayme...This affects iATS Payments ACH/EFT payment processor which renders the payment block based on currency chosen. Here are the steps to replicate:
1. Install and enable [iATS paymentextension](https://github.com/iATSPayments/com.iatspayments.civicrm)
2. Add and configure an iATS Payments ACH/EFT payment type payment processor.
3. Enable USD and CAD currencies
4. Go to 'Submit Credit Card Contribution' backoffice form
5. Choose payment processor created at step 2
Issue:
1. Payment block renders payment block with check template
2. Switching currency doesn't update the payment block.
For more detail discussion on MM - https://chat.civicrm.org/civicrm/pl/ixxrxhxs43r4mfyjpnf6tnwnnc
ping @KarinG @eileen @JoeMurray @seamuslee5.31.0Monish DebMonish Debhttps://lab.civicrm.org/dev/financial/-/issues/82Develop getter & setter structure for Payment classes2021-05-31T22:31:04ZeileenDevelop getter & setter structure for Payment classesI don't think anyone designing Payment Processing subsystem would include the spec that you pass an undefined set of parameters to the 'doPayment' method, but that is how ours grew up.
This has caused us issues with inconsistencies arou...I don't think anyone designing Payment Processing subsystem would include the spec that you pass an undefined set of parameters to the 'doPayment' method, but that is how ours grew up.
This has caused us issues with inconsistencies around how payment processors determine variables. It also makes it really hard to clean up the code that interacts with payment processors as the code spends a lot of time buying arrays which go off into the void.
I'm pretty sure that if we were designing from scratch we would make it look much more like
```
$paymentObject = $this->getPaymentObject();
$paymentObject
->setContributionID(5)
->setContactID->(6)
->setAmount(50)
->setInvoiceID('xyz')
->setRecurringFrequency(1)
->setRecurringUnit('week')
....
->doPayment();
$feeAmount = $paymentObject->getFeeAmount();
```
We might provide some helpers etc but that seems much more inline with modern coding conventions and with our desire for standardisation.
I believe we should start adding getters & setters & encouraging payment processors to use them. The getters would do any normalisation of parameters (I'm looking at you currency vs currencyID).
It would be quite some time before this usage has 'flowed through the system' & we switch to relying on it when making payments but I think that adding this structure sets us up well for the future.
See PR for proposed change - which will not ACTUALLY change anything other than make these methods available in the first instance
https://github.com/civicrm/civicrm-core/pull/15509
@artfulrobot @KarinG @adixon @mattwire @andrewhunt
(Payment\PropertyBag)