Feature/pre 3440 multi shop configuration

[adumont-payplug]

Description

Multi-shop support: a Sylius installation can now hold several PayPlug gateway configurations of the same type, each connected to its own PayPlug account and scoped to its own set of channels.

Until now the plugin assumed one PayPlug account per installation. AbstractGatewayConfigurationType refused the creation of a second gateway config for a factory name that already existed, and everything downstream — the API client, the /account payload, the UPC configuration repository — resolved credentials by factory name alone. That is fine with one account, and silently wrong with several: a name-based lookup returns an arbitrary config, so a request for channel A can be signed with channel B's credentials.

This PR replaces the installation-wide uniqueness rule with a per-channel one, then threads the payment method (rather than the factory name) through every place that needs to know which account it is talking to, and gives the admin the two things that become necessary once several accounts coexist: seeing which account a gateway is connected to, and disconnecting one of them without touching the others.

Motivation: merchants running several shops on one Sylius installation need one PayPlug account per channel.

Related issue(s): PRE-3440 — includes PRE-3628, PRE-3629, PRE-3631, PRE-3632, PRE-3682, PRE-3683, PRE-3685.

---

PRE-3628 — per-channel gateway uniqueness

The rule is now: a channel may be linked to at most one enabled gateway config per factory type. Two CB gateways may coexist and both be enabled as long as their channel sets are disjoint; different factory types never conflict.

• New Checker/GatewayChannelConflictChecker — matches on channel code rather than object identity, ignores disabled gateways on both sides, and handles the not-yet-persisted subject (no id ⇒ can never match a rival).
• New Gateway/Form/Extension/PaymentMethodTypeExtension — carries both the conflict rule and the base-currency rule on the root payment-method form. That move is the crux: Sylius adds channels from CoreBundle's own type extension, i.e. after gatewayConfig, so a listener inside gatewayConfig.config runs before enabled and channels are submitted and can only ever see persisted data. Root POST_SUBMIT is the first point where the submitted channel set, the submitted enabled flag and the mapped gateway config all exist.
• AbstractGatewayConfigurationType loses its PRE_SUBMIT listener, the canBeCreated() / checkCreationRequirements() pair and two constructor dependencies; the per-gateway currency policy stays where it belongs (one hook per gateway type) and is read back by the extension.
• The CB base-currency gate now reads the mapped config through PayPlugGatewayFactory::resolveDisplayMode() instead of the unmapped DISPLAY_MODE_FIELD form key, which never reaches the persisted config.
• New PaymentMethodRepository::findEnabledByGatewayName().
• Translation form.only_one_gateway_allowed → form.gateway_channel_conflict (en/fr/it).

PRE-3629 — claimed channels are unselectable in the picker

POST_SET_DATA on the root form replaces the channels child with a copy carrying a choice_attr closure, so a channel already held by another enabled gateway of the same factory renders disabled with a title naming the claiming payment method.

Channels the edited payment method already holds are deliberately left selectable: browsers do not submit disabled checkboxes, so disabling a checked one would silently drop that channel on save. Pre-existing overlaps are reported by the submit-time rule instead. Both answers come from the same claims() lookup, which is what keeps the picker and the validator in step.

PRE-3682 / PRE-3683 / PRE-3685 — scoping credentials to the payment method

• PayPlugApiClientFactoryInterface::create(string $factoryName) is removed from the interface. createForPaymentMethod() is now the only way application code can obtain a client — the compiler, not review, is the guard against reintroducing a channel-ambiguous lookup. The concrete create() survives as @internal purely for the client.xml service-factory definitions (the remaining open half of PRE-3682, tracked separately).
• SupportedMethodsProvider fetches /account per gateway config, memoized by persisted id (falling back to spl_object_id for unflushed configs) instead of once per call — previously the first method's account governed every later one in the list. The payment_methods sub-key is resolved from the config the payload was fetched for.
• New Upc/ScopedConfigurationRepositoryInterface — UPC's IConfigurationRepository takes no context on any method (it was written for one account per installation). Rather than widen a shared contract that other plugins consume, the scope is carried Sylius-side by a sub-interface with withGatewayConfig() / forPaymentMethod() withers: the repository is a shared service, and a mutable scope would leak across requests — IPN and background token refresh being exactly where that would go unnoticed.
• UnifiedApiPaymentCreatorInterface::createPayment(), OperationStatusFetcherInterface::getOperation(), the UHF command handlers, HostedFieldsWebhookNotificationHandler, IpnAction, OneClickAction, IntegratedPaymentController, PaymentStateResolver, CaptureAuthorizedPaymentProcessor and the Oney/permission validators all take or resolve the payment method now.

