This task is mostly moving the payment-related parts of the use cases from the Donation bounded context to the payment bounded context and using a different repository (PaymentRepository instead of DonationRepository).

Acceptance criteria

• There is one use case for booking an external payment, with a unified interface
• The use case checks
  • If the payment (referenced by ID) exists, by loading a payment from the repository by ID.
  • If booking data (data from payment provider) is valid (already implemented in the bookPayment methods of payments that implement the BookablePayment)
  • If the payment is not booked book it
• if the checks are ok, the use case books and persists the payment and returns an output DTO

Implementation Details

The output DTO should have a payment-independent interface, mostly informing about success or failure (with some message about why the failure occurred). SofortNotificationResponse from the donation bounded context can be a good inspiration.

Given our intended usage of this use case (calling it inside the notification use cases of Membership and Donations), finding the payment by ID should never fail (you may throw a LogicException instead of returning a failure result).

The use case itself should not branch on payment type. If you need different services for different payment types (e.g. origin check), create a factory, like in the "Create Payment" use case.