[proposal] Use payment state machine on order instead of main state machine for refunded state.

[prigal]

Actually this plugin set the "refunded" state on an order.

Refunded is something related to payment. An order can still be completed or whatever while it's payment is refunded.

Moreover Sylius already have refunded and partially refunded states on payment_state in order.

Why not using them and keep order state unmodified ?

In our use case we will have "canceled" orders with refunded state on payment_state when order is canceled.

[Zales0123]

It would be indeed nice to operate somehow on a payment state machine, as we have a relation between payment and refund since #85. Needs to be considered before a stable release 🖖

[prigal]

Imo we should not touch the sylius_payment.state state machine as long as payment can be completed on it's side and there is a refund_payment in front of it.

But we should change order.payment_state state machine as long as it's an overview of all payments states in an order.

[prigal]

Just for reference, if you want to work on it we did this in our fork https://github.com/printoclock/RefundPlugin. (as explained in an other ticket #110 , no time to PR properly but if it's not done by someone else in next future we will do it in a couple of months)