Acceptance Criteria

• The domain objects (payment and credit-card related payment data) are refactored according to the data model (see discussion part). You can leave other payment objects in a semi-broken state as long as all remaining tests still pass and the next steps are clear (i.e. putting TODOs/commented-out code in classes, skipping tests).
• There is a PaymentRepository interface with methods for getting a payment (by id) and storing a payment
• There is an implementation of the interface that stores a payment class with credit card payment method in database tables. All other payment methods may throw "Not implemented" logic exceptions for now.

Implementation details

• Suggested refactoring for the new class that holds credit card data:
  • The new class should combine most responsibilities/properties of CreditCardPayment and CreditCardTransactionData. see discussion above for certain fields of CreditCardTransactionData.
  • Credit card payments can be "created" an "processed" (see BookablePayment that already exists). The default constructor can create an unconfirmed payment, all other data should come in through the confirmation method (with a`CreditCardTransactionData` object)
• Suggested refactoring for the CreditCardTransactionData class: Get rid of the FreezableValueObject trait and use a value object (constructor and readonly properties instead). The end goal should be an object with a constructor and property getters/readers (We can decide if we want to use PHP 8.1 readonly or just annotate for now). To reduce the number of constructor parameters (from currently 11 to 5-7) see discussion on dropping properties. Drop transactionStatus as a constructor parameter, that's always the same string. Also, try to use smaller value objects, e.g. TransactionIdentifier that contains transactionIdand TransactionTimestamp.
• The Payment ID must be non-nullable and passed through the constructor. Tests will use fake payment IDs, production code will use the ID generated created in T301115: Create sequential IDs from payment repository.
• Use Doctrines Inheritance Mapping with Class Table Inheritance to map the abstract payment to the credit card payment. You can have a look at the donation bounded context mappings for DonationPayment and DonationPaymentSofort as examples.