We now include the refunded amount in the email to the customer. When
voiding a payment, it's the full amount of the payment. When giving back
credit then it's only the money that has been paid too much.
At closer inspection, almost all logic around which payment actions to
display involves only the state of the payment. So I moved the logic
there.
We now have one list of all possible actions supported by the UX. Then
payment methods can declare a list of supported actions. If that's
conditional, they can implement the conditions themselves. The payment
model itself then still filters the actions based on its state.
Currently it works like any other payment method you can select on
checkout. It will eventually be added automatically to the order, when a
customer has credit available.
Most of the time this doesn't get called because source_required: false.
But sometimes it [does happen](https://app.bugsnag.com/yaycode/openfoodnetwork-uk/errors/66329690f4b6380007e8a4f8)
I have a feeling that source_required? could be moved to the superclass as payment_source_class.present?. But I don't know enough about this area of the system to try it...
