>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3614434. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !38 >>> <p>A payment's <code>kind</code> is declared here as two fixed values, <code>KIND_PAYMENT</code> and <code>KIND_DEPOSIT</code>. Both are a consumer's words. A booking module holds a deposit against damage, a rental shop against a returned item, a shop selling downloads holds none; none of that is kessai's business. Let the caller pass the string it wants. The field's own description already says "a consumer-defined kind", so this is aligning the code with what it claims.</p> <p>Nothing here interprets the value, which is what makes it cheap. It is a plain string base field, part of an index, set on create and read back with <code>getKind()</code>. It reaches <code>lockName()</code> and <code>existingPayment()</code>, where it keeps "the charge for X" apart from "another charge for X" when locking and deduplicating. Nothing displays it and nothing branches on it, so kessai needs a value it can compare, not one it understands.</p> <p><b>The default is the part that matters.</b> <code>chargeToken()</code> defaults the kind to <code>KIND_PAYMENT</code> and <code>authorizeToken()</code> to <code>KIND_DEPOSIT</code>, and that silent default has already caused a bug in a consumer: yoyaku charges a no-show fee through <code>chargeToken()</code> without naming a kind, so the fee is created wearing the checkout payment's identity and a refund of the fee reads as a refund of the booking. With no vocabulary to inherit, the argument should be required: whoever creates a payment says what it is for, and that class of bug cannot recur.</p> <p><b>What to change</b></p> <ul> <li><code>src/PaymentInterface.php</code>: remove <code>KIND_PAYMENT</code> and <code>KIND_DEPOSIT</code>.</li> <li><code>src/PaymentManagerInterface.php</code> and <code>src/PaymentManager.php</code>: make <code>$kind</code> a required argument of <code>create()</code>, <code>authorizeToken()</code> and <code>chargeToken()</code>, and say in the docblocks that the value is the caller's own and is only ever compared.</li> <li><code>src/Entity/Payment.php</code>: drop <code>setDefaultValue()</code> on the field. A required field with a default lets a caller omit the value at storage level too, which is the same trap one layer down. Keep <code>max_length</code> 64 and add a machine-name constraint (lowercase, digits, underscores), since the value lands in lock names and queries.</li> <li>Tests: seven files use the constants, including <code>WorldlineFinalizerTest</code>, which sets a deposit kind explicitly. They can pass their own literals.</li> </ul> <p>Nothing inside kessai outside tests relies on the defaults: the gateway plugins' <code>chargeToken(PaymentInterface $payment)</code> is a different method and unaffected.</p> <p><b>Out of scope:</b> the consumers. Yoyaku will name its own payments (the booking, the guarantee, the no-show fee) in its issues 3614440 and 3614433. This one is only about kessai holding no opinion.</p> <p>Both projects are pre-1.0 and reinstall-only, so stored rows keeping the old values are not migrated; a site with a live authorized guarantee would stop finding it under a new value, which is a release-note line. By the usual ordering a consumer's CI cannot go green until this lands and reaches <code>1.x-dev</code>.</p>