Metaissue for ensuring our preferred order->pay->createPayment flow is used everywhere.

We have long had the principle (since 4.6 was pre-alpha) that we want to work towards the following flow at a code level.

1. Create a pending Order using Order.create api
2. Optionally process a payment against that order using PaymentProcessor.pay api
3. Create a payment record (either from above or just recording an offline payment) using Payment.create api

The expectation is that the code correctly creates a pending contribution (order) with all the related entities when Order.create is called.

When a payment is added the related entities are updated & if appropriate notification emails are sent out.

(Note an earlier iteration of this was to create a pending contribution always & then update it with contribution.completetransaction - this maps to the above as the Order.create creates the pending contribution and Payment.create calls contribution.completetransaction when the payment completes the order).

This issue is a metaissue to link to & categorise all the things that need to be done to reach this. 'High' Priority are any issues that stand before people adopting the recommended flow.

Item	Status	Priority	Blockers	Notes
Document order api / Pseudoentity	In progress	High	-	At the sprint this was startedCurrent tweak
Deprecate creating orders with non-pending status	Done	High
Order.create should not require total amount	Done	High
Identify any issues that would block someone moving off a non-preferred flow to our preferred flow	Started	High		This is really what this issue is about
Update payment instrument id when adding a payment to a pending order	To discuss	High	Discussion	#81 and possibly #47
Support invoice_id in PaymentProcessor.pay	done	high		#77 (closed)
Support chaining Payment.create from Order	PR	High		Needed to ease adaption to us deprecating creating Orders as non-pending pr
Fix identified core bug on ParticipantPayment creation	To do	High	Tests not yet passing	#74
Make contribution_id mandatory for PaymentProcessor.pay	Done	High		PR - since we have agreed for policy (not technical) reasons to do this we should try to get a test & merged
Document moving off transact api	Done	Medium		PR here
Consider generating default invoice ID in Order.create	To do	Medium	Discussion	#78
Add getters & setters to Payment Class	Done - could do more maybe	Medium		#82
Deprecate transact api from explorer	Done	Medium		#79 (closed)
Deprecate & remove calls to CRM_Contribute_BAO_Contribution::addPayments	To do	Low		This is part of consolidating all payment creation on Payment.create
Fix all remaining places in core to create a pending contribution/order & then complete	Needs chipping away at - tacking events at the moment	In progress	Low	#53
Noisily deprecate transact api	Done	low		#80 (closed)