This task is about moving the payment-related parts of the use cases that handle notifications from payment providers from the Donation and membership bounded contexts to the payment bounded context.

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
  • 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 (with exception/different execution path for "followup payments", see below)
  • If the payment originated from the payment provider (where possible, with a unified interface that supports all payment providers). This feature is called "Origin Check"
• if the checks are ok, the use case books and persists the payment
• PayPal Payments should support booking multiple times:
  • Check transaction id, if it matches the payment, fail
  • If it's different, create a new payment (amount and interval matching the original payment), book it, add a reference to the parent payment and store it.
  • Returns a different success DTO, indicating a followup payment. Using different classes forces the calling code to use different code paths for successful first-time and followup payments.

We have split this task into several (dependent, but more manageable) subtasks