DefaultSettlementSubscriber::onCaptured() confirms every held line of the order the captured payment names as its subject, without looking at the payment's kind. A booking order carries more than the checkout payment: a charge-mode security deposit is its own KIND_DEPOSIT payment, and the no-show fee is charged against the stored card later. Capturing either confirms the order's held lines, even when the checkout payment itself never happened.
OrderLockSubscriber already does this correctly: it returns early unless the payment's kind is KIND_PAYMENT, precisely so that a deposit does not drive the checkout lock. The settlement subscriber needs the same scoping on the confirmation decision.
onFailed() and onRefunded() read the same way, and they need a decision rather than a copy of the same answer. A failed deposit authorization arguably should release the lines, since the guarantee the booking was accepted on is gone; a refunded deposit is not obviously an order cancellation. Worth settling here and recording in the class docblock, so the next reader can see which kinds each path answers for.
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #4
mably commentedComment #6
mably commentedMerged to 1.x as
366d4c7.The issue turned out to hold two bugs rather than one, and the second is the worse: refunding a charge-mode security deposit cancelled the order it guaranteed, and refunding a deposit after the event is how a deposit ends normally. Capture and refund now answer for the checkout payment alone. Failure deliberately still answers for either kind, since a booking accepted on the strength of a guarantee has no basis once the guarantee is refused.
The no-show fee case in the title is not fixed here, and cannot be fixed by a payment kind: the fee is charged through
chargeToken(), which stamps the checkout payment's kind by default. Its capture is harmless, since by then no line is still held, but its refund would read as an order cancellation. Follow-up in #3614433: Yoyaku reads a payment's meaning off a kessai constant instead of labelling its own payments, which is now about yoyaku labelling its own payments rather than borrowing a kessai constant.The subscriber had no test coverage at all before this; it now has five cases, verified against the unscoped code.