Vipps Organization Cost Configuration
Component Detail
Description
Configuration component that manages per-organization Vipps client credentials and tracks the cost-sharing agreement across participating organizations (350–750 NOK/month). Ensures each organization uses the correct Vipps client ID and that billing attribution is recorded in Supabase.
vipps-org-cost-config
Summaries
The Vipps Organization Cost Configuration component directly enables the platform's multi-tenant Vipps login offering, allowing each participating organization to independently authenticate their members using Norway's dominant mobile payment identity system. By managing per-organization credentials and enforcing subscription validation before enabling the Vipps login option, this component protects the business from unauthorized usage and ensures billing attribution is cleanly recorded in Supabase. The 350–750 NOK/month cost-sharing model it supports makes Vipps login commercially viable for smaller organizations that could not bear the full integration cost alone, expanding the platform's addressable market. This directly reduces churn risk by offering a login experience members already trust and use daily, and it strengthens the platform's competitive position in the Norwegian market where Vipps penetration is near-universal.
This is a low-complexity configuration component with no external dependencies, making it a low-risk deliverable suitable for early-sprint completion. Its primary development effort involves setting up the per-organization credential store in Supabase, implementing the five configuration retrieval interfaces, and wiring subscription-status validation into the Vipps login enablement flow. Testing requirements are straightforward: unit tests for each interface covering enabled/disabled org states, missing config edge cases, and redirect URI validation. The main scheduling risk is upstream: this component must be completed before any Vipps OAuth or login UI components can be integrated and tested.
Admin reporting for cost-share attribution should be scoped separately to avoid scope creep. Deployment requires Supabase schema changes to be coordinated with the backend deploy.
This configuration component acts as the single source of truth for per-organization Vipps OAuth credentials, abstracting credential lookup from both the mobile client and the backend OAuth handler. The `getVippsConfig(orgId)` and `getClientId(orgId)` interfaces should query a Supabase table (e.g., `vipps_org_configs`) keyed on organization ID, returning nullable types to force callers to handle the disabled-org case explicitly. `isVippsEnabledForOrg(orgId)` should additionally check subscription status, not just credential presence, to prevent stale configs from enabling the login flow after subscription lapse.
`listActiveVippsOrgs()` supports admin reporting and should be backend-only, guarded by an admin role check. On the mobile side, only `getVippsConfig`, `isVippsEnabledForOrg`, `getClientId`, and `getRedirectUri` are needed — keep the mobile surface minimal. No caching layer is required given low call frequency, but consider a short TTL cache if subscription checks become a hot path.
Responsibilities
- Store per-organization Vipps client ID and redirect URI configuration
- Validate that an organization has an active Vipps subscription before enabling the login option
- Expose cost-share configuration for admin reporting
Interfaces
getVippsConfig(orgId: String): VippsOrgConfig?
isVippsEnabledForOrg(orgId: String): bool
listActiveVippsOrgs(): List<String>
getClientId(orgId: String): String?
getRedirectUri(orgId: String): Uri?