>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3614333. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !32 >>> <p>Worldline documents the idempotence key as having a <strong>maximum length of 40 characters</strong>, ASCII only. See <a href="https://docs.direct.worldline-solutions.com/en/integration/api-developer-guide/idempotent-requests">Idempotent requests</a>.</p> <p><code>PaymentOperationKey::for()</code> returns <code>Crypt::hmacBase64()</code>, which is <strong>43 characters</strong>. Measured, not guessed: capture, cancel, refund and the undo-checkout variants all come out at 43. So every key <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/kessai/-/work_items/3614235" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/kessai/-/work_items/3614235</a></span> sends is three characters over the documented limit, on all of capture, cancel, refund and the card-on-file charge.</p> <p>Whether Worldline rejects the request, truncates the key or ignores the header is not established. None of those is the intended behaviour, and two of them mean the protection that issue added does not exist.</p> <h3>How this got missed, which is the more useful part</h3> <p><span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/kessai/-/work_items/3614235" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/kessai/-/work_items/3614235</a></span> recorded key length as unverified. It was then "verified" against a pre-production account by sending keys of 32, 64, 128, 200 and 256 characters to <code>CreateHostedCheckout</code>, all of which were accepted, and the conclusion drawn was that length is not a concern.</p> <p>That test could not fail. <code>CreateHostedCheckout</code> is <strong>not</strong> one of the idempotent methods, so the header is never processed and the length never validated. The supported list is CreatePayment, CancelPayment, RefundPayment, CapturePayment, CompletePayment, CreatePayout and SubsequentPayment.</p> <p>The same probe run had already shown the endpoint was not idempotent, since the same key with different amounts produced two different checkouts. The right conclusion at that point was that the length result was worthless, not that length was fine.</p> <h3>Fix</h3> <p>Shorten the key to at most 40 characters. Truncating the base64 HMAC to 40 leaves 240 bits, which is far more than enough to keep two operations on two payments apart, and keeps it ASCII.</p> <p>A test should pin the length and the character set, so the constraint is enforced by something other than a comment.</p> <h3>Other pre-production measurements, for the record</h3> <p>These were measured properly and are going into the Worldline documentation page in the same change:</p> <ul> <li><strong>sessionTimeout is in minutes.</strong> A session created with 1 was IN_PROGRESS immediately and lapsed within seventy-five seconds, while a 5 created beside it was still open.</li> <li><strong>The minimum is one minute.</strong> Zero is refused with error 50001111 naming the field. The gateway refusing to open a session with under a minute left matches exactly.</li> <li><strong>There is no maximum at 180.</strong> Both 181 and 1440 were accepted.</li> <li><strong>The redirect URL survives repeat visits.</strong> Three fetches returned HTTP 200 with a byte-identical form, which is what makes one session per payment safe.</li> <li><strong>An expired session reports CANCELLED_BY_CONSUMER</strong>, with no distinct expiry status, so nothing reading the hosted-checkout status can tell a lapsed session from an abandoned one.</li> <li><strong>Retention is at least 24 hours</strong> and an in-flight duplicate answers HTTP 409, which is what the SDK surfaces as IdempotenceException and this module already treats as retryable.</li> </ul>