>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3614082. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !19 >>> <p>Split out of <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/kessai/-/work_items/3614067" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/kessai/-/work_items/3614067</a></span>, which records the decision and the reasoning. Third of three. Independent of <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/kessai/-/work_items/3614080" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/kessai/-/work_items/3614080</a></span> and <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/kessai/-/work_items/3614081" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/kessai/-/work_items/3614081</a></span>, so it can land in any order, though the settings form description reads better once the gateway declares its own deadline.</p> <h3>The default deadline setting has no form and no constraints</h3> <p><code class="language-php">kessai.settings:default_payment_ttl</code> is editable only by importing configuration, and its schema declares an integer with no bounds, so a negative or absurd value is accepted silently.</p> <p>Adding a settings form with a single bounded number field, and a range constraint in the schema so the value is validated wherever it is written, not just through the form. The description explains what the setting now means: the fallback used by a gateway that declares no window of its own.</p> <p>The route sits at the path the Worldline submodule already assumes as its parent, which currently has no page behind it, so the section gains a real root and the Worldline settings and the payments list are reparented under it.</p> <h3>The reconciliation sweep has no budget</h3> <p><span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/kessai/-/work_items/3614081" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/kessai/-/work_items/3614081</a></span> made the expiry sweep ask the provider before writing a payment off, which is right, but it left cron making up to two hundred sequential API calls in a single run with nothing bounding them. The Worldline SDK offers no connect or read timeout of any kind, the only timeout it exposes being the hosted checkout session, so a hung call cannot be bounded from our side and limiting how many calls a run makes is the only defense available.</p> <p>Adding a second setting beside the deadline, the number of payments a single sweep may ask a provider about, defaulting low. A payment not reached in one run simply stays pending and is asked in the next, which is the behavior wanted anyway, and the run logs what it left. This belongs to the engine rather than to any gateway: the sweep is kessai's, it covers every gateway, and reading a submodule's configuration to run kessai's own cron is the layering <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/kessai/-/work_items/3614080" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/kessai/-/work_items/3614080</a></span> and <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/kessai/-/work_items/3614081" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/kessai/-/work_items/3614081</a></span> exist to undo.</p> <h3>The deadline is not visible to an operator</h3> <p><code class="language-php">expires</code> is not exposed in the payments view, so an operator cannot see which payments are about to lapse or sort by the deadline. Adding it as a sortable column alongside the created column.</p> <h3>The handoff is not recorded in the audit trail</h3> <p><code class="language-php">PaymentEvents::INITIATED</code> is the one lifecycle event the audit trail bridge does not record. It is not a money outcome, which is why it was left out, but it is the last local record before the payer leaves and the moment a consumer locks its order, which is exactly what a dispute needs to establish. Recording it, and correcting the bridge documentation, which currently states that every outcome resolving a payment is recorded and so does not describe the new entry.</p> <h3>Notes</h3> <p>Configuration in <code class="language-php">config/install</code> applies at install time. The module is in alpha and its releases carry no migration path, so an existing site picks these up by reinstalling. Documentation and the French translations are updated in the same merge request.</p>