Introduction
Eclipse is a Banking as a Service (BaaS) platform that allows financial institutions and fintechs to expose their licensed capabilities — customer onboarding, bank account provisioning, payments, withdrawals, card issuing, VAS, and more — through a single, consistent API.
A common deployment model is where Eclipse operates as a white-label technology platform under a bank or institution's brand. In this model, an Operator (the institution or its designated team) carries out administrative tasks on behalf of tenants:
- Platform setup and deployment
- Tenant onboarding, configuration, and lifecycle management
- Permission and template management
- Fee structure configuration
- Transaction monitoring and fraud management
- Incident response and operational support
- Tenant offboarding
This guide is intended for operators and technical administrators responsible for running the Eclipse platform. It should be read alongside the Eclipse Integration Guide — operators should have full knowledge of the API capabilities available to tenants.
Operator Lifecycle
The sections of this guide follow the operational lifecycle of the Eclipse platform:
1. Platform Setup
Get the platform deployed and configured before onboarding any tenants.
| Section | Description |
|---|---|
| Installation Options | Cloud-hosted SaaS vs. self-hosted deployment models, infrastructure requirements, Hazelcast clustering, ECS Anywhere |
| Accountable Institutions | Configuring the white-label institution layer that groups tenants under a common brand and administration |
| Admin Portal Configuration | Branding, theming, menu customization, email templates, onboarding wizards, and dropdown configuration |
| Postilion Management | Connecting to the Postilion card management infrastructure, HSM services, and outbound processor configuration |
| 3D Secure Configuration | Enabling Wibmo 3DS MPI for acquirer-side 3DS authentication and issuer-side ACS integration |
| Pool Account Integration | Connecting the sponsor bank's pool account for real-time deposit notifications and EFT outflows |
| Eclipse Logging | Log level configuration, JSON log format, CloudWatch integration, and distributed trace analysis |
2. Tenant Onboarding
Configure each tenant before they go live.
| Section | Description |
|---|---|
| Tenant Management | Creating tenants, exporting and importing tenant configuration as JSON, promoting sandbox configs to production |
| Wallet Type Configuration | Defining wallet modes, currencies, program codes, KYC requirements, and fee logic per wallet type |
| Permissions Management | Configuring shared permission templates, wallet-specific permissions, and reporting access by role |
| Attribute Validation | Enforcing payload validation rules for POST/PUT requests per tenant, institution, or globally |
| Tenant Config Reference | Complete reference of all tenant configuration keys — card issuing, authentication, notifications, fraud, limits, and more |
| Property Management | Managing global and tenant-level properties, permission-gated access, and dynamic Javaassist-derived properties |
3. Day-to-Day Operations
Ongoing management of a live platform.
| Section | Description |
|---|---|
| Limit Configuration | Transaction limit patterns (per wallet, user, organisation, card), collation periods, override mechanism, and low-balance alerts |
| Fee Configuration | Retail fees (tenant to customer), wholesale fees (operator to tenant), tiered structures, Wallet Logic Sets, and fee scheduling |
| Multi-Currency Configuration | Enabling multi-currency wallets, configuring source/destination/fee wallets per currency and transaction type |
| Transaction Monitoring | Fraud rule engine, static rules, custom fraud rule creation, third-party fraud platform integration, Postilion-specific patterns |
| Developing Eclipse Plugins | Building and deploying custom plugins — injection-point, implementation, and listener categories |
Key Concepts for Operators
Multi-Tenant Architecture
Every resource in Eclipse is scoped to a tenant. Tenants are logical partitions of the platform — each with its own customers, wallets, admin users, configuration, and permission set. Tenants cannot access each other's data. A single Eclipse deployment can support hundreds of tenants simultaneously.
Tenants can be grouped under an Accountable Institution (a white-label brand layer), which allows institution-level administrators to manage a set of tenants within their brand scope.
Configuration Inheritance
Most configuration in Eclipse follows a three-level hierarchy:
Global (platform-wide) → Institution (brand-level) → Tenant (highest precedence)When a configuration key is evaluated, the tenant-level value takes precedence over the institution level, which in turn overrides the global default. This allows operators to set sensible platform-wide defaults and let tenants customize within those boundaries.
Sandbox vs. Production
Eclipse maintains separate sandbox and production environments. The recommended workflow is:
- Configure the tenant fully in sandbox.
- Test all flows end-to-end in sandbox.
- Export the tenant configuration as a JSON file.
- Review and redact any sandbox-specific values (marked
TODOin the export). - Import the JSON into production to create the production tenant.
See Tenant Management for the export/import workflow.
Zero-Downtime Deployments
Eclipse is designed for zero-downtime deployments. All API changes are backwards compatible. Platform updates occur Monday–Thursday during business hours. Scheduled downtime (when required) is communicated at least 5 days in advance and planned between 23:00 and 04:00 SAST.
Getting Help
| Channel | Use |
|---|---|
| Onboarding support | New tenant setup, integration questions, testing support |
| Operational support | Day-to-day platform issues, Mon–Fri 08:00–17:00 SAST |
| 24/7 Production Support | Critical incidents, +27 10 449 1784 |
| Help Center | Submit and track support tickets |