## Problem/Motivation A deferred hold and a later charge are made as unscheduled merchant-initiated *subsequent payments*, anchored on the subject's own authenticated hosted checkout. `WorldlineGateway::findChainAnchorReference()` looks that checkout up with: ```php ->condition('gateway', $this->getPluginId()) ``` `$this->getPluginId()` is the **plugin** id, `worldline`. A payment's `gateway` column holds the **payment account** id, which since #3621924 is a machine name the site owner chose. The two coincide only for the account this module ships, because its id happens to be spelled the same as the plugin. So on a site whose Worldline account is called anything else -- and the whole point of #3621924 is that a site may hold a test account beside its production one -- the anchor lookup matches nothing. What happens then is not a degraded answer, it is a dead feature. The hosted checkout deliberately requests no tokenization, so a payment carries no stored card to fall back to. Measured in a kernel probe against 1.x, with an account `worldline_test` and an authenticated, captured checkout on it: ``` anchored on: NULL chargeToken() threw: GatewayDeclinedException: Worldline SALE was not accepted for payment 2. ``` `settleOnGateway()` records that payment **failed**. Every deferred hold and every later charge on such an account fails, and the log line blames a missing stored card rather than the lookup. On a site holding two Worldline accounts where one *is* called `worldline`, the same condition is wrong the other way: a hold on the second account is anchored on a transaction belonging to the first, which is a different PSPID and a different contract. That is a request the platform refuses, and one it should never have been sent. The engine already settled this question for the sibling lookup. `PaymentEngine::getLatestToken()` scopes a subject's stored token to one account, with a docblock saying why: *"A token is an alias the provider minted for one merchant account and honors only there, so the account has to be part of the question."* A chain anchor is the same kind of thing -- a transaction id that means something at one merchant and nothing at another -- and it was left keyed on the plugin. Nothing caught it because every fixture in `WorldlineGatewayTest` creates its payments with `'gateway' => 'worldline'`, which is both the account id and the plugin id, so the wrong condition and the right one agree. ## Proposed resolution Scope the anchor lookup to the account the payment being charged was taken against, `$payment->getGateway()`, which is what `getLatestToken()` already does for the token it falls back to. That answers both halves at once: an account with a name of its own finds its own checkouts, and neither of a site's two accounts reaches into the other's. `docs/worldline.md` gains the sentence the code was missing -- an anchor belongs to one account, as a stored card does. ## Remaining tasks - [x] Kernel test: a later charge on an account whose id is not the plugin id anchors on that account's own checkout. This is the one that fails against 1.x. - [x] Kernel test: a checkout taken against another account at the same provider is not an anchor for this one. It fails against 1.x (which anchors one account's charge on another's transaction) and against a fix that overshoots into finding any checkout at all, which its sibling cannot see. ## User interface changes None. 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.)