Checkout Workflow - One more status needed?

Hey Nick -
I'm helping George with his installation and in reviewing the forums, I am finding there is a significant amount of user confusion about the workflow and the states the order goes through. In particular, we have a state 'refunded' that reflects the progress of reversing the financial transaction, but we dont have an equivalent 'paid' state for the initial financial transaction. It seems it should be consistent and by adding one more state to the workflow a lot of the confusion would be resolved. As it is now, the state 'confirmed' is a bit ambiguous as to whether it is signifying a confirmed contractual arrangement, hence a freezing of certain data fields like product and price, but still allowing payment methods to be changed if the initial method did not complete, or a confirmed payment, in which case there is no preceding step that verifies all required data fields necessary for fulfillment have been reviewed and confirmed. My suggestion is to have two states, confirmed which matches the 'confirm' layout and aligns with someone clicking the submit button to say that all displayed data is correct, and launches the payment plugins to attempt payment. And a subsequent state of 'paid' which aligns with a payment success returned from a gateway and launches the shipment/fulfillment process. Only a 'Paid' can be reverted to a refunded state, releasing inventory. Created and Confirmed revert to a cancelled state, releasing inventory.

If you don't concur that two states are needed to separate "agree to purchase" and "funds received" then help me understand how we can infer the financial aspect - how to identify orders that are ready to ship from orders that are confirmed but still unpaid using the API hooks OnBeforeOrderConfirm and OnAfterOrderConfirm. On Before is perfect for last-pass validations of all data going into the order, shipping address, product configuration, and inventory availability, before entering into an agreement/formalizing the order. OnAfter is great for triggering payment following the digital signature/database commit of the agreed upon order. Where is the API equivalent for OnAfterPaymentReceived to start the fulfillment process?

It seems a "Confirmed(but not paid)" state should be separate from the "(confirmed and) Paid" state. Only Paid orders can advance to Shipped and a review of orders in the backend would clearly separate the "confirmed (but hung up in payment)" orders that may eventually need to be called to request/assist with obtaining payment or be cancelled after x days, from the "paid (but not shipped)" orders that clearly identify any backlogs in fulfillment/shipping. While the payment received data fields could be displayed and queried to sort this combined list, it seems these should be two separate states for the order workflow.
Thanks for clarifying,
Duke

Thanks - I'll dig into these.

Please consider these subtleties in the workflow as a target rich environment for the documentation project.