>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3615857. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !47 >>> <p>Measured against a pre-production account on 2026-08-10: two fresh 150,00 authorizations taken through the hosted checkout, plus one transaction from 2026-07-23 kept to test age. <strong>Every assumption the movement records rest on held, so no behaviour changes.</strong> The unmeasured notes in <code>docs/worldline.md</code> are replaced with what was observed.</p> <h3>The four behaviours the movement records rest on</h3> <ul> <li><strong>isFinal false keeps the authorization open.</strong> 30,00 claimed off 150,00 left it claimable and a second claim of 20,00 succeeded. Each capture carries its own provider id.</li> <li><strong>isFinal true closes it, releasing the remainder.</strong> 40,00 claimed off 150,00 as final, then a further capture of 10,00 sent straight to the platform, bypassing the engine guard because a local refusal proves nothing about the provider: refused, 50001127 ACTION_NOT_ALLOWED_ON_TRANSACTION.</li> <li><strong>A partial reversal</strong> leaves the rest claimable and the last of it was then claimed. <strong>No reference is issued per reversal</strong>, as documented.</li> <li><strong>A partial refund</strong> carries its own provider id, and a second exhausting the balance reached refunded. Refunds were accepted against captures that had not yet settled.</li> </ul> <h3>A hold expires; the mandate under it does not</h3> <p>The result with the most consequence, and it is one transaction answering two questions at the same moment, 17 days after it was authorized:</p> <ul> <li><code>capturePayment</code>: <strong>refused</strong>, 50001127</li> <li><code>subsequentPayment</code>, anchoring a new authorization on it: <strong>accepted</strong></li> </ul> <p>The new authorization was read back from the platform to confirm it was real rather than a bare 200: PENDING_CAPTURE, authorized, 5,00. So a booking taken long in advance is workable, but by authorizing late against the original checkout rather than sitting on an early hold. Nothing observed suggests a limit on how much later; 17 days was the oldest transaction to hand, not a ceiling that was found.</p> <p>Nothing in the answer says a hold has died: it reported PENDING_CAPTURE with isAuthorized true moments before refusing the capture. The only way to learn a hold has lapsed is to try to take the money.</p> <h3>An anchor is refused only once the platform has voided it</h3> <p>Not because of its age, and not because of the state kessai records:</p> <ul> <li>PENDING_CAPTURE and authorized, <strong>17 days old</strong>: accepted</li> <li>PENDING_CAPTURE and authorized, same day: accepted</li> <li>captured, same day: accepted</li> <li>refunded, same day: accepted</li> <li>CANCELLED and UNSUCCESSFUL, not authorized: <strong>refused</strong>, 20001101</li> </ul> <p>The 17-day row is what rules age out. And kessai's own state is a poor proxy for the platform's: a reversal settles asynchronously like a capture, so a payment cancelled here still read PENDING_CAPTURE minutes later and anchored without complaint. That is why <code>chainAnchorReference()</code> is right not to filter on state; the only reliable test is the request itself.</p> <p>One narrow consequence is left unfixed and written down: the anchor query takes the newest authenticated checkout, so a subject whose newest one was genuinely voided loses the chain even when an older live one would serve. Doing better means asking the platform rather than guessing locally.</p> <h3>One more, measured throughout</h3> <p><strong>The parent payment status is not a settlement indicator.</strong> It reported PENDING_CAPTURE after each partial capture, after the final capture, and after the platform itself refused to add anything more to that authorization. Captures and reversals settle asynchronously and the parent lags, so what is still held is the engine's own arithmetic, never the provider's status field.</p>