## Problem/Motivation Two defects in the payment account entity added in #3621924 and #3621928, found by a full audit of the module. Both are about the same thing: an account names a gateway plugin, and nothing connects the two beyond that string. ### An account outlives the module that provides its gateway, and is still offered `PaymentAccount` calculates no dependencies, and the three shipped accounts ship `dependencies: { }`. So nothing ties `kessai.payment_account.simulator` to `kessai_simulator`, or `kessai.payment_account.worldline` to `kessai_worldline`, and uninstalling a gateway module leaves its account behind, **enabled**. Observed in a kernel probe against 1.x, after `module_installer->uninstall(['kessai_simulator'])`: ``` account after uninstall: STILL THERE, enabled=true getAvailableGateways(): {"manual":"Manual / offline","simulator":"Simulator (fake card)"} isGatewayAvailable('simulator'): true create('10.00','EUR','simulator','booking') threw: GatewayDeclinedException: Payment names account "simulator", whose plugin "simulator" is not installed on this site. ``` So a checkout goes on offering a payment method the site no longer has, `isGatewayAvailable()` confirms it to a consumer validating a stored id, and every payer who picks it meets an exception. The module already established the rule for the four shipped views in #3620960, which carry `dependencies.enforced.module: [kessai_views]` for exactly this reason; the accounts were added afterwards and never got it. The same probe shows a second, smaller thing: that exception names no payment. `createPayment()` loads the gateway to ask it for a deadline before the row is saved, so `$payment->id()` is NULL and the line reads `Payment names account`, with a hole where an id would be. ### Adding an account never asks for the settings its gateway needs `PaymentAccountForm::form()` builds the gateway's own configuration subform from `$account->getPluginId()`, which on the add form is the empty string: the gateway is chosen in the same submit. There is no AJAX and no rebuild from the submitted value, so the subform is never built on the add form at all. `submitConfigurationForm()` then runs against no values and writes the gateway's defaults, and the account is saved **enabled** with no credentials. An operator following `modules/kessai_worldline/README.md` -- *"Add one under Administration > Payments > Accounts and pick Worldline as its provider; the API credentials, the webhook key and the hosted checkout options are all on that account's form"* -- adds an account, is shown none of those fields, and ends up with an enabled Worldline account that opens no checkout. Every payer who picks it is told *"The payment could not be started just now."* until somebody notices and edits the account. The gateway's `#required` elements cannot help, because they are never rendered. Nothing caught it because the only test of the add form uses the `manual` gateway, which configures nothing. ## Proposed resolution **Refuse the uninstall while accounts are held at the module's gateways.** A `ModuleUninstallValidator` names the accounts in the way; the site owner deletes each one first, which the account's own delete form refuses in turn while payments name it, and then the module goes. The same shape core's `filter` and `field` modules use. **Not by deleting the accounts,** which was the first attempt and is wrong twice over. It deletes an account `PaymentAccountDeleteForm` would have refused to delete, straight past that refusal, from the Uninstall page. And an account id is named as a plain string by things no config dependency can see -- `yoyaku_payment.settings` holds one as its default, and a workflow step holds the one it takes payment through -- so an account having no payments does not make it unused. Retired accounts count, since disabling one changes nothing about what already names it. Uninstalling `kessai` itself is not refused by its own accounts, because that takes the entity type and the payments with them. And `ConfigImportModuleUninstallValidatorInterface` is answered as core's `field` module answers it, so an import that removes the accounts and the module together is allowed: that is the order the refusal asks for. **Build the gateway's settings subform from the gateway being chosen.** The plugin id is taken from the submitted value when there is one, falling back to the raw input and then to the entity, so the subform exists on a straight POST and the gateway's `#required` elements are enforced with no JavaScript. `#ajax` on the gateway select reveals the same subform as soon as it is picked, which is what the READMEs already describe. **Say which payment, or say none.** The two `loadGateway()` refusals name the payment only when it has an id, so the message reads for a payment being created as well as for one being settled. ## Also found in the docs, and fixed here `docs/events.md` says two things the engine does not do, both read off the published page against the code: - **`PARTIALLY_CANCELED` is described as leaving the payment authorized.** It is also announced when the *last* of a hold is released on a payment that already claimed something, and that payment stays **captured** -- `CANCELED` means nothing was ever taken, which is the rule `docs/architecture.md` states and which `PaymentReversalTest::testWhatTheNonFinalClaimLeavesCanBeReleased()` pins. A consumer writing a subscriber for a no-show fee claimed out of a guarantee is exactly who reads that row, and it tells them the wrong state. - **The deadline is said to default to `kessai.settings:default_payment_deadline`,** with that key switching expiry off site-wide. The gateway decides: the bundled `manual` gateway's payments never lapse whatever the key says, which is the module's headline behaviour and what `PaymentExpiryTest` pins. The key is the fallback for a gateway declaring no window of its own. Both are documentation defects: the behaviour is right and already tested, and the page disagreed with it. ## Remaining tasks - [x] Kernel test: uninstalling a gateway module is refused while an account is held at it, retired accounts included, with the wiring and the logic each toggled; and once the account is deleted the module goes and nothing offers it. - [x] Functional test: adding a Worldline account collects the API settings, and refuses to save without the required ones. - [x] `docs/architecture.md` still files the settings under *Configuration > Web services* and says the gateway submodules hang their own pages under them. Both were replaced in #3621928. - [x] `docs/events.md` misstates the state a `PARTIALLY_CANCELED` payment is in, and what the deadline defaults to. No new test: both behaviours are already pinned, and it was the page that was wrong. ## User interface changes The add-account form shows the chosen gateway's own settings, as the edit form already does. Uninstalling a gateway module now lists its accounts among the configuration that will be deleted. AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and tests on the merge request. I reviewed and ran the work myself before posting it.)