>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3614067. --> Reported by: [mably](https://www.drupal.org/user/3375160) >>> <p>Split out of the alpha2 audit, <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/kessai/-/work_items/3614065" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/kessai/-/work_items/3614065</a></span>. Each point needs a design decision, so alpha2 ships the current behavior unchanged. The module is in alpha, so none of these need to preserve compatibility: pick the best model and break what it takes.</p> <h3>The default deadline applies to payments that should never lapse</h3> <p><code>PaymentManager::create()</code> stamps a deadline on every payment unless the caller passes a non-positive <code>$ttl</code>, and no caller passes one. That includes the bundled <code>manual</code> gateway, whose documented purpose is cash, cheque and bank transfer settled by an operator out of band, potentially days later. Those are recorded expired 30 minutes after creation. The module own <code>PaymentExpiryTest</code> asserts this against gateway <code>manual</code>, so the test suite currently locks the behavior in.</p> <p>Options: make the deadline opt-in at the call site; let the gateway plugin declare its own default, so <code>ManualGateway</code> returns none and a redirect gateway returns a window matching its checkout session; or keep the blanket default and exempt gateways that start no round-trip. The gateway-declared option looks best, since the gateway is what knows the shape of its checkout.</p> <h3>Expiry does not reconcile with the provider</h3> <p><code>PaymentManager::expire()</code> records local state only; it never calls the gateway. So a local expiry is not evidence about what the provider did, and the ordering between a local expiry and a late provider outcome needs review before expiry is relied on. To decide: whether the reaper should cancel at the gateway, whether a refused transition should log rather than pass silently (<code>capture()</code> currently returns quietly for any state it does not handle, unlike <code>refund()</code> which logs), and what the reconciliation path is.</p> <h3>Handoff route session handling</h3> <p>Two items to review together, both concerning the route added in <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/kessai/-/work_items/3611852" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/kessai/-/work_items/3611852</a></span>.</p> <ul> <li>The route calls <code>initiate()</code> on each visit while the payment is pending, and a redirect gateway records a fresh hosted-checkout session each time, overwriting the previous one. The return path then resolves against the stored session only, so the interaction between repeat visits and the session the payer actually used needs tightening. The provider already offers the pieces for this: <code>allowedNumberOfPaymentAttempts</code> and <code>sessionTimeout</code> exist so one session can carry several attempts rather than minting a session per click, and <code>RETURNMAC</code> identifies which session a return belongs to. kessai sets the first two and ignores the third. Keeping one session per payment, and reusing it while it is open, looks like the better model.</li> <li>The per-payment handoff token is derived from the payment id alone. The route now refuses a handoff past the payment deadline, which bounds it, but the token itself is still a bearer value that travels in the query string and so reaches access logs and browser history. Worth deciding whether that is acceptable or whether it should be scoped further.</li> </ul> <h3>Smaller items in the same area</h3> <ul> <li><code>kessai.settings:default_payment_ttl</code> has no admin form and no schema constraints, so a negative or absurd value is accepted silently.</li> <li>The reaper caps each run at 200 payments and logs nothing about the remainder.</li> <li><code>expires</code> is not exposed in the payments view, so an operator cannot see or sort by the deadline.</li> <li><code>PaymentEvents::INITIATED</code> is not recorded in the audit trail. It is not a money outcome, so this is a question rather than a gap.</li> </ul>