Four doors, one rule about where a payer goes home. Two of them read a different half of where home is, one records an address no door will follow, and the guard all four ask raises on the payer's own path. ## The handoff route reads the link, never the payment `PaymentHandoffController::redirectOnward()` resolves only `$request->query->get(PaymentHandoff::RETURN_ARG)`. Both sibling doors can reach the address the payment recorded and this one cannot: `WorldlineReturnController::redirectOnward()` reads `$payment->getReturnUrl()` and reads nothing else, and `SimulatorCheckoutForm` reaches it whenever the query argument is absent. It reaches it the wrong way, by folding the two into one value before checking either, which is a defect of its own and is the last section below; what it is evidence of here is that the handoff route is the one door of the three that cannot reach the record at all. The contract already says which it should be. `PaymentInterface::getHandoffUrl()` documents its own argument as "Where to send the payer once the payment finishes, or NULL to **leave any onward URL already recorded in place**", and `Payment::getHandoffUrl()` puts no return argument on the link when none is passed. `docs/remote.md` names the handoff route as one of the three routes that send a payer home. So all four of the route's onward branches - a payment already resolved, one past its deadline, a gateway that could not start, and a gateway that starts no round-trip at all - send the payer to this site's front page whenever the link carries no address of its own. A consumer that named `returnUrl` on the request and then rendered `$payment->getHandoffUrl()`, which is the call the contract documents, mints exactly such a link. Reached by the most ordinary thing a payer does with a handoff link, which is open it twice; `PaymentEvents::INITIATED` documents that as expected. On the bundled `ManualGateway`, which opens no session, it is every handoff. Where the engine answers another host, the front page is the engine's and not the shop's. None of the six onward cases in `PaymentHandoffControllerTest` covers it: every one hands the address in the query string. ## And creating a payment records an address nothing will follow `PaymentEngine::createPayment()` checks the length of `$request->returnUrl` and nothing else. `recordReturnUrl()` checks the length *and* asks `OnwardUrl::resolve()` with the payment's own origins, and `createPayment()` says in its own comment why a bad value is refused rather than dropped: "a consumer named it in code before any money was asked for, and a payment that silently cannot send its payer home is worse than a request that says so." That is held for the length and not for the address. On a site that settles its own payments `AllowedOrigins` answers the empty list, so every external address is refused at redirect time. A consumer naming `returnUrl: 'https://shop.example/thanks'` is accepted, the payment records it, and every payer lands on the front page for ever with nothing said at any point. `kessai_server` refuses the same value at its own door, so only the consumer on the same site meets this. ## The guard they all ask raises on the payer's critical path `OnwardUrl::resolve()` documents itself as refusing "a value Url cannot parse rather than allowing it to throw on the payer's critical path". Its `try` only ever covered the internal branch. `Origin::getOrigin()` finds the origin whatever is in front of the value, so `"\thttps://shop.example/x"` is allowed on a site that registered `https://shop.example`, and `Url::fromUri()` then raises `\InvalidArgumentException` on the leading tab. Every caller is on a payer's path: `PaymentHandoffController::redirectOnward()` and `WorldlineReturnController::redirectOnward()` answer the payer a 500 in the middle of paying, and `PaymentEngine::recordReturnUrl()` takes the handoff request down with it. Reached with `?kessai_return=%09https://shop.example/x` on a link anyone holding it can edit. The same happens for a leading newline, carriage return, vertical tab or NUL. A line break *behind* the address is refused by nothing at all: it resolves, it is recorded, and it reaches the `Location` header, which PHP will not send once it holds one. The payer is answered a redirect naming nowhere. ## And the simulator's page picks before it checks `SimulatorCheckoutForm::buildForm()` carries `query->get(RETURN_ARG) ?: $payment->getReturnUrl() ?: ''` as one value and only then asks `OnwardUrl` whether it is usable. So an address on the link takes the record's place before either has been checked: a payer whose link names somewhere they may not go lands on this host's front page while their payment holds an address that was named in code and vouched for when it was created. That is the same defect as the first section's, at the other door that takes a link address, and it survives the fix to the handoff route. ## Proposed resolution - `PaymentHandoffController::redirectOnward()` prefers the address on the link and falls back to the one the payment recorded, so a link that carries none, and a link that carries one this payer may not be sent to, both reach the checked address rather than the front page. - `PaymentEngine::createPayment()` refuses an onward address the payment's own origins would refuse, as `recordReturnUrl()` does, rather than recording one no route will follow. - `OnwardUrl::resolve()` refuses a value carrying a control character before anything reads it, and its `catch` covers the external branch as well as the internal one. - `SimulatorCheckoutForm` carries only the link's address and reads the record where the payer is sent, in that order, so the page holds the same rule as the handoff route. - Tests in both directions on each half. 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.)