Admin Panel
PSP Management | Routing | Methods | Partners | Compliance
Purpose
The Admin Panel is the single control plane for all payment infrastructure configuration. It eliminates the need for direct database edits or code deploys when changing payment behavior.
Every setting is scoped: global defaults → partner (white-label brand) overrides → country overrides → payment method overrides. The most specific scope always wins.
Target users: payment operations team and compliance officers. Engineers should only be needed to add new capabilities -- not to change configuration.
Scope Hierarchy
Example: MGA forbids crypto methods in Finland
Wins: Always. Cannot be overridden.
Example: Min deposit = $10
Wins: When no lower scope has an override
Example: Partner A: min deposit = $20
Wins: Over global default for that partner's traffic
Example: DE + Partner A: min deposit = $25
Wins: Over partner default for traffic from that country
Example: Crypto + DE + Partner A: min deposit = $50
Wins: Most specific. Wins over all other scopes.
Admin Panel Modules
PSP Management
Configure payment service providers: credentials, connection parameters, health monitoring, and operational status.
FUNCTIONALITY
- Add, edit, or soft-disable a PSP without code changes
- Store API credentials (key/secret) encrypted at rest; never exposed in UI after save
- Configure base URL, webhook signing secret, timeout, and retry policy per PSP
- Set health check endpoint and define what a "healthy" response looks like
- Toggle maintenance mode: PSP is excluded from routing while in maintenance
- View live health score and last-N transaction success rate per PSP
BACKEND -- NOTES
- BECredentials stored encrypted (AES-256). Never returned in GET responses -- only a masked indicator (e.g., "key set ✓").
- BEPSP record has a `status` enum: ACTIVE | MAINTENANCE | DISABLED. Orchestrator skips non-ACTIVE PSPs.
- BEHealth score is computed async by a background job and stored on the PSP record; not computed on request.
FRONTEND -- NOTES
- FEAPI key/secret fields: write-only inputs. On load, show "••••••••" placeholder, not actual value.
- FEHealth indicator: colored dot (green/amber/red) derived from health score range.
Payment Methods
Define available payment methods globally and per-scope. Control display order separately for mobile and desktop. Set integration type per (method + PSP) pair.
FUNCTIONALITY
- Global method registry: Visa, Mastercard, Maestro, Crypto (BTC/ETH/USDT), Bank Transfer, e-Wallet, local methods (BLIK, PIX, UPI…)
- Enable or disable each method globally, per partner, or per country
- Map each (method + PSP) pair to either H2H (direct API) or Invoice Link (redirect) integration type
- Set display name, icon, and sort order for end-user checkout UI
- Configure separate display lists for mobile and desktop: same methods, different priority
- Mark a method as "deposit-only", "withdrawal-only", or "both"
BACKEND -- NOTES
- BE`payment_methods` table: id, slug, display_name, icon_url, direction (DEPOSIT|WITHDRAWAL|BOTH), is_active.
- BE`psp_method_configs` table: psp_id, method_id, integration_type (H2H|INVOICE_LINK), is_active, extra_params (JSONB).
- BE`method_display_orders` table: scope (GLOBAL|PARTNER|COUNTRY), scope_id, method_id, device (MOBILE|DESKTOP), position.
FRONTEND -- NOTES
- FEDisplay order editor: two drag-and-drop lists side by side -- Mobile | Desktop. Each card shows method icon, name, toggle.
- FEH2H vs Invoice Link badge clearly visible on each (method + PSP) row in the config table.
Countries & Currencies
Control payment availability per country, assign accepted currencies, set KYC requirements, and define AML risk ratings.
FUNCTIONALITY
- Enable or block a country for deposit, withdrawal, or both
- Override available payment methods per country (subset of global list)
- Set country-level currency: which currencies are accepted, which is default
- Configure KYC tier required to transact in this country (e.g., Tier 1 = ID only, Tier 2 = proof of address)
- Set country-level AML risk rating: standard / elevated / high. Affects manual review queue routing
BACKEND -- NOTES
- BE`country_configs` table: country_code (ISO 3166-1 alpha-2), deposit_enabled, withdrawal_enabled, default_currency, kyc_tier_required, aml_risk (STANDARD|ELEVATED|HIGH).
- BEAccepted currencies stored as array on country_config. Currency list drives checkout dropdown.
- BECountry block is evaluated at the API Gateway level before any orchestration. Hard block = 403.
FRONTEND -- NOTES
- FECountry list with search, flag icon, status badges (Deposit / Withdrawal / Blocked), and inline toggle.
- FEAML risk badge color-coded: green (standard), amber (elevated), red (high).
Partners (White-label Brands)
Each white-label partner gets an isolated configuration scope. Partner settings override global defaults and can only be more restrictive -- never more permissive than the global baseline or assigned license.
FUNCTIONALITY
- Each white-label partner (brand) has its own configuration scope that overrides global defaults
- Assign which PSPs are available to this partner and in what priority order
- Enable or disable specific payment methods per partner regardless of global availability
- Set partner-specific deposit/withdrawal limits that are stricter than global limits
- Configure partner-level fee split and settlement currency
- Assign a compliance profile (license) to this partner -- determines which countries and methods are permitted
BACKEND -- NOTES
- BE`partners` table: id, brand_id (FK brands), license_profile_ids (array FK), psp_priority (ordered array of psp_ids), fee_config (JSONB).
- BEScope resolution order: method override → country override → partner override → global. First defined wins.
- BEIf partner has no override for a setting, the system falls back to global default -- no null checks needed in business logic.
FRONTEND -- NOTES
- FEPartner detail page: tabs for General, PSPs, Methods, Limits, License. Each tab is a self-contained form.
- FEInherited-from-global fields shown with a subtle "Global default" label and a "Override" button to activate the field.
Limits & Velocity Rules
Define transaction size limits, rolling velocity caps, and auto-review triggers. All limits cascade through the same scope hierarchy as other settings.
FUNCTIONALITY
- Global min/max per transaction: deposit and withdrawal separately
- Rolling velocity caps: per player per day/week/month (count and volume)
- Method-level limits: crypto may have higher minimum than cards
- Partner-level overrides: a VIP partner may have higher caps than default
- Responsible Gaming (RG) self-imposed limits: player-set caps are enforced here, not overrideable by ops
- Hard limits for large withdrawals: automatically trigger manual review queue above threshold
BACKEND -- NOTES
- BE`limit_rules` table: scope, scope_id, method_id (nullable), direction, min_amount, max_amount, daily_cap_count, daily_cap_volume, monthly_cap_volume, review_threshold.
- BEVelocity counters stored in Redis with TTL = window duration. Checked synchronously before PSP call.
- BERG self-imposed limits are stored separately and are not visible in the admin panel; they take precedence silently.
FRONTEND -- NOTES
- FELimit editor: currency-aware amount inputs. Show equivalent in EUR for non-EUR partners.
- FEVisual hierarchy: global → partner → method shown as nested cards to make override structure clear.
Routing Rules
Build and manage routing rules that map transaction conditions to PSPs. Define cascade chains, A/B splits, and emergency overrides.
FUNCTIONALITY
- Visual routing rule builder: IF (brand + country + method + amount range) THEN use PSP with priority list
- Rule priority ordering: drag to reorder; first matching rule wins
- Cascade order per rule: define fallback chain PSP1 → PSP2 → PSP3 with retry conditions
- A/B split routing: send X% of traffic to PSP-A and (100-X)% to PSP-B for a given rule
- Dry-run mode: simulate which PSP a given transaction would be routed to without actually processing it
- Emergency override: one-click force all traffic of a brand/country/method to a specific PSP
BACKEND -- NOTES
- BE`routing_rules` table: id, brand_id, country_code, method_id, amount_min, amount_max, psp_chain (ordered JSON array with weight %), priority, is_active.
- BERules evaluated in ascending priority order. First match short-circuits. Global catch-all rule should always be last (highest priority number).
- BEEmergency override flag bypasses normal rule evaluation entirely. Stored as a separate "override" record with expiry timestamp.
FRONTEND -- NOTES
- FERule list view: sortable table with drag handles for priority reorder. Inline enable/disable toggle per rule.
- FEDry-run panel: form with brand, country, method, amount, direction. Shows which rule matched and which PSP would be selected.
- FEEmergency override: prominent red banner when active, with timer showing expiry and one-click cancel.
License & Compliance Profiles
Define license profiles that encode jurisdiction-specific payment rules. Assign profiles to partners. Used as hard constraints -- they cannot be overridden at any lower scope.
FUNCTIONALITY
- Create named license profiles: MGA, UKGC, Curaçao, unlicensed, etc.
- Each license profile defines: permitted countries, forbidden payment methods, required KYC tier, RG requirements
- Assign one or more license profiles to a partner; constraints are the union of all assigned profiles
- Compliance audit log: every change to a license profile is versioned and attributed to an admin user
BACKEND -- NOTES
- BE`license_profiles` table: id, name (e.g. "MGA"), permitted_country_codes (array), forbidden_method_ids (array), min_kyc_tier, rg_requirements (JSONB).
- BEAt transaction time: license constraints are evaluated before partner overrides. A forbidden method returns 403 regardless of routing rules.
FRONTEND -- NOTES
- FELicense profile page: two-column layout -- permitted countries map on the left, forbidden methods list on the right.
Audit Log
Immutable record of every configuration change. Required for compliance and incident post-mortems.
FUNCTIONALITY
- Every configuration change is logged: who, what field, old value → new value, timestamp
- Immutable log -- entries cannot be edited or deleted, only appended
- Searchable and filterable by admin user, resource type, partner, date range
- Exportable to CSV for compliance reporting
BACKEND -- NOTES
- BE`audit_logs` table: id, admin_user_id, action, resource_type, resource_id, old_value (JSONB), new_value (JSONB), created_at. No UPDATE or DELETE on this table -- ever.
- BEWrite to audit_log inside the same DB transaction as the config change. If the log write fails, the change rolls back.
FRONTEND -- NOTES
- FEDiff view: old value on left (red), new value on right (green) -- same visual pattern as git diff.
Access Control
Full read/write across all modules, all partners. Can manage admin users.
Read/write: PSP status, routing rules, method toggles, limits. Read-only: credentials, license profiles.
Read/write: license profiles, country AML ratings, KYC tiers. Read-only: everything else.
Key Implementation Notes
Config Cache Invalidation
The Orchestrator caches routing config in memory. When a rule changes in the Admin Panel, the backend must broadcast a cache invalidation event (e.g., via Redis pub/sub) to all Orchestrator instances. Max stale window: 10 seconds.
No Cascading Deletes
PSPs and methods are never hard-deleted -- only soft-disabled. Historical transactions reference PSP/method IDs; deleting them would break reconciliation and reporting.
Credential Rotation
PSP credentials can be updated without downtime. The system must complete in-flight transactions with the old key and use the new key for new ones. Implement with a short dual-key window (~30s).
Admin Panel is NOT the source of truth for transactions
The Admin Panel configures behavior -- it does not store transaction data. All transaction history lives in the core `transactions` table and is accessed via separate reporting/analytics interfaces.