Let store owners configure payment plugins per store

[KrzysztofPajak]

Type: feature

Issue

A store owner can activate a payment method in the Store panel but cannot configure any of them. The grid at /Store/Payment/Index renders the method's friendly name and system name as plain text, so there is no way into the plugin's settings. Two things stand in the way:

1. The shipped payment plugins (Payments.CashOnDelivery, Payments.BrainTree, Payments.StripeCheckout) only have Areas/Admin controllers, and their ConfigurationUrl is an absolute /Admin/... path — linking to it would send a store manager into the admin area rather than to a screen they are allowed to use.
2. Two plugins were not correctly per-store even for an admin. BrainTree's admin screen read its settings from the injected instance (resolved for whichever store hosts the admin panel) and saved them with no store scope, so the store scope selector was ignored and per-store credentials were impossible. StripeCheckoutService assigned the api key to the process-wide static StripeConfiguration.ApiKey; harmless with one key for all stores, but with a key per store two concurrent checkouts overwrite each other's credentials.

Reproduce: sign in to /Store as a store manager with ManagePaymentMethods granted, open Payment methods — the names are not links, and there is no other route to the plugin settings.

Solution

Each payment plugin now ships an Areas/Store configuration screen that loads and saves its settings for the manager's own store (StaffStoreId), gateway credentials included, so each store transacts on its own Stripe/BrainTree account. The screens reuse the plugins' existing configuration models and localization resources — no new resources, no migration.

The Store grid links to that screen. The url is built from the Store-area controller the plugin actually ships (StoreAreaConfiguration.GetConfigurationUrl) rather than from the provider's own ConfigurationUrl, since the latter points at the admin area; a plugin without a Store screen renders plain text, exactly as the Shipping grid already does.

Storefront behavior needed no change: AddSettings already registers every ISettings class as scoped and loads it for the current store, so checkout has always read per-store values. The two genuine defects above are fixed — BrainTree's admin screen now honors the selected store scope (and offers the selector), and the Stripe api key travels with a per-call StripeClient.

Breaking changes

None to public contracts. One behavior change worth noting: BrainTree's admin configuration screen now writes to the selected store scope instead of always writing globally. With the scope set to all stores (the default) the behavior is identical; an admin who had a specific store selected will now see their edits apply to that store, which is the point of the fix.

Note that StoreManager does not carry ManagePaymentMethods by default — an admin must grant it before the menu entry and these screens appear. This is pre-existing and unchanged here.

Testing

1. As a main admin, grant the StoreManager customer group the ManagePaymentMethods permission, and assign a store manager customer to a store.
2. Sign in to /Store as that store manager and open Payment methods. The friendly name and system name of Cash on delivery, BrainTree and Stripe are now links; a payment plugin without a Store-area screen would stay plain text.
3. Click Cash on delivery. Change the additional fee and save. Confirm the success notification and that the value persists on reload.
4. In the main admin panel, open the same plugin with the store scope set to all stores. Confirm the global value is unchanged — the store manager's save created a store-scoped row only.
5. Place an order in that store's storefront and confirm the additional fee from step 3 is applied, then place one in another store and confirm it is not.
6. Open Stripe in the Store panel. Confirm the webhook url shown is that of the manager's own store, not of the host serving the panel. Fill in a test api key and secret, save, and confirm a checkout in that store uses them.
7. As a main admin, open BrainTree, switch the store scope selector to a specific store, save credentials, then switch back to all stores and confirm the global credentials were not overwritten.
8. dotnet build GrandNode.sln and dotnet test src/Tests/Grand.Web.Store.Tests both pass.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.