Add store-scoped payment management to Grand.Web.Store

[KrzysztofPajak]

Type: feature

Issue

The store-manager panel (Grand.Web.Store) already mirrors many Admin configuration areas in a store-scoped way (Shipping, Tax, GiftVoucher, Discount, ContactAttribute), but payment configuration was missing — it lived only in Grand.Web.Admin. A store owner had no way to manage payment methods, payment settings, or payment restrictions for their own store.

Solution

Adds a store-scoped PaymentController to Grand.Web.Store, following the existing Store ShippingController conventions (primary-constructor DI, CurrentStoreId from StaffStoreId, [PermissionAuthorize(PermissionSystemName.PaymentMethods)] + action-level permissions). It provides the three capabilities requested:

• Payment methods — list available providers and enable/disable them for the store (stored in the store-scoped PaymentSettings.ActivePaymentProviderSystemNames).
• Payment settings — the store-level PaymentSettings toggles.
• Payment restrictions — restrict each method by country / shipping method, like the Store shipping restrictions.

Payment settings and active methods were already store-scoped via ISettingService + PaymentSettings. Payment restrictions, however, were stored globally (setting keys PaymentMethodRestictions.{SystemName} / ...Shipping.{SystemName} with no storeId), unlike shipping restrictions which live on the store-scoped ShippingMethod entity. To get true per-store isolation, the four restriction methods on IPaymentService / PaymentService now accept an optional string storeId = "", which is threaded into:

• ISettingService.GetSettingByKey(..., storeId) — store-specific read with fallback to the global value.
• ISettingService.SetSetting(..., storeId) — writes a per-store setting row.
• LoadActivePaymentMethods / LoadAllPaymentMethods — so restrictions apply per store at checkout.

Views live in Areas/Store/Views/Payment/ (Index grid, Settings, MethodRestrictions + Country/Shipping tab partials), reusing the existing Grand.Web.AdminShared payment models/mappers. The Store sidebar reuses the shared AdminSiteMap, which already contains the Payment node, so no sitemap change was needed.

Plugin configuration links (gateway credentials via each provider's ConfigurationUrl) are intentionally out of scope here and deferred to a separate task; the Store methods grid shows the list + active toggle only.

Breaking changes

None. The new storeId parameters on IPaymentService are optional and default to "", so the existing Admin PaymentController and all other callers keep their current global behaviour unchanged.

Testing

1. Build the solution (dotnet build) — Admin and Store both compile.
2. As an admin, grant the Manage payment methods permission to the store manager customer group (Customers → Customer groups → store manager → ACL). Note: this permission is not part of the default store-manager set (consistent with how ShippingSettings / TaxSettings were added).
3. Log in to the store panel (/store) as a store manager. Confirm a Payment item appears in the sidebar with Payment methods, Payment settings, and Payment method restrictions.
4. Methods: open store/payment, toggle a provider active, reload, and confirm it persists. Verify the PaymentSettings Setting record carries the manager's StoreId (store-scoped, not global).
5. Settings: change a toggle on the settings page, save, reload — persists for that store only.
6. Restrictions: open Method restrictions, restrict a method for a country and/or a store shipping method, save. Confirm a paymentmethodrestictions.* / paymentmethodrestictionsshipping.* Setting row is written with the manager's StoreId, leaving any global row untouched.
7. Isolation: with two stores, confirm restrictions set by store A do not affect store B, and that at checkout in store A the restricted method is hidden for the restricted country/shipping while store B is unaffected (falling back to the global value if it has no override).

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
22 Accepted issues

Measures
0 Security Hotspots
92.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud