## Problem One contract, two implementations, and only one of them keeps a promise the contract states in so many words. `PaymentClientInterface::deleteStoredTokens()` ends: **"One payment cannot stop the batch."** The engine holds it deliberately and says why at each of the three branches where it could have given up: a payment this site does not store, a payment whose gateway module has been uninstalled, and a gateway with no token support are each logged and skipped, "because this runs over a list, and stopping on one payment strands the tokens of every payment behind it". `RemotePaymentClient::deleteStoredTokens()` opens with `groupByRemote()`, which calls `findRemoteFor()` per payment, which throws `\InvalidArgumentException` for a payment naming an account this site reaches through no enabled remote. So the first such payment ends the call before any host is asked, and **not one token is forgotten anywhere**, including at the remotes this site can still reach. The unroutable payment is ordinary rather than exotic: `findRemoteByAccount()` answers only enabled remotes, so disabling a remote — which is how a client site retires a host — is enough to produce one. A consumer holding two remotes that passes a payer's payments to `deleteStoredTokens()`, which is what a "forget my card" action does, gets an exception and leaves the payer's card on file at the provider it could still have reached. The engine, handed the same list, forgets every token it can and warns about the one it cannot. `deletePayments()` is not the same case and is correct as it stands: the contract documents `@throws \InvalidArgumentException` for a payment this implementation did not make, and the engine narrows the whole list before deleting any of it, so both sides refuse the batch together. ## What shipped The payment that names no enabled remote is skipped, said in the log the way the engine says it at each of its own three branches, and the rest of the batch goes on. The skip is its own method rather than a flag on the grouping, because the two callers want opposite things and the difference is worth stating once. `deletePayments()` keeps refusing the whole list, which the contract declares and the engine does too: deleting is a deliberate act on records of money and a caller must not be told it happened when part of it did not. Forgetting a token is the other way round, since what is left behind by giving up is a card on file at a provider. The client had no logger, so it takes `logger.channel.kessai_client`, the channel its notice route already writes to. `docs/remote.md` gained the rule beside the routing it belongs to. ## Tests | Test | Against the unfixed code | |---|---| | `AcrossTheWireTest::testOnePaymentNothingCanRouteDoesNotStrandTheBatch` | `InvalidArgumentException: This payment names no account this site reaches` | In the two-site test rather than beside the client, because what has to be true is that the reachable host really was asked and really did forget: the real client builds the request, the real controller reads it and the real engine clears the token. AI-Generated: Yes (Claude Code was used 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.)