The Eclipse Architecture

Eclipse is an API-first SaaS platform hosted on AWS by EFT Corporation. At its core, it exposes more than 250 RESTful endpoints designed to provide a consistent and flexible set of services, covering areas such as customer onboarding, wallets, card issuing, and payments.

Eclipse includes an admin portal that consumes these APIs for ad hoc operations, CRM activities, and general administrative tasks. In practice, most tenants use their own branded, customer-facing channels. These channels typically call Eclipse APIs either directly from the client or via tenant-managed backend services.

To help tenants accelerate time to market, Eclipse also provides optional white-label starting points for building channels on top of the platform, or for solutions built by EFT Corporation:

A white-label WhatsApp bot supporting onboarding, wallets, card issuing, QR payments, and value-added services
A white-label React-based PWA covering onboarding, wallets, card issuing, QR payments, and value-added services
A white-label React Native mobile app covering onboarding, wallets, card issuing, QR payments, and value-added services

The combination of Eclipse APIs and these white-label channels allows tenants to launch quickly and evolve their offerings over time.

Multi-tenant API model

All Eclipse REST APIs are exposed through a single base URL shared across tenants. The tenant context is defined by a path parameter in the URL and enforced through the JWT bearer token included with each request.

For example, tenant 100 can retrieve its customers with:

GET https://ukheshe.live/eclipse-conductor/rest/v1/tenants/100/customers

While tenant 200 would call:

GET https://ukheshe.live/eclipse-conductor/rest/v1/tenants/200/customers

Tenants are logically isolated on the backend. Each tenant has its own configuration, customers, wallets, and data, while sharing the underlying AWS infrastructure. This model is similar to platforms such as Office 365 or Google Workspace, where each organisation operates independently on shared infrastructure.

Backend architecture

The Eclipse backend follows a layered, cloud-native design that uses proven technologies at each layer to ensure scalability, resilience, and operational consistency:

AWS data centre infrastructure for compute, storage, and networking
AWS Elastic Container Service (ECS) for container orchestration, autoscaling, and resilience
AWS relational and document databases for data persistence
Docker containers running on Linux
Java 19 runtime
Quarkus framework
Selected open-source libraries
EFT Corporation standardised architecture libraries
Eclipse-specific business logic

The high-level architecture is depicted in the following diagram:

EFT Corporation is an AWS Partner and has completed an architecture and security review with AWS to validate that Eclipse follows AWS best practices for scalability, resilience, and security. As a result, the Eclipse platform has received the AWS Well-Architected designation. From an operational perspective, Eclipse has maintained 100% uptime over the past 24 months, with less than 30 seconds of total downtime since inception, and there have been no recorded security exploits.

Although Eclipse serves as an orchestration layer that exposes coarse-grained APIs over multiple fine-grained backend systems, it is not simply an ESB or API gateway. Many core Eclipse constructs are implemented as stateful microservices with persistence, including customers, wallets, and accounts.

The Eclipse APIs are intentionally designed to keep the API contract stable while allowing the underlying implementation to change. Services can be hosted internally within Eclipse or externalised to third-party systems. For example, a wallet’s store of value may be managed directly within Eclipse or backed by an external system such as a bank account, card management platform, or crypto provider.

Card issuing is a good example of this abstraction. Issuing a card through Eclipse typically requires only a minimal JSON payload. The underlying card management system could be Mastercard PTS, Postilion postbridge, or another provider entirely, but these details are hidden from the API consumer.

A core technical component within Eclipse is the eclipse-conductor, which acts as the single entry point for all API traffic. It combines the capabilities of an API gateway and ESB, but is purpose-built by EFT Corporation to support Eclipse use cases and avoid the complexity of off-the-shelf solutions that rely on multiple components or scripting languages.

The conductor is built on** Vert.x and Quarkus, using a stateless, non-blocking I/O model t**o deliver high throughput and low latency. Orchestration and service composition logic is implemented directly in Java, simplifying both development and ongoing maintenance.

Key capabilities provided by the eclipse-conductor include:

Authentication and identity services supporting JWT, OIDC, SAML2, and custom schemes
API observability, including tracing and detailed metrics (latency, error rates, concurrency)
Load balancing and failover
Java-based orchestration and service composition
Reverse proxy and service discovery
Request validation and policy enforcement
Caching
Authorization and access control
Web application firewall protections (including XSS and SQL injection)
Accounting and auditing
Rate limiting for throughput and concurrency
TLS termination

The eclipse-conductor either proxies requests to, or orchestrates across, downstream microservices, which are predominantly implemented using Java and Quarkus.**

To fully understand the Eclipse APIs and their behaviour, it is important to become familiar with the naming conventions and terminology used throughout this documentation, alongside the OpenAPI specification.