## Problem/Motivation A site cannot hold two accounts at the same provider, so it cannot keep a Worldline test account beside its production one and switch between them. `kessai_worldline` reads a single config object, `kessai_worldline.settings`, holding one `api.url`, one `api.pspid` and one key, with the secret supplied by a single `kessai_worldline.api_secret` override in `settings.php`. There is one slot, so switching means overwriting it, and the account being replaced has nowhere to live. **The worse half is what it does to payments already taken.** A payment stores a *plugin id* in its `gateway` column, and `PaymentEngine::loadGateway()` resolves that id against whatever the single settings object currently says. After a switch, every payment taken against the old account resolves to the new one: a capture, a refund, or the expiry sweep asking the provider what became of it, all go to an account that never saw that transaction and will answer that it does not know it. Those rows are not recoverable by editing configuration back, because nothing on the payment records which account took the money. The same shape blocks anything else that needs two accounts at once: two legal entities on one site, a second currency handled by a separate contract, a gradual migration from one merchant account to another. ## Proposed resolution Make the thing a payment names a **configured instance of a gateway plugin** rather than the plugin itself, the way pdv addresses its consumers. - A config entity per instance, naming a plugin id and carrying that instance's own configuration: endpoint, PSPID, checkout settings. - `PaymentInterface::getGateway()` returns an instance id. The base field is already 64 characters, so the column does not move. - `PaymentEngine::loadGateway()` resolves instance -> plugin id plus that instance's configuration, and builds the plugin **with** it. The memo it keeps today is per plugin id and becomes per instance; that memo exists because the expiry sweep asks up to `reconcile_batch` payments about their provider on one cron run, so keeping it per instance rather than losing it is the difference between one plugin build and a build per payment. - `create()`, `authorizeToken()` and `chargeToken()` take an instance id. The reuse question, which is already subject plus kind plus gateway plus currency, then keys on the instance, which is more correct than today: two accounts really are two payments. - Per-instance secrets, held as `key` entities the instance names. No `settings.php` override survives: a site with two accounts has two secrets and an override has one slot. - **One webhook endpoint, several signing keys.** The endpoint is one URL for the whole site, and each account signs with its own key. Verifying against a single account's secret would reject every notification from the others, so the verifier holds one key store over every enabled instance and lets the key id in the notification pick. - `hook_kessai_gateway_info_alter()` keeps altering plugin definitions; instances are configuration and are altered as configuration. ## Remaining tasks Before 1.0, because the **meaning** of the `gateway` column is public API. Doing it afterwards is a data migration over live payments rather than a rename, and every consumer that passes a gateway to `create()` is affected. No update path: pre-1.0 alpha, so a site already running kessai sets its accounts up by hand. This borrows pdv's addressing shape, not its consumer concept: a gateway instance is which account the money goes to, where [#3621925](https://git.drupalcode.org/project/kessai/-/work_items/3621925)'s consumer is who is asking. A remote consumer would be constrained to the instances it may name, which is authorization and belongs there. ## User interface changes An admin listing and form for gateway instances, and the gateway select on a consumer's own settings (orchestra's payment step, for one) becomes a choice of instance. ## API changes `create()`, `authorizeToken()` and `chargeToken()` take an instance id where they take a plugin id today, and `PaymentInterface::getGateway()` answers one. ## Data model changes A new config entity type. The `gateway` base field keeps its shape and changes its meaning. AI-Generated: Yes (Claude Code was used to help draft this issue summary. The current behaviour described here was read from the code rather than assumed.)