>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3614276. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !30 >>> <h3>reauthorize() can strand a hold on the cardholder's card</h3> <p>A card authorization cannot be extended in place, so <code>WorldlineGateway::reauthorize()</code> places a fresh hold and then voids the previous one. That ordering is right: the new hold has to exist before the old one is released.</p> <p>The void runs through <code>call()</code> rather than <code>run()</code>. <code>call()</code> catches, logs and returns a boolean, and <code>reauthorize()</code> discards the boolean. So when the void fails the method still returns cleanly, and the payer is left with two holds against their card.</p> <p>Leaving the new hold in place is correct, and raising here would be worse: the caller would read a failure for an operation that largely succeeded. The problem is what the failure leaves behind.</p> <p><strong>The stranded authorization id exists nowhere afterwards.</strong> <code>chargeStoredCard()</code> has already overwritten the payment's reference with the new hold, <code>$previous</code> was only a local variable, and <code>logException()</code> records the payment id but not the reference. An operator reads "Worldline cancel-previous failed for payment 42" and has no way to find which authorization is still holding the money, short of trawling the back office by amount and timestamp.</p> <p>The module already handles the identical situation properly one file away: <code>WorldlinePaymentFinalizer::releaseOrRefund()</code> logs <code>(@ref)</code> and says the amount "may need releasing in the back office". This should match it.</p> <p>Fix: name the superseded reference in the log, at warning severity, and say plainly that a hold is still open and needs releasing by hand. No behaviour change beyond that; the new hold stays, the payment stays valid.</p> <h3>Remove hook_help</h3> <p><code>KessaiHelp</code> was added in <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/kessai/-/work_items/3614263" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/kessai/-/work_items/3614263</a></span>. It is not wanted, so it comes out along with the six French strings that came with it. The documentation in <code>docs/</code> and the README remain the entry point.</p> <p>Worth recording why it should not come back in this shape: it built its output by concatenating paragraph and list tags into a string, in the same change that removed exactly that pattern from the simulator checkout form on accessibility grounds. Core's own hook_help example does the same thing, so it was idiomatic Drupal and still inconsistent with this project.</p> <h3>Everything else audited clean</h3> <p>Recorded so the next pass does not repeat it. The value objects are properly immutable (<code>PaymentDeadline</code> has a private constructor with named constructors, <code>CheckoutSession</code> is readonly promoted). The event surface matches exactly: seven constants, all seven dispatched, none orphaned. Translations pass potx in both directions across all five modules. Security, query indexes and documentation against code were covered in the previous pass and nothing has changed beneath them.</p>