The `PaymentMethod` interface is quite [[ https://martinfowler.com/bliki/AnemicDomainModel.html | anemic ]], leading to the code smell of "[[ https://blog.codinghorror.com/code-smells/ | Inappropriate Intimacy ]]" and static analysis (PHPStan level 2) failing for `SofortPaymentNotificationRouteTest.php` because of assumptions about a returned class (this could also be considered [[ https://en.wikipedia.org/wiki/Downcasting | downcasting ]])
**Refactoring steps/Acceptance Criteria: **
* Find all instances of `Donation` and `Membership` domain models where `getPaymentMethod` or `getPayment` is called. Check how the payment properties are used and add appropriate methods to the `PaymentType` interface. Create an abstract base class if most `PaymentType` implementations share default values. Examples of possible method names: `isExternalPayment`, `supportsRecurringPayments`, `notifyOfFirstPaymentDate`.
* Search context repositories and FundraisingFrontend repo for Payment class names and move all checks (`instanceof`, `getPaymentId`) and getters of properties to appropriate methods of the `PaymentType` interface.
* The only classes in the Donation and Membership domain that are allowed to choose different code paths for the the different implementations of payments should be the `DoctrineDonationRepository` and `DoctrineApplicationRepository` classes.
Notes
* This could be done as part of {T188394}.
* In case the `PaymentMethod` interface gets too bloated, Payment data handling can be factored out via [[ http://www.oodesign.com/strategy-pattern.html | Strategy Pattern ]] or [[ http://www.oodesign.com/visitor-pattern.html | Visitor Pattern ]] (see also https://stackoverflow.com/questions/8665295/what-is-the-difference-between-strategy-pattern-and-visitor-pattern).