The monitor needs to send emails not only when a payment is processed successfully but also in case a refund entry is created because of some error.
An example is when an investor makes a payment which does not reach the minimum payment amount and therefore has to be refunded.
It would be nice to have an implementation which is generic on the monitor side, so that the monitor (resp. the MonitorService) can simply provide the Refund Reason and the corresponding message is assembled by the email service. Though this would require the RefundReason enum is known in the email moduel which is an undesirable dependency.
Note: refunds are also created in case the last tier or the overall token limit is overflown by a payment. That refund should be send in the same email as the allocated token amount. Overflowing the last tier or total token limit is a corner case.
The monitor needs to send emails not only when a payment is processed successfully but also in case a refund entry is created because of some error. An example is when an investor makes a payment which does not reach the minimum payment amount and therefore has to be refunded.
It would be nice to have an implementation which is generic on the monitor side, so that the monitor (resp. the MonitorService) can simply provide the Refund Reason and the corresponding message is assembled by the email service. Though this would require the RefundReason enum is known in the email moduel which is an undesirable dependency.
Note: refunds are also created in case the last tier or the overall token limit is overflown by a payment. That refund should be send in the same email as the allocated token amount. Overflowing the last tier or total token limit is a corner case.