Implement environment-aware endpoint configuration for Vipps and BankID
epic-bankid-vipps-login-api-clients-task-002 — Build an environment configuration module that resolves the correct Vipps Login OAuth 2.0 base URLs (test vs. production) and BankID Supabase Edge Function endpoints based on the active Flutter build environment. Configuration must be injectable and never hard-coded inline. Expose typed config objects consumed by both the Vipps API Client and the BankID Provider Client.
Acceptance Criteria
Technical Requirements
Implementation Notes
Use Flutter flavors or --dart-define-from-file for environment switching. Define a sealed class AuthEnvironmentConfig with two concrete implementations: TestAuthEnvironmentConfig and ProductionAuthEnvironmentConfig. Expose a Riverpod Provider
This ensures both API clients receive typed, correct URLs with zero string duplication. Avoid the antipattern of reading environment from a .env file at runtime — this is a mobile app, use compile-time injection.
Testing Requirements
Unit tests using flutter_test. Two test cases minimum: (1) test environment returns correct Vipps test base URL and staging Edge Function URL; (2) production environment returns correct live URLs. Use a factory or mock flavor injection to avoid needing actual --dart-define at test time. Assert all derived endpoint paths are correctly appended (e.g., /v2/login/token).
No integration or network calls in these tests.
Norway has multiple BankID broker providers (e.g., Signicat, Criipto, Nets) with different integration contracts, pricing, and WebView behavior. If the broker is not selected and contractually agreed before implementation begins, the BankIDProviderClient may need to be rewritten after initial build.
Mitigation & Contingency
Mitigation: Define a minimal broker interface abstraction (session initiation, WebView URL generation, assertion validation) before writing any provider-specific code. Confirm broker selection with Norse Digital Products before starting this epic.
Contingency: If the broker changes after implementation, the abstraction layer allows replacing the provider-specific implementation behind the same interface with a targeted rewrite rather than a full redesign.
Android deep link handling with custom URI schemes can conflict with existing app links (HTTPS-based) or fail silently on certain Android versions if the intent filter is misconfigured, causing OAuth callbacks to never reach the app and leaving users stranded on the Vipps or BankID page.
Mitigation & Contingency
Mitigation: Use HTTPS app links (Android App Links) rather than custom URI schemes where possible, as they are more reliable on modern Android. Test deep link receipt on Android 12+ explicitly during development, as this version changed intent flag requirements.
Contingency: Implement a polling fallback for Vipps (check auth status on app foreground) as a secondary callback mechanism if deep link receipt fails on specific Android configurations.
Vipps Login has a separate test environment (mt2.vipps.no) that requires distinct test merchant credentials which must be applied for separately. If test credentials are delayed, integration testing of the VippsApiClient cannot proceed, blocking the entire authentication flow.
Mitigation & Contingency
Mitigation: Apply for Vipps test merchant credentials at the start of the project sprint, not when implementation begins. Use Vipps' publicly documented mock token responses for unit tests to decouple unit testing from live credentials.
Contingency: Implement the VippsApiClient with full mock injection support so all service-layer tests can run against a stub client while waiting for official test credentials.