Fix customer login and credit-card checkout on non-Development environments

[hristobakalov]

Problem

On deployed (non-Development) environments, logging in as any existing site user (e.g. the demo user David Knipe) failed with the generic error page "Something Went Wrong — Something went wrong when trying to access this resource." All account pages (profile, order history, addresses) and checkout were equally broken. Completing a purchase with a credit card failed even where login worked.

Root causes

1. ASP.NET Identity was not registered outside Development (src/Foundation/Startup.cs)

The upgrade only called AddCmsAspNetIdentity<SiteUser>() in Development, on the assumption that Opti ID replaces it on DXP. On other environments it registered null-returning stubs:

services.AddSingleton<ServiceAccessor<ApplicationSignInManager<SiteUser>>>(_ => () => null);
services.AddSingleton<ServiceAccessor<ApplicationUserManager<SiteUser>>>(_ => () => null);

Consequences on deployed sites:

• PublicApiController.Login / InternalLogin called SignInManager().SignInAsync(...) on null → NullReferenceException → 500 on every customer login.
• ProfilePageController, OrderHistoryController, ResetPasswordController, UsersController and CheckoutController constructor-inject ApplicationSignInManager<SiteUser> / ApplicationUserManager<SiteUser> directly — unresolvable from DI → 500 on profile, orders, addresses and checkout pages.

The assumption was incorrect: AddOptimizelyIdentity() (called with useAsDefault: false) installs an IAuthenticationSchemeProvider decorator that overrides authentication only for CMS UI paths (protected modules, edit/preview context) and delegates everything else to the app default. Opti ID (editors) and ASP.NET Identity (site visitors) are designed to coexist.

Fix: register AddCmsAspNetIdentity<SiteUser> unconditionally (as CMS 12 did), remove the null stubs, and use the existing EcfSqlConnection → EPiServerDB fallback so it also works on DXP where only EPiServerDB is injected. The Opti ID registration is unchanged.

2. Credit-card purchases threw InvalidCastException (GenericCreditCardPaymentGateway.cs)

Commerce 15 removed ICreditCardPayment; this branch replaced it with a compile-only stub in CommerceTypeStubs.cs that no runtime payment type implements, and changed GenericCreditCardPaymentOption to create a generic IPayment. The gateway still hard-cast the payment:

var creditCardPayment = (ICreditCardPayment)payment; // always throws at runtime

This made cart.ProcessPayments(...) fail for the default demo payment method, so no credit-card order could ever be placed. The cast result was dead code (the card-number validation using it is commented out).

Fix: removed the dead cast; the gateway returns its (already unconditional) successful result.

Not changed (known Commerce 15 preview gaps, flagged in code)

• Card details are no longer stored on payments (interface removed) — confirmation UI won't show last-4 digits.
• Saved credit cards (CreditCardService) remain stubbed out.
• Subscription first-order checkout workflow remains skipped (OrderGroupWorkflowManager removed in Commerce 15).

Verification

dotnet build -c Release — succeeds, 0 errors.

🤖 Generated with Claude Code

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}