Skip to main content

Overview

This section covers how External Services are configured in Connect to enable secure integration with downstream systems.

Every external system that Connect communicates with must first be defined as a Service Provider. Each provider can have one or more Service Accounts, which capture authentication details and environment-specific configuration.

Where encryption, decryption, signing, or transformation is required, Message Profiles are used to process request and response payloads.

This structured approach ensures secure, reusable, and manageable downstream integrations.

Integration Architecture​

Downstream integration in Connect follows a layered model:

  1. Service Provider -- Defines the external system.
  2. Service Account -- Captures authentication and environment details.
  3. Message Profile -- Defines request and response processing steps.
  4. Microservice Mapping -- Uses the provider and account to execute calls.

This separation provides clarity, reusability, and strong security boundaries.

Service Providers​

A Service Provider represents an external system such as:

  • KYC Registries
  • Bureau Services
  • Payment Gateways
  • Banking Apis
  • Third-party Data Providers

The provider defines the identity of the downstream system but does not contain authentication secrets.

Service Accounts​

A Service Account is created under a Service Provider.

Service Accounts capture environment (Production, Sandbox), authentication mechanism, credentials and the associated message profile.

This allows:

  • Multiple environments per provider
  • Separate credentials for each integration
  • Clear isolation between test and production accounts

Message Profiles​

When request or response encryption and signing is required, Connect uses Message Profiles.

Message Profiles define a processing pipeline that can include:

  • Payload encryption and decryption
  • Payload signing
  • Payload transformations
  • Value extraction using JPath

Message Profiles are applied at the Service Account level and are executed during:

  • Outbound request processing
  • Inbound response processing

This ensures:

  • Secure communication with downstream systems
  • Standardized transformation logic
  • Reusable integration workflows

Typical Integration Flow​

  1. A microservice is configured to use a Service Provider.
  2. The Service Account supplies authentication and headers.
  3. If configured, the Message Profile processes the request.
  4. The request is sent to the downstream provider.
  5. If configured, the Message Profile processes the response.
  6. The final processed response is returned to the caller.

Why This Design Matters​

The Providers architecture enables:

  • Clear separation of identity and credentials
  • Reusable message processing logic
  • Secure encryption and signing workflows
  • Multi-environment configuration
  • Centralized management of external integrations

All provider configuration, authentication, and message processing logic is managed declaratively through the Connect UI — without requiring application code changes.

This design allows Connect to scale across multiple downstream systems while maintaining strong governance and security.

Summary​

The Providers section is the integration foundation of Connect.

By configuring:

  • Service Providers
  • Service Accounts
  • Message Profiles

administrators can securely connect to external systems with structured, reusable, and maintainable integration logic.