Check if we need to distinguish between "error" (an error occurred because something went wrong) and a "domain error" (the checking code in our domain decided that the payment notification can't be handled)? In the first case, we'd tell the payment provider "Hey, we couldn't handle this, please resend" which (at least in the case of PayPal) would cause retries (with exponentially growing time between them to allow us to fix the error). The second case is more of a "logic" error. In this case we should tell the payment provider that everything went smoothly and try to resolve the issue internally (adapting rules, rightfully ignoring the request, etc).

Go through the logic in the use case

• Check if the FailureResult of the BookPayment use case needs the distinction between error and domain violation
• Check for possible domain/logic exceptions and return an unhandled result
• Go through all instances of createFailureResult/createUnhandledResult to see if they are correct.
• Add explanatatory doc comments to the result from the BookDonation use case

The guiding question when deciding is "Is this a recoverable error that we can try again?"

This task can have the following outcomes:

• Simplified result object (just success/failure, "unhandled" becomes "failure")
• Simplified result object + throwing exceptions on error
• Keep trinary state

Implementation Notes

• Should be done before adapting the BookPayment routes (T307892: Change donation payment notification routes in Fundraising Application).
• Work for this should be done in the BookDonation use case.