Financial issueshttps://lab.civicrm.org/dev/financial/-/issues2024-03-07T16:39:04Zhttps://lab.civicrm.org/dev/financial/-/issues/167Document Support for CiviCRM from payment processors2024-03-07T16:39:04ZJoeMurrayDocument Support for CiviCRM from payment processorsDocument appropriately the support that CiviCRM receives from a variety of payment processors.
- [ ] Payment processing feature page that cites the sponsoring payment processors
- [ ] Individual payment processor pages similar to partn...Document appropriately the support that CiviCRM receives from a variety of payment processors.
- [ ] Payment processing feature page that cites the sponsoring payment processors
- [ ] Individual payment processor pages similar to partner detail pages
- [ ] Update the extension readme.md on extensions in gitlab
- [ ] Update extension pages on c.o (for as long as these will exist)
Josh has started on first two tasks as of Feb 22, 2021.
----
Original description
Document appropriately (after determining what that means ;) ) the support that CiviCRM receives from a variety of payment processors.
This might mean putting something into the info.xml or README.md of each extension, as well as adding something somewhere on c.o.
See https://github.com/agileware/cf-stripe/issues/1
@mattwire any sense of Stripe's compensation arrangements being different in Australia compared to other countries? I like the policy thrust of @justinfreeman 's comment but don't believe it is industry practice.joshjosh@civicrm.orgjoshjosh@civicrm.orghttps://lab.civicrm.org/dev/financial/-/issues/166Account IIF Export Amount Format improper2021-03-01T02:27:36ZLoganBearAccount IIF Export Amount Format improperBatches created before 5.34 export simple value amounts:
```
12.00
-12.00
```
Batches after the upgrade to 5.34 adds a dollar sign to the amount:
```
$12.00
-$12.00
```
I can't get these files imported without loading them into Excel...Batches created before 5.34 export simple value amounts:
```
12.00
-12.00
```
Batches after the upgrade to 5.34 adds a dollar sign to the amount:
```
$12.00
-$12.00
```
I can't get these files imported without loading them into Excel and changing the formatting.5.35.0https://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/160Allocation of "fee amount" is incorrect if fee is added after contribution is...2020-12-11T17:11:37ZJonGoldAllocation of "fee amount" is incorrect if fee is added after contribution is created#### Steps to replicate:
* Go to **Administer » CiviContribute » Payment Methods**. Note the default payment method.
* Also note a payment method that doesn't have the same financial account.
On a clean install, "Check" is the default ...#### Steps to replicate:
* Go to **Administer » CiviContribute » Payment Methods**. Note the default payment method.
* Also note a payment method that doesn't have the same financial account.
On a clean install, "Check" is the default method, and "Credit Card" has a different financial account. I'll use those in my example below.
* Create a contribution with payment method of credit card. Enter a fee amount, save, and note the contribution ID.
* Run the following SQL to view the financial account IDs of the transaction (my contribution ID is 96 below):
```sql
mysql> SELECT entity_id, amount, from_financial_account_id, to_financial_account_id, total_amount, fee_amount FROM civicrm_entity_financial_trxn ceft JOIN civicrm_financial_trxn cft ON ceft.financial_trxn_id = cft.id WHERE entity_table = 'civicrm_contribution' AND entity_id = 96;
+-----------+--------+---------------------------+-------------------------+--------------+------------+
| entity_id | amount | from_financial_account_id | to_financial_account_id | total_amount | fee_amount |
+-----------+--------+---------------------------+-------------------------+--------------+------------+
| 96 | 18.00 | NULL | 12 | 18.00 | 4.00 |
| 96 | 4.00 | 12 | 5 | 4.00 | 0.00 |
+-----------+--------+---------------------------+-------------------------+--------------+------------+
```
* The above is correct - the `from_financial_account_id` of the fee trxn matches the `to_financial_account_id` of the main trxn.
* Create a second contribution with payment method of credit card, but do *not* enter the fee.
* Save the contribution, then immediately edit it to add the fee.
* When you run the SQL above, it will look like this:
```sql
mysql> SELECT entity_id, amount, from_financial_account_id, to_financial_account_id, total_amount, fee_amount FROM civicrm_entity_financial_trxn ceft JOIN civicrm_financial_trxn cft ON ceft.financial_trxn_id = cft.id WHERE entity_table = 'civicrm_contribution' AND entity_id = 95;
+-----------+--------+---------------------------+-------------------------+--------------+------------+
| entity_id | amount | from_financial_account_id | to_financial_account_id | total_amount | fee_amount |
+-----------+--------+---------------------------+-------------------------+--------------+------------+
| 95 | 11.00 | NULL | 12 | 11.00 | 0.00 |
| 95 | 3.00 | 6 | 5 | 3.00 | 0.00 |
+-----------+--------+---------------------------+-------------------------+--------------+------------+
```
Note that the fee's `from_financial_account_id` no longer matches the account of the main transaction - it matches the financial account ID of the **default** payment method, not the payment method of this contribution.
**tl;dr:** The financial transaction for a fee amount is calculated incorrectly if you edit the fee after the contribution is saved.
I haven't written a patch/test yet, but I intend to in the next day or two.5.34.0JonGoldJonGoldhttps://lab.civicrm.org/dev/financial/-/issues/159Line items are added from default price set on recurring contributions for fi...2022-12-14T00:35:14ZFrancis (Agileware)Line items are added from default price set on recurring contributions for financial types with tax accounts.# Steps to reproduce, verified on dmaster.demo.civicrm.org
1. Create a Membership type with required autorenewal
2. Enable Tax & Invoicing
3. Create a Sales Tax account, at any rate, and assign it to the "Member Dues" Financial type.
4....# Steps to reproduce, verified on dmaster.demo.civicrm.org
1. Create a Membership type with required autorenewal
2. Enable Tax & Invoicing
3. Create a Sales Tax account, at any rate, and assign it to the "Member Dues" Financial type.
4. Configure a Contribution Page to sign up for the membership, using the "Member Dues" Financial type.
5. Sign up for a membership using the Contribution page.
6. Using the created recurring contribution id, call the Contribution.repeattransaction API to simulate the membership autorenewal like a payment processor supporting recurring contributions
7. Inspect the resulting contribution records using the Order.get API
# Expected Results
Two orders that are identical apart from dates and IDs
# Actual Results
The second order has two line items. The second line item will be for the price field in the default price set (field 1 / set 1 unless you've somehow changed it), and will be for the same amount as the total of the contribution.
On additional attempts to repeat the transaction, the system crashes due to a DB constraint violation and *rolls back the database transaction, losing the records of any contributions processed so far.*
# Why does this happen?
When `CRM_Contribute_BAO_Contribution::add` calls `CRM_Contribute_BAO_Contribution::checkTaxAmount`, this method checks if the financial type has tax applied and calls `CRM_Price_BAO_LineItem::getLineItemArray` if so, regardless of whether there are any line items already.
# Proposed Solution
Move the calls to `CRM_Price_BAO_LineItem::getLineItemArray` out of `CRM_Contribute_BAO_Contribution::checkTaxAmount` and into `CRM_Contribute_BAO_Contribution::add`, and **only** call it if there's no line_item array present already. See discussion at https://chat.civicrm.org/civicrm/pl/9iuqyx9fp3dexnupuxfefsj4ke
Agileware Ref: CIVICRM-16175.34.0https://lab.civicrm.org/dev/financial/-/issues/158Wording change - change UI parts of contribution soft schema to soft credit2020-12-12T00:21:24ZeileenWording change - change UI parts of contribution soft schema to soft creditThrough out the ContributionSoft.xml fields are referred to as 'Contribution Soft x' but in the UI we normally use 'Soft Credit'
When exposing these fields through Search Kit/ Afform / Metadata based functions I believe 'Soft Credit' is...Through out the ContributionSoft.xml fields are referred to as 'Contribution Soft x' but in the UI we normally use 'Soft Credit'
When exposing these fields through Search Kit/ Afform / Metadata based functions I believe 'Soft Credit' is more meaningful5.34.0https://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/156Refund status not set correctly when cancelled_payment_id is set2020-11-09T14:28:28ZJonGoldRefund status not set correctly when cancelled_payment_id is setThis is the same as https://lab.civicrm.org/extensions/stripe/-/issues/260, but the issue lies in core.
### Steps to Replicate
* Create a contribution.
* Refund the entire contribution via `Payment.create`. Set the `cancelled_payment_i...This is the same as https://lab.civicrm.org/extensions/stripe/-/issues/260, but the issue lies in core.
### Steps to Replicate
* Create a contribution.
* Refund the entire contribution via `Payment.create`. Set the `cancelled_payment_id`.
### Expected Result
The contribution's status should be "Refunded".
### Actual Result
The contribution's status remains "Completed".
PR [16148](https://github.com/civicrm/civicrm-core/pull/16148)'s purpose is to set a contribution's status to "Refunded" when the refund's total equals the contribution's total (in `CRM_Financial_BAO_Payment::create()`.
However, this function [returns early](https://github.com/civicrm/civicrm-core/blob/0b44c58f8d6abea7e0be266d89e0100a0e871f60/CRM/Financial/BAO/Payment.php#L99-L102) if the `cancelled_payment_id` is set. Stripe 6.5 [sets that value](https://lab.civicrm.org/extensions/stripe/-/blob/master/CRM/Core/Payment/StripeIPN.php#L318) (as it should). So that code never runs.
Moreover, the test on PR 16148 doesn't set this value, so the bug isn't caught.5.32.0JonGoldJonGoldhttps://lab.civicrm.org/dev/financial/-/issues/155Incorrect deductible shown in contribution summary report2020-11-09T13:37:51ZMonish DebIncorrect deductible shown in contribution summary reportSteps to replicate:
1. Ensure that there are multiple contributions with non-zero non-deductible amount.
2. Go to Contribution Summary Report
3. Select Non-Deductible amount column + Grouping on Receive Date - Month
Result: Total non-d...Steps to replicate:
1. Ensure that there are multiple contributions with non-zero non-deductible amount.
2. Go to Contribution Summary Report
3. Select Non-Deductible amount column + Grouping on Receive Date - Month
Result: Total non-deductible amount is incorrect against each month
On closer look, group function (- SUM) is not applied on non-deductible amount, thus the report column show random amount.
Here's a screencast that explains the issue, where I added two contributions this month w/o non-deductible amount respectively, but the Contribution summary report shows incorrect value:
![yhv](/uploads/e851d5c3b56e46c1de049d12d1f977ff/yhv.gif)
ping @JoeMurray @eileen @mattwire @EdselopezMonish DebMonish Debhttps://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/153Orange Paypal Pro button not redirecting properly after reCaptcha on Paypal2020-12-09T00:33:53ZStoobOrange Paypal Pro button not redirecting properly after reCaptcha on Paypal#151 related issue @eileen @seamuslee
The javascript errors are fixed but we have been able to reproduce other errors related to the reCaptcha system at Paypal.com. I am not sure if these can be fixed on CiviCRM's side or not but we sh...#151 related issue @eileen @seamuslee
The javascript errors are fixed but we have been able to reproduce other errors related to the reCaptcha system at Paypal.com. I am not sure if these can be fixed on CiviCRM's side or not but we should be aware of the following experience from user testing.
My guess is the from the Civi side we should confirm we are sending Paypal the proper auto-return URL to ensure that Paypal can find its way back to us after hitting us with the reCaptcha on their end.
In *Chrome and Safari* the Javascript errors are fixed -- when you click the Paypal button, there's no validation error requiring the user to input CC fields.
**But** when I go to Paypal, I'm asked to complete a ReCaptcha at this URL: https://www.paypal.com//cgi-bin/webscr?cmd=_express-checkout&token=EC-2JE64037K02097038. Once I complete the challenge, the page does not reload to the log-in screen. Instead it just sits with the challenge results accepted. If I then reload the page, it redirects me to the Paypal log-in page as it should at this URL: https://www.paypal.com//cgi-bin/webscr?cmd=_express-checkout&token=EC-2JE64037K02097038
In *Firefox*, the Javascript errors are fixed -- when I click the Paypal button, there's no validation error requiring the user to input CC fields. When you go to Paypal, I'm asked to complete a ReCaptcha. Once I complete the challenge, the Paypal experience is different page loads the sad dinosaur error screen "hmm we're having trouble finding that site"https://lab.civicrm.org/dev/financial/-/issues/148Deprecate BaseIPN functions validateData & LoadObject2021-01-22T20:28:33ZeileenDeprecate BaseIPN functions validateData & LoadObjectWe've just done a round of clean up around interacting with completeOrder and I'm putting this here as what I think would be a good starting point next time.
The function in the BaseIPN class validateData does a bit more than that - it...We've just done a round of clean up around interacting with completeOrder and I'm putting this here as what I think would be a good starting point next time.
The function in the BaseIPN class validateData does a bit more than that - it
1) loads a couple of things - one of which is needed - contribution
2) it checks a couple of things
3) it calls loadObjects which in turn does very little over & above calling
```
$contribution->loadRelatedObjects($input, $ids)
```
Most of the things thus-loaded are unused - except in some specific ways within the processor classes & the stuff around $ids['paymentProcessor'] = $paymentProcessorID; could go if we just passed that as an input to the other functions.
In the past sometimes we have duplicated functions in order to unravel them. On a number of occasions this has worked out well. On others I think we are still paying the price. In particular I think it works when you duplicate code & then keep actively cleaning it up. The mess in the batch update task feels like a case where the code was probably duplicated but then left for a looooonnnnggg time.
In this case I think we can duplicate the contents back with a 'light clean' - since we've already gotten it down to fairly minimal code chunk.5.35.0https://lab.civicrm.org/dev/financial/-/issues/146alterPaymentProcessorParams hook and propertyBag2020-09-15T15:35:00Zmattwiremjw@mjwconsult.co.ukalterPaymentProcessorParams hook and propertyBagSee https://github.com/civicrm/civicrm-core/pull/17507#issuecomment-690213686:
> 1. pass property bag to alterPaymentProcessorParams
>
> - ✔ the hook gets to deal with sensible, known data and does not have to (re-)implement all t...See https://github.com/civicrm/civicrm-core/pull/17507#issuecomment-690213686:
> 1. pass property bag to alterPaymentProcessorParams
>
> - ✔ the hook gets to deal with sensible, known data and does not have to (re-)implement all the quirks of checking different array keys for one thing.
> - ✔ any setting the hook does in a prop bag ensures forward consistency for the next process in the chain (another hook or the main process)
> - ✖ It's possible that the reason for a hook is something pretty darn weird needs doing; in which case the raw array may be more useful.
>
> 2. pass the original array to the hook
>
> - ✖ hook has to do all work arounds
> - ✖ hook is free to implement bad practise in altering the array
> - ✔ hook can do whatever it likes.
>
> I think (1).
And example from Stripe where we're currently passing an array for compatibility (but this should not be used as a model as Stripe ignores the return values from the hook anyway).
https://lab.civicrm.org/extensions/stripe/-/blob/master/CRM/Core/Payment/Stripe.php#L484-489
// @fixme DO NOT SET ANYTHING ON $propertyBag or $params BELOW THIS LINE (we are reading from both)
$params = $this->getPropertyBagAsArray($propertyBag);
// We don't actually use this hook with Stripe, but useful to trigger so listeners can see raw params
$newParams = [];
CRM_Utils_Hook::alterPaymentProcessorParams($this, $params, $newParams);https://lab.civicrm.org/dev/financial/-/issues/145Adding "standard" params to propertyBag2020-09-16T00:42:12Zmattwiremjw@mjwconsult.co.ukAdding "standard" params to propertyBagThis came out of https://github.com/civicrm/civicrm-core/pull/18425 and https://github.com/civicrm/civicrm-core/pull/17595.
Specifically, adding "standard" parameters to propertyBag when they are already in use by a payment processor th...This came out of https://github.com/civicrm/civicrm-core/pull/18425 and https://github.com/civicrm/civicrm-core/pull/17595.
Specifically, adding "standard" parameters to propertyBag when they are already in use by a payment processor that has been converted to use propertyBag is likely to break existing implementations.
Accessing params that are later added as "standard" params to propertyBag when a payment processor is already converted internally to propertyBag (eg. most of the ones written by me Stripe, authnetecheck, Smartdebit).
Example Issues:
- authnetecheck accesses `$params['credit_card_number']` which disappears once mapped to a propertyBag because only the standardised `cardNumber` field is available.
- If authnetecheck was using `$propertyBag->getCustomProperty('credit_card_number')` it would throw an "InvalidArgumentException" because you are not allowed to use `getCustomProperty` for a "standard" property.
Similar issues will apply to any other properties that are already in use by a payment processor.
@eileen @artfulrobot @seamuslee @tottenhttps://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/143Convert core processors to use Guzzle and bring them under CI2020-09-05T01:27:07ZeileenConvert core processors to use Guzzle and bring them under CISubtask of https://lab.civicrm.org/dev/financial/-/issues/132Subtask of https://lab.civicrm.org/dev/financial/-/issues/132https://lab.civicrm.org/dev/financial/-/issues/142Order api proposal - require less line item parameters2020-12-03T10:37:27ZeileenOrder api proposal - require less line item parametersI'd like to propose that we add sensible defaults for line items when using the order api
1) price_field_id - if NONE of the rows have a price_field_id then use the default pricefield id for all of them (I don't want to open up technica...I'd like to propose that we add sensible defaults for line items when using the order api
1) price_field_id - if NONE of the rows have a price_field_id then use the default pricefield id for all of them (I don't want to open up technical analysis of dealing with multiple price sets, more complex config) - so this is just for that common use case
2) qty - if not set, default to 1
This would make the minimum required params for a 'quick config' (I hate that usage but I think we know what it means) order
```
$this->callAPISuccess('Order', 'create', [
'financial_type_id' => 'Donation',
'contact_id' => $contact1,
'line_items' => [
['line_item' => [
[
'financial_type_id' => CRM_Core_PseudoConstant::getKey('CRM_Contribute_BAO_Contribution', 'financial_type_id', 'Donation'),
'line_total' => 40,
],
[
'financial_type_id' => CRM_Core_PseudoConstant::getKey('CRM_Contribute_BAO_Contribution', 'financial_type_id', 'Member Dues'),
'line_total' => 50,
],
]],
]
]);
```
Ideally we would also accept
```
'financial_type_id' =>'Donation',
```https://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/140Order API - Participant Status2020-12-09T15:25:34Zmattwiremjw@mjwconsult.co.ukOrder API - Participant StatusCurrently Order API does not allow setting participant or membership status. It is hardcoded to `Pending from incomplete transaction` for participant and `Pending` for Membership.
This is a problem for event cart which will use Order A...Currently Order API does not allow setting participant or membership status. It is hardcoded to `Pending from incomplete transaction` for participant and `Pending` for Membership.
This is a problem for event cart which will use Order API per https://github.com/civicrm/civicrm-core/pull/17886 and needs to set `Pending from cart` as status.
All other parameters for participant/membership can be passed through and will be set to whatever you set them to (or defaults if not set).
My view is that we don't need to put any restrictions in place on what the status can be set to.
We are not talking about contribution status here - the two are independent. Any flow that "completes" a contribution will also complete any linked participants/memberships if they are not already "completed" but we hope to separate this logic more in the future as it doesn't work for everyone.
Over the last couple of years we've been progressively removing more and more restrictions within core about what can/can't be done (with memberships mostly) but also participants because any restriction in core restricts what can be done via extension/third-party integrations.
My proposal here is to remove the restriction on participant status when created/updated using Order API per: https://github.com/civicrm/civicrm-core/pull/18096 Note that you *can* pass a participant/membership ID in here but it will still get overwritten with the hardcoded status (so eg. a "completed" membership would get set to Pending and a "On waitlist" participant would get set to "pending from incomplete transaction").
I don't think we are going to run into the same issues that we do with contributions when changing statuses because the participant/membership entities don't have a whole set of financial accounting behind them.
Thoughts please @eileen @artfulrobot @KarinG (webform_civicrm will need converting to Order API at some point) @wmortada @bgm
Also note that, according to the docs here https://docs.civicrm.org/dev/en/latest/financial/orderAPI/#sample-ordercreate-for-single-event-registration until 5.20 the Order API created participants as `Registered` by default.5.34.0