PRE-3631 — the connected account, per gateway

New Auth/IdTokenEmailExtractor reads the email claim out of the OAuth id_token at callback time and UnifiedAuthenticationController writes it to the gateway config as account_email; a read-only connected_account.html.twig renders it on the update screen of all seven gateways.

Worth knowing: /account carries no email (verified live — the payload is id, company_ref, country, object, is_live, configuration, permissions, payment_methods), and neither does the client-credentials token used for background calls. The interactive authorization-code exchange is the only place the address exists, which is why it is captured at login rather than fetched on demand — same approach as the PrestaShop module. The extractor is total (any malformed input returns null) and deliberately does not verify the signature: the token arrives as the direct response body of a server-to-server POST, never via the browser, and the claim is display text, not an authorization decision. A gateway connected before this change shows the "re-authenticate" placeholder until the merchant reconnects.

Requires payplug/unified-plugin-core ^1.1.2, where TokenOutput gained a nullable idToken — earlier versions drop id_token from the token response entirely. Constraint bumped accordingly.

PRE-3632 — disconnect one gateway

New UnifiedLogoutController + Auth/GatewayConnectionRevoker — the inverse of the OAuth callback, scoped to a single gateway config. It clears live_client, test_client and account_email, drops both cached UPC tokens, and disables the payment method.

• hfIdentifier is cleared only when the config is a CB gateway with Hosted Fields selected; elsewhere it is a merchant-typed value, not account-bound state. live, oneClick, deferredCapture, the display-mode flags and fees_for are untouched.
• Distinct from the renew_oauth checkbox, which immediately mints new credentials — logout ends with none.
• Two consequences worth flagging for QA: since PRE-3629 only counts enabled gateways, logging out releases that gateway's channels for another config to claim; and because PaymentMethodValidator::process() only ever disables, the merchant must re-tick "Enabled" by hand after reconnecting.
• GET, not POST: the button is rendered inside the Sylius payment-method <form>, where a nested <form> would be invalid HTML. The CSRF token travels in the query string, the same shape as Sylius's own sylius_admin_shipment_resend_confirmation_email. security.csrf.token_manager is injected with @? — it is absent when CSRF protection is off, and a hard reference would break container compilation for such an app.

---

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 💥 Breaking change (fix or feature that causes existing functionality to change and that could impact other libs)
• 📦 Dependency update

Breaking changes for anyone extending the plugin

Removed / changed	Replacement
PayPlugApiClientFactoryInterface::create(string $factoryName)	createForPaymentMethod(PaymentMethodInterface $pm)
UnifiedApiPaymentCreatorInterface::createPayment($dto)	createPayment($dto, PaymentMethodInterface $method)
OperationStatusFetcherInterface::getOperation($id)	getOperation($id, PaymentMethodInterface $method)
AbstractGatewayConfigurationType::__construct() — $gatewayConfigRepository and $requestStack dropped	translator only
shouldValidateBaseCurrency() / baseCurrencyViolationMessage() — protected → public, now take the mapped config	same hooks, new visibility/shape
$gatewayFactoryName property on the 8 configuration types	no longer read; the factory name comes off the gateway config
Translation key form.only_one_gateway_allowed	form.gateway_channel_conflict (%channel%, %payment_method%)
Injecting PayplugUnifiedCore\Contracts\IConfigurationRepository	ScopedConfigurationRepositoryInterface, scoped per payment method

---

Checklist

Code Quality

• Code is linted and formatted
• No unnecessary commented-out code or debug logs
• No hardcoded values (use env variables or config)

Testing

• Unit tests added / updated

New suites: GatewayChannelConflictCheckerTest, PaymentMethodTypeExtensionTest, IdTokenEmailExtractorTest, GatewayConnectionRevokerTest, UnifiedLogoutControllerTest, IntegratedPaymentControllerTest, plus scoping coverage added to the UPC, API-client-factory and SupportedMethodsProvider tests.

Security & Ops

• No sensitive data or secrets introduced
• Logging and error handling are appropriate

Manual test plan

1. Create two CB payment methods on disjoint channels, authenticate each against a different PayPlug account → both save and both stay enabled.
2. Try to give the second one a channel the first already holds → the checkbox is rendered disabled, and submitting the overlap anyway is refused with the conflict error on the channels field.
3. Disable the first → its channels become selectable for the second.
4. Check out on each channel → the payment is created on that channel's account (SupportedMethodsProvider amount limits and allowed countries follow the right account too).
5. On each update screen, the connected account email is displayed; "Disconnect this account" clears that gateway's credentials and disables it, leaving the other gateway connected and working.

[adumont-payplug]

Review pass on the full diff

Reviewed in five passes: form/validation (PRE-3628/3629), credential scoping (PRE-3682/3683/3685), auth controllers + extractor + revoker (PRE-3631/3632), tests, config/translations. Full PHPUnit suite run under PHP 8.2: 589 tests, green.

What holds up

Several of the load-bearing claims in the description were checked against vendor source rather than taken on trust, and all of them hold:

• The wither immutability is watertight. SyliusUpcConfigurationRepository uses clone $this and assigns on the clone; nothing mutates $this. Every consumer in src/ scopes before use — there is no unscoped configurationRepository-> call left. The cross-tenant leakage failure mode during IPN is closed.
• The token-cache purge is correct, which is easy to get wrong: TOKEN_CACHE_KEY_PREFIX matches UPC's TokenManager exactly, and both the revoker and TokenManager go through the same shared SyliusTokenCache, so PSR-6 key sanitization is symmetric on write and delete. GatewayConnectionRevokerTest exercising a real cache over an ArrayAdapter instead of mocking ITokenCache is the right call.
• The @? CSRF argument is sound. Sylius' own CsrfProtectionEnabledExtension::isCsrfProtectionEnabled() is literally $this->container->has('security.csrf.token_manager') — the template gate and the controller null check are the same condition, so there is no window where the link omits a token the controller then demands. The route also sits behind /admin, so the token is defence-in-depth, not the only authorization.
• IdTokenEmailExtractor is genuinely total. Every branch checked: json_decode without JSON_THROW_ON_ERROR returns null for non-UTF8 and for depth > 512; a segment length ≡ 1 mod 4 produces a pad base64_decode(..., true) rejects; filter_var never throws.
• Errors added to channels do not bubble to the root (ChoiceType sets error_bubbling => false on the type itself), and Form::add() inside POST_SET_DATA does re-map data into the replaced child (lockSetData is only on during PRE_SET_DATA). Both docblock claims are accurate.
• GatewayChannelConflictChecker is the strongest piece here. The asymmetry between findConflicts() (bails on a disabled subject) and findClaimedChannels() (unconditional, minus the subject's own channels) is non-obvious and correct.
• SupportedMethodsProvider is a real bug fix on its own — the old ??= let the first method's /account payload govern every later one in the list.

---

Two findings with no file in the diff

Three factory-name credential lookups the description does not list as remaining gaps. The breaking-change section says the only open half of PRE-3682 is client.xml's singletons. It isn't:

• src/Provider/OneySupportedPaymentChoiceProvider.php:42 — findOneByGatewayName(OneyGatewayFactory::FACTORY_NAME)
• src/Provider/Payment/ApplePayPaymentProvider.php:52 and :209 — same, for Apple Pay
• src/Twig/OneyExtension.php:35 — findOneBy(['factoryName' => OneyGatewayFactory::FACTORY_NAME])

findOneByGatewayName() is setMaxResults(1)->getSingleResult(), so with two Oney or two Apple Pay gateways it returns an arbitrary one — the exact bug this PR exists to kill, in shop-facing code (Apple Pay merchant-session/domain validation, Oney simulation display). Not necessarily in scope to fix here, but they should be listed and ticketed. Separately: that method is typed ?PaymentMethodInterface but getSingleResult() throws NoResultException rather than returning null — pre-existing.

No CHANGELOG.md / UPGRADE.md entry. There is an eight-row breaking-change table for anyone extending the plugin — dropped constructor arguments, changed interface signatures, a removed translation key, protected → public hooks. CHANGELOG.md has a live ## [2.0.0] - Unreleased section and neither file was touched. Integrators will not read a PR body.

---

Assessment

Ready to merge: with fixes. The credential-scoping architecture is sound and the immutability, cache-key and form-mechanics claims all check out. One critical issue (see the IntegratedPaymentController thread) turns a previously dormant assumption into an exploitable one, and the form layer that enforces the new per-channel rule traded its only real-form test for an all-mock one.

On the plan itself: the four pre-justified tradeoffs — GET + query-string CSRF, unsigned id_token parsing, leaving already-held channels selectable, the wither-based scoped repository — all survive scrutiny, and in three cases the reasoning is more careful than the summary lets on. Where the plan under-reaches is that it treats "thread the PaymentMethodInterface through" as sufficient without asking where that PaymentMethodInterface comes from. IntegratedPaymentController is where that omission bites.

[claude]

Claude Code Review

Claude Code Review is paused for this repository. To reconnect it, an admin of this repository's GitHub organization (or the account owner, for personal repositories) who can also manage your Claude organization's Code Review settings needs to re-link GitHub in Code Review settings. This is a one-time step.

_{Tip: disable this comment in your organization's Code Review settings.}