Acceptance criteria

• The new use case will be responsible for creating a payment and its assorted data, saving it in the repository and returning an output DTO.

Some aspects of this use case are in child tickets and can be left out of the initial implementation

Implementation details:

Suggested fields for input DTO (aka "Request"):

• amount (in cents, integer)
• interval (integer)
• payment type (as string )
• IBAN and BIC, defaulting to empty strings

Return DTOs:
Suggested fields for successful output DTO (aka "Response"):

• payment id
• an instance of URLGenerator, with the payment id filled in

The failure type only returns the reason as a string.

Other hints:

• The AddDonationUseCase already contains a lot of the needed code for creating the new class.
• The "Create Payment" use case should be one of the few places in the domain that branches on payment types. Try to use polymorphism and types as much as possible.
• The dependencies and the validation methods that will be created in the sub-tickets should already be defined in the interface when working on this one.
• Until T300490 is implemented, we use a dummy bank transfer code.
• You can delete the PaymentDataValidator and its test - min and max amount is specific to donation and membership, checking if the payment method string matches an available payment method is part of the use case (and should not be exposed anywhere else).