A full read of kessai from the first file, `1.x` at `2692528`. All 150 tracked files; phpcs at `Drupal,DrupalPractice` over the module root, phpstan level 5, cspell at CI's own expanded config (probed with `colour`/`handback`/`behaviour` first), potx per project in both directions over all five catalogs, a duplicate scan, a verb-first naming scan over 199 method names, and a metrics regeneration. Every linter is already clean and the metrics page still matches the tree. Four findings. ## Opening a provider session is the one write to a payment that does not go against its locked row `PaymentEngine::createSessionAtGateway()` stores the session the gateway just handed back by loading the payment fresh and saving **the whole entity**: ```php $fresh = $this->getPaymentStorage()->loadUnchanged($payment->id()); ($fresh instanceof PaymentInterface ? $fresh : $payment)->setPaymentSession($session)->save(); ``` Every other write to a payment in the module goes through `writeUnderRowLock()` or `accumulate()`, and `docs/architecture.md` states the rule outright: *every write to a payment goes against the locked row, not just the ones that read it first*. `PaymentRecorderInterface` repeats it, and the three `record*` doors, `recordReturnUrl()` and `clearSiblingTokens()` were all moved onto that writer for exactly this reason. This call site was not swept with them. Reloading narrows the window; it does not close it. The read and the save are two statements, and a settlement committed between them is written back, because saving an entity writes every one of its fields: * A payment's first checkout session lapses while the payer is away at the provider. They paid, but the browser return failed. * They click pay again. `loadStoredSession()` finds no open session, so the engine takes the `create_session` lock and asks the provider for a new one — seconds, with no connect or read timeout available. * Worldline's webhook lands in that window. It takes the **settle** lock, which is a different lock, and captures the payment: `state` becomes captured, `captured` becomes the amount, a completed claim row is written. * The handoff request comes back, reloads, and saves. If the webhook's write lands between that reload and that save, the save puts `state` back to `pending` and `captured` back to `0.00`, with the claim row still there saying the money moved. The payment is then pending with a completed claim against it, `getBalance()` reads `0.00` so it can never be refunded, and the expiry sweep is free to write off a payment that was paid. That is the same damage the onward-URL write used to do, described in the same section of the architecture document. The fix is to write the session through `writeUnderRowLock()` like everything else, so only the session columns move and they move against the locked row. ## The simulator tells a French payer their payment is "captured" `SimulatorCheckoutForm` builds the already-settled line from the raw state value: ```php '#value' => $this->t('This payment is already %state.', ['%state' => $payment->getState()]), ``` `getState()` answers with the stored machine name, so the page reads "This payment is already captured." in English and "Ce paiement est déjà captured." in French — the sentence is translated and the word inside it is not. The payment's `state` field already declares a translated label per value (`Pending`, `Authorized`, `Captured`, `Canceled`, `Refunded`, `Failed`, `Expired`), and all seven are already in kessai's own French catalogue. The capital reads wrong mid-sentence in both languages, so the line also becomes `This payment is already resolved: %state.` — "resolved" is the word the engine and the handoff route already use for a payment that has left pending — and the label goes after the colon where a capital belongs. ## `kessai_audit_trail` still calls the engine's token a card The engine holds a **token** and the human is the **payer**; only `kessai_worldline` and `kessai_simulator` keep card words, because those really do take cards. `PaymentAuditTrailSubscriber` still says "stored card token" in its class docblock and "The stored-card token" in the comment above the transient bucket, and its test says "A card alias does not belong on the longest clock." `docs/events.md` already describes the same bucket correctly, as "the stored token", so the submodule contradicts its own documentation. ## `settleOnGateway()` documents a failure path it does not have Its docblock says a gateway that is not installed is recorded as a failed payment there: > the gateway the payment names may not be installed at all. All three leave nothing moved, so all three record the failure … The gateway is loaded inside this, so the last of the three is recorded like the other two instead of escaping a method whose whole answer is a settled or declined payment. It is not. `createTokenPayment()` calls `createPayment()` first, which loads the gateway to ask it for a deadline and raises `GatewayDeclinedException` before any payment row is saved — so `authorizeToken()` and `chargeToken()` raise and write nothing, which is what `PaymentClientInterface` correctly documents on both of them. By the time `settleOnGateway()` runs, `loadGateway()` is answering from its per-request memo and cannot raise at all. So a comment in the money path says the opposite of the interface beside it, and a test written on the strength of it would pass without exercising anything. The comment is corrected to say what actually happens, and the behaviour it describes gains the test it never had. ## Tests * The session write gains a test that a settlement committed by another copy survives opening a session, and that the caller's own object still sees the session it was handed. Stated plainly: a single-process kernel test cannot observe a row lock, so this pins the contract rather than reproducing the race — `test-only changes` will pass on it, and that is what a contract test looks like. * The simulator gains a functional assertion that the settled page carries the human label and not the machine name. * `authorizeToken()` and `chargeToken()` against a gateway this site does not have gain the test the corrected comment describes: each raises `GatewayDeclinedException` and leaves no payment row behind. ## Dropped after checking, so they are not re-filed * `deleteStoredTokens()` clears the alias locally only for payments sharing the first one's subject, so a batch mixing subjects would leave the others carrying a token whose alias is gone. Every shipped consumer builds its batch from one subject, and the interface already says "every payment of the same subject", so there is no reachable consequence today. * `isReturnSecretValid()` answering TRUE for a return that carried no secret. The route verifies its per-payment token first and settles from the provider server-side, never from the query string, which `docs/gateways.md` already reasons through. * The two stub gateways under `tests/modules/kessai_test` sharing four identical method bodies. They are deliberately two gateways and each docblock says which. * `kessai_worldline`'s shipped `api.url` pointing at the pre-production endpoint. That is the safe default and the settings form and documentation both say to change it when going live. 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.)