## Problem Three faults, one subject: where a payer taken on behalf of another site belongs, and whether they ever reach it. ### Two of the three doors never ask `OnwardUrl` owns the rule and names who asks it: > Every route that sends a payer onward asks it: the engine's handoff route, and the return and payment pages gateways provide. Its second argument is the origins that payer may be sent to. Three doors send a payer onward. One passes them: | Door | What it asks | | --- | --- | | `WorldlineReturnController` | `OnwardUrl::resolve($payment->getReturnUrl(), $origins)` | | `PaymentHandoffController` | `OnwardUrl::resolve($return)` | | `SimulatorCheckoutForm` | `OnwardUrl::resolve((string) $form_state->getValue('return'))` | With no origins, an external address is compared against an empty list, `resolve()` answers `NULL`, and the caller falls back to `Url::fromRoute('<front>')` — *this* site's front page, which a payer who came from somewhere else has never seen. ### No door could carry them there anyway Deciding a payer may be sent to another site is not sending them. Core replaces a redirect leaving this site with a **400** and logs that a `TrustedRedirectResponse` was wanted, and all three doors answered with a plain `RedirectResponse` (the simulator through `setRedirectUrl()`, which `FormSubmitter` turns into one). `OnwardUrl` states this rule about itself and is caught by it: > core refuses a non-local redirect from a plain RedirectResponse and answers 400, which strands the payer on an error page in the middle of paying. So the address a payment vouched for reached its payer as an error page, having already paid. Worldline's return route has had this since origins landed; the other two would have arrived with it. ### And a handoff link can take the address off the payment The rule is held where an onward URL is read and where a consumer writes one through the API. The handoff route writes one too: it hands the raw `kessai_return` query argument to `openPaymentSession()`, which records it over the stored one. That argument is not signed — the token covers the payment and its deadline — and the link carrying it reaches browser history, access logs and mail by design. So anyone holding it can replace the address the payment was created with, which a consumer named in code and had checked against the sites its payer may be returned to. Nothing follows it afterwards, but nothing follows the real one either: it is gone. ## What it costs `docs/remote.md` states the promise: "A payer taken for another site belongs back on that site when the provider is done." Every step below is an ordinary operation: 1. A consumer on `shop.example` calls `create()` with `returnUrl: 'https://shop.example/thanks'`. `ConsumerScope::assertReturnUrl()` accepts it, because the site owner registered that origin against the consumer. 2. The consumer mints a handoff link and sends its payer there. 3. The payer pays and comes home through the gateway's return route, which passes the origins — and meets the 400, because the response never said the address had been allowed. 4. Or the payer opens the handoff link again, which `PaymentEvents::INITIATED` documents as expected: "a second click, the browser's back button, a re-sent link". The payment is no longer `PENDING`, so the route answers with the front page of the engine's host. 5. Or someone edits `kessai_return` on that link once while the payment is pending, and the shop's own address is overwritten for good. The same fallback is taken on three further branches of the handoff: a payment past its deadline, a `GatewayException`, and a gateway that starts no round-trip at all. The simulator's door is worse, because it is reached *after* paying rather than instead of it: `redirectToReturnUrl()` runs on every approve and every decline. ## Proposed - Both doors ask `AllowedOriginsInterface::forPayment()` and pass what it answers, as Worldline's return route already does. Resolved on the way out rather than up front, because a handoff that reaches the provider never uses the answer, and read once per request rather than once per address on the simulator's page. - `OnwardUrl::redirect()` answers with the response that carries the payer: trusted and uncacheable for an address on another site, and the plain redirect a payment this site took for itself always met. One owner, because a rule each route restates is a rule one of them gets wrong. - `PaymentEngine::recordReturnUrl()` refuses an address the payer may not be sent to, beside the length rule already there and for the reason the contract already gives for it: an onward URL that cannot be followed is not recorded, the run says so, and what the payment holds is kept. Nothing changes on a site without `kessai_server`: `AllowedOrigins` answers `[]`, every external address stays refused, and every redirect is the one it always was. ## Naming `returnOrigins` read two ways — "origins of the return" and "return the origins" — and `origin` points backwards in ordinary use, at where a request came from, while this decides where a payer goes. It is now **`allowedOrigins`**, which is what core calls this kind of list in `cors.config`, and which says that empty is its ordinary state. `Return` is dropped rather than kept, because it named one of the list's uses rather than the list: `ConsumerSite` already reads it for something that is not a return at all, deriving where to post a consumer's notices when exactly one origin is registered. The stored field moves with it, to `kessai_allowed_origins`, outright rather than kept alive by an update hook. AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the change and its tests. Each behavioural fix has a test that was run against the unpatched code and seen to fail, and seen to pass with the change.)