|
|
|
@@ -27,13 +27,20 @@ Rechnung) liegt gekapselt in einem Modul pro Zahlungsart. Aufgelöst wird über
|
|
|
|
|
Abgesichert über
|
|
|
|
|
`sanitizeParticipantOptions()` / `participantOptionsComplete()` (Guard im `SignUpCommand`).
|
|
|
|
|
- `type` ist i.d.R. `'string'`; `'richtext'` wird über `Views/Components/TextEditor.vue` (TinyMCE, HTML) gerendert
|
|
|
|
|
und via `v-html`/`{!! !!}` ausgegeben. Teilnehmer-Eingaben rendert die generische
|
|
|
|
|
`SignUpForm/components/PaymentMethodInputs.vue` schema-getrieben.
|
|
|
|
|
und via `v-html`/`{!! !!}` ausgegeben; `'icon'` rendert die `Views/Components/RichSelectBox.vue` (kuratierte
|
|
|
|
|
FA-Symbol-Auswahl, Liste in `resources/js/constants/paymentMethodIcons.js`). Teilnehmer-Eingaben rendert die
|
|
|
|
|
generische `SignUpForm/components/PaymentMethodInputs.vue` schema-getrieben.
|
|
|
|
|
- Optionaler Schlüssel `'hint'` je Option: erklärender Hilfetext, den die Admin-Render-Stellen unter dem Feld anzeigen
|
|
|
|
|
(z.B. bei `payment_information`, dass der Text am Anmeldeende + in der Mail erscheint).
|
|
|
|
|
- `defaultConfiguration()` je Modul liefert die Start-Config beim Anlegen der Tenant-Instanz (`CreateTenantAction`),
|
|
|
|
|
aktuell das Default-Symbol (`icon`): Überweisung `building-columns`, Sonstiges `coins`.
|
|
|
|
|
- **Aktivierungs-Guard:** Eine Tenant-Zahlungsmethode darf nur `active` werden, wenn alle `required`-Optionen befüllt
|
|
|
|
|
sind (`isConfigurationComplete()`), erzwungen in `UpdateAvailablePaymentMethodAction`.
|
|
|
|
|
- **Config-Speicherung (JSON):** pro Tenant auf `available_payment_methods.configuration`, pro Event auf dem Pivot
|
|
|
|
|
`event_payment_methods.configuration`. Beim Zuweisen an ein Event wird die Tenant-Config als **Snapshot kopiert**
|
|
|
|
|
(Copy-on-Assign, spätere Tenant-Änderungen wirken NICHT nach). Sync erfolgt differenziell in `UpdateEventCommand`.
|
|
|
|
|
(Copy-on-Assign, spätere Tenant-Änderungen wirken NICHT nach). Sync erfolgt differenziell in
|
|
|
|
|
`SetPaymentMethodsCommand` (Endpoint `/api/v1/event/details/{event}/payment-methods`, ausgelöst aus dem
|
|
|
|
|
„Teilnahmegebühren"-Bereich).
|
|
|
|
|
- **`PaymentMethod` ist nur eine Fassade:** `PaymentMethod::optionsFor/participantOptionsFor/requiredOptionKeys/`
|
|
|
|
|
`sanitizeConfiguration/isConfigurationComplete/defaults()` delegieren an die Registry. Bestehende Aufrufstellen
|
|
|
|
|
bleiben stabil.
|
|
|
|
@@ -94,7 +101,8 @@ Beispiel GiroCode (nur Überweisung):
|
|
|
|
|
## Neues Zahlungsmodul hinzufügen
|
|
|
|
|
|
|
|
|
|
1. Klasse unter `Modules/` anlegen, `extends AbstractEventPaymentModule`; `slug()`, `defaultName()`, `getOptions()`
|
|
|
|
|
implementieren; `registrationSummary()`/`doPayment()`/`createInvoice()` überschreiben, wo nötig.
|
|
|
|
|
implementieren; `defaultConfiguration()` (z.B. Default-`icon`) sowie
|
|
|
|
|
`registrationSummary()`/`doPayment()`/`createInvoice()` überschreiben, wo nötig.
|
|
|
|
|
2. Zahlart-spezifische Extras als **eigenes Fähigkeits-Interface** (nicht ins Core-Interface).
|
|
|
|
|
3. In `EventPaymentModuleRegistry::MODULES` eintragen. `PaymentMethod::create(['slug' => …])` wird dann automatisch über
|
|
|
|
|
`ProductionDataSeeder` (iteriert `EventPaymentModuleRegistry::slugs()`) geseedet.
|
|
|
|
@@ -102,8 +110,10 @@ Beispiel GiroCode (nur Überweisung):
|
|
|
|
|
|
|
|
|
|
## Datenübernahme
|
|
|
|
|
|
|
|
|
|
`storage/app/sync_payment_bank_data.php` überführt einmalig Bestands-Bankdaten (Tenant/Event) in die Modul-Config
|
|
|
|
|
(idempotent). Bei Live-Inbetriebnahme einmal ausführen.
|
|
|
|
|
`storage/app/2026_08_05_backfill_payment_method_configuration.sql` überführt einmalig Bestands-IBAN-Daten (Tenant/Event)
|
|
|
|
|
**und** die Default-Symbole in die Modul-Config (idempotenter JSON-Merge, nichts wird überschrieben). Bei
|
|
|
|
|
Live-Inbetriebnahme einmal gegen die Produktionsdatenbank ausführen — ersetzt das ältere PHP-Skript
|
|
|
|
|
`sync_payment_bank_data.php`.
|
|
|
|
|
|
|
|
|
|
## Tests
|
|
|
|
|
|
|
|
|
|