### Problem/Motivation A full read of the module from its first file rather than a diff against the last tag: all 141 tracked files, plus phpcs at the ruleset CI fetches and again at DrupalPractice, phpstan at level 5, cspell at CI's own configuration rather than core's, a British-spelling sweep, a docs identifier sweep, a shipped-config translation audit run through locale on an installed site, a metrics regeneration and a repeated-literal scan. Every linter is clean and the metrics page is current. Nine findings. Two are defects: - **A movement asked twice for its payment answers with the copy it loaded the first time.** `MovementBase::getPayment()` reads the entity reference's own `entity` property. Core's `EntityReference::getTarget()` loads the payment once and then keeps it on the field item for the rest of the request, so a claim, a refund or a reversal asked again after money has moved hands back the totals as they stood before it moved. Every money write in the engine goes through `loadUnchanged()` and `save()`, which replaces the object storage holds and leaves the pinned one behind. `MovementInterface` is `@api`, so this is a consumer's trap rather than an internal one: read a claim's payment, refund the payment, read the claim's payment again, and the refunded total is still zero. - **`create()` takes any amount string, including a negative one the engine can then never give back.** `authorizeToken()` and `chargeToken()` both refuse a non-positive amount, and `create()` already validates the kind on the stated grounds that nothing on that path validates the entity. The amount gets no such door. A negative one is created, captured into a completed claim, and leaves `getBalance()` negative, so every refund is then refused as more than is refundable: money recorded as taken that the engine will not let back out. A malformed one reaches `bcadd()`, which raises a `ValueError` naming bcmath rather than the caller. Three are places the engine goes quiet, or spends something it did not need to: - `recordCheckoutUndone()` returns without a word when the amount is not positive. That is the shape of the money finding in #3621918, where a caller reached it with a figure of zero after the undo had already gone out to Worldline. The caller was fixed there; the door was not. Every other path in this engine that cannot do what it was asked says so at warning severity: capture-skipped, cancel-skipped, refund-skipped, and the direct sale that clamps the amount it was handed. The interface docblock does not mention the case at all, on the one method whose own documentation says there is no second chance to write the row. - `WorldlinePaymentHandler::resolveFromProvider()` logs the SDK's bare exception message when the hosted-checkout status fetch fails. That message is the category rather than the cause, naming neither the offending field, nor the HTTP status, nor the platform's error id a support ticket is opened with; `WorldlineError::describe()` exists precisely because of it, and the gateway's four other catches all use it. This call is the one both the payer's return and the cron sweep make, so it is the failure that leaves a payment pending with nothing legible saying why. - The reconciliation budget in `expireDuePayments()` is decremented before the gateway is loaded. A payment naming a gateway this site no longer has therefore spends a unit of a budget whose documented purpose is to bound network calls, while making none, and defers real payments to a later run for nothing. That is a state the module's own instructions produce, since kessai_simulator's status report tells a site to uninstall it before going live. Two are the admin surface, and both cost a French operator more than an English one: - **Twelve translatable strings in the four shipped views reach no `.po` file.** Each view ships a description, a table summary and an empty-area text, all marked translatable by core's config schema and none of them present in any of the module's five catalogs. Verified through locale's own lookup on an installed site rather than inferred: the column labels and the captions resolve, these do not. The summary is what core calls the table's accessible description, so a screen-reader user reading in French gets an English account of a thirteen-column table, and the empty text is the first thing an operator sees on a site that has taken no payments yet. - **All four views ask the operator to type a state's machine name.** The state is a `list_string` with seven translated labels on a payment and three on a movement, and the exposed filter is a free-text `contains` box. Nothing on the page says which words are valid, the labels the entity already defines are never shown, and the value typed is English whatever the interface language. The `list_field` plugin is not the answer and the suite already says so, since it raises on a base field, which is why `PaymentsViewTest` pins the string handler. Two are duplication of the kind #3620119 and #3621918 each fixed one of: - The `worldline` plugin id has three owners: the attribute declares it, `findChainAnchorReference()` writes the literal into its query, and `WorldlineWebhookController` writes it again to refuse a notification belonging to another gateway. A drift between them raises nothing. The webhook simply resolves no payment and stops settling anything, and the card-on-file chain quietly loses its anchor. - A claim row has one owner and the other two movements have none. `recordClaim()` is the single place a claim is written; a refund row and a reversal row are open-coded in `doRefund()`, `doCancel()` and both halves of `recordCheckoutUndone()`, four copies of the same create, the same currency copy and the same save. The last two money bugs in this module were each a path that did not write the row its siblings wrote. ### Proposed resolution - Load a movement's payment through the payment storage. It is statically cached, so it costs no query, and it attaches nothing to the row, so the answer is whatever storage currently holds. - An `assertAmount()` beside `assertKind()`, refusing anything that is not a well-formed decimal of zero or above, at all three creation doors. Zero stays legal, because a zero-amount payment is the documented way to carry a card on file for a free booking; the two token paths keep answering a zero amount with NULL and now raise on a negative one instead of quietly doing the same, which is the caller's bug either way. - Log the skipped undo at warning severity, naming the payment and the figure, and say so on the interface. The existing test pins that nothing is recorded, which stays true. - Render the status-fetch failure through `WorldlineError::describe()`, like the gateway's other four catches. - Spend the reconciliation budget where the call is made, after the gateway loads. - Add the twelve view strings to the kessai_views catalog, and pin the gap with a test that walks the shipped config through the same locale lookup, so a string added to a view later cannot go untranslated unnoticed. - Turn the state filter into a grouped filter, which is core's own pattern for the node status: it keeps the `StringFilter` handler `PaymentsViewTest` pins, renders a select of the states' own translated labels, and compares with equality rather than a leading-wildcard `LIKE`. - Name the plugin id once on `WorldlineGateway`, read back by the webhook, with the gateway asking itself through `getPluginId()`. - One private writer the three record helpers share, so a column added to a movement is added once. ### Remaining tasks Review and merge. ### User interface changes The state filter on the payments, claims, refunds and reversals lists becomes a select of the states, in the interface language. The four lists gain French for their descriptions, their table summaries and their empty text. ### API changes `PaymentManagerInterface::create()`, `::authorizeToken()` and `::chargeToken()` now raise `InvalidArgumentException` for an amount that is not a well-formed decimal of zero or above; the two token methods previously answered a negative amount with NULL. `WorldlineGateway` gains a public constant for its plugin id. Nothing is removed and no signature changes. ### Data model changes None. ### Release notes snippet A claim, a refund or a reversal now answers with its payment as storage currently has it, rather than with the copy it first loaded. An amount that is negative or malformed is refused at the door instead of being recorded as money the engine can never give back. A checkout undo the engine cannot record now says so in the log, and a Worldline status fetch that fails now logs what the platform actually said. The four payment lists filter by state through a select of the states' own labels, and their descriptions, table summaries and empty text are translated. AI-Generated: Yes (Claude Code was used to read the module, to draft this issue summary, and to write the fixes and their tests on the merge request. I reviewed all of it, and each new test was confirmed to fail against the unfixed code.)