>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3619761. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !56 >>> <p>A movement (claim, refund or reversal) holds a required entity reference to its payment. Deleting the payment does not remove them: the module implements no delete hook, no <code class="language-php">preDelete()</code> and no <code class="language-php">postDelete()</code>, and Drupal does not cascade through an entity reference. The rows survive pointing at a target that no longer exists, which also puts them in permanent breach of their own <code class="language-php">setRequired(TRUE)</code> constraint.</p> <h3>Why this is not only an integrity question</h3> <p>A movement carries an amount, a currency, a kind, a state and a gateway reference. The gateway reference is re-linkable at the payment provider by design, so these rows are pseudonymous data rather than anonymous data, and storage limitation applies to them. A movement that outlives its payment has no owner, no retention period and nothing that will ever visit it again, so it is kept indefinitely by omission rather than by decision.</p> <p>That makes it reachable in ordinary use rather than theoretical. Any consumer that deletes payments as part of its own data retention purge produces these rows on every sweep, unattended, and the module gives it no way to avoid doing so: the movements are kessai's own entities and a consumer should not have to know they exist.</p> <h3>What should happen</h3> <p>Deleting a payment should delete the movements that hang off it, in the same storage transaction, so a payment and its movements are removed all or nothing.</p> <p>The durable record does not depend on those rows. <code class="language-php">kessai_audit_trail</code> already records the movement that caused each lifecycle event, its entity type, its amount, its kind, and for a claim whether it was final, alongside the payment totals, and it writes them to the permanent bucket. The operational rows are the working state, not the record.</p> <p>The audit submodule is optional and its recording is deliberately best effort, so the cascade is written knowing that on a site without it a delete leaves nothing behind, which is what a site that installed no audit log asked for.</p> <h3>The same reasoning applies to what the chain keeps</h3> <p>The entry recorded the stored card token in the permanent context, justified in a comment as an opaque, non-PII payment identifier because no name or email is recorded. Absence of a name is not what makes an identifier non-personal: a card alias resolves back to a payment instrument at the provider. The token moves to the transient context, and the movement's own <code class="language-php">reference</code> is recorded there beside it rather than in the permanent one, which is also the gap that left one specific refund unreconcilable against the provider from the chain alone.</p> <p>Both contexts are on a clock, and the difference is which one. The permanent context rides the chain's long ladder and is gone when the archive file is unlinked at <code class="language-php">file_purge_after</code>, two years by default. The transient context is what <code class="language-php">transient_purge_after</code> clears, a separate and deliberately shorter clock whose stated purpose is that raw personal data does not linger, and which is disabled out of the box. So this shortens nothing on its own: it puts these two keys where a site that sets a retention period can reach them, which in the permanent context it could not.</p> <h3>Scope</h3> <p>No update path is needed. The module is pre-1.0 and reinstall-only, so a site carrying rows orphaned by the current behavior clears them on reinstall.</p> <p>AI-Generated: Yes (Claude Code was used to find this, to verify it against a running site, to help draft this issue summary and to write the code and tests on the merge request. I reviewed and ran the work myself before posting it.)</p>