Spec: Payment Processor integration with FormBuilder

This issue is to gather information about how we can implement Payments using FormBuilder.

Pre-requisites

API4 Payment API: financial#223

The Payment API allows us to record a payment against a Contribution. It is independent of Payment Processor integrations, all of which tell CiviCRM about their payments being attempted/created, completed, failed, etc by calling the Payment API. The Payment API can record partial payments (amount paid is less than amount outstanding), overpayments (amount paid is greater than amount outstanding). There will be a separate Refund API that is a wrapper for Payment API.

API4 Order API: #4367

The Order API allows us to create a Pending Contribution, LineItems and associated entities (eg. Membership, Event Participant).

Creating the Order

PriceSets/PriceFields

FormBuilder will need to develop a UI that allows you to display various PriceFields on the form. We will allow PriceFields from different PriceSets to be used (this might require some internal work in CiviCRM core where it assumes that all PriceFields come from a single PriceSet.

LineItems

CiviCRM core used to have a restriction on one Contribution only have a single lineitem for each PriceFieldValue. This PR https://github.com/civicrm/civicrm-core/pull/30316 should have fixed that (in 5.75).

Order

We should be able to add/remove LineItems as well as update existing Pending Orders. We need to be able to "finalize" the order so it can be submitted for Payment. Joe thinks that non-profits will have requests for changes to the order even after it has been submitted for payment. But we could introduce restriction APIv4 to not allow these changes.

Supporting Diverse Payment Processor Workflows

We need to develop a spec for rendering widgets/content from some but not all Payment Processors on the Contribution form. This will need to handle the various workflows, etc. that Payment Processors provide/require.

To include:

• Off-site redirect and return to the form, reloading form state and showing completed payment.
• On-site "iframe" style with freezing of the Order when it is submitted for Payment and confirmation of Completed payment.
• Payment attempts should be logged in CiviCRM's database so that we have a record of payment attempts and can identify payment issues.