MEMEH RTPO logo
Documentation menu
Docs Home Get Started Concepts Architecture Security RTP Guide Fintech Developer Guide Runtime Configuration UAT Operations Downloads API Reference

Architecture

MEMEH RTPO is the official Request-to-Pay orchestration platform of the Bank of Sierra Leone National Payment Switch. Its architecture separates human enablement, governed configuration, runtime orchestration, trusted addressing, provider connectivity, and the existing IPS flow.

What MEMEH RTPO does
  • • Enables and certifies approved request submitters and providers
  • • Governs CAS, participant, route, and adapter configuration
  • • Orchestrates requests and records authoritative lifecycle evidence
What connected domain services do
  • • CAS owns alias resolution and financial-address data
  • • Participating providers own customer consent and RTP processing
  • • IPS remains the inter-participant switching and payment rail
Click to open full size. The diagram shows the current enablement, configuration, runtime, provider, and lifecycle boundaries.

Diagram legend (1–8)

Each step maps to the lifecycle section below.

Jump to lifecycle →
1
Checkout submits request
The approved request submitter calls Core with a bearer credential and a JSON idempotency_key.
2
Core validates and normalizes
Core validates aliases, merchant identity, amount, currency, reference, description, and duplicate-request rules.
3
CAS Resolver calls CAS V2
The resolver authenticates with the assigned participant identity, maps MEMEH RTPO alias types, and obtains verified payer and payee FinAddresses from the Central Addressing Service.
4
Published route is selected
Core matches the CAS payee servicer to an active participant, route, and Bank Adapter from the Control Plane snapshot.
5
Canonical instruction is dispatched
Core persists one instruction and posts it to the selected Bank Adapter.
6
Provider starts its RTP flow
The adapter posts to the configured provider RTP API. The provider owns customer consent and IPS interaction.
7
Provider returns lifecycle
The provider posts a stable lifecycle event to the adapter; the adapter restores correlation and forwards it to Core.
8
Core exposes outcome and history
Core deduplicates the event, enforces the state machine, and serves current status plus immutable event history.

High-level model

A practical stack view of how responsibilities split across enablement, request submitters, governed configuration, Core, adapters, providers, and IPS.

1
Enablement Portal
Governs access applications, administrator review, sandbox credentials, partner workspace, downloads, UAT guidance, and audit records before runtime use.
2
Business / Biller / Government Service
Uses an approved checkout or payment platform to submit a payment request and consume lifecycle status.
3
Checkout / Request-Submitter Backend
Calls MEMEH RTPO with a bearer credential, JSON idempotency_key, merchant_id, payer/payee aliases, amount, currency, and reference.
4
CAS Resolver
Keeps MEMEH RTPO’s canonical internal contract stable, manages the CAS V2 token, maps alias types, and validates default FinAddress responses.
5
Central Addressing Service (CAS V2)
Acts as the trusted external authority for aliases, financial addresses, and servicer identifiers.
6
Runtime Control Plane
Governs participants, CAS endpoints, routes, and adapters, then publishes the versioned snapshot consumed by Core.
7
MEMEH RTPO
Validates requests, consumes CAS results, builds canonical instructions, routes them, and tracks lifecycle.
8
Bank Adapter / Provider Connector
Posts the canonical request to the configured provider RTP API, stores correlation, and forwards provider lifecycle events to Core.
9
Provider RTP Platform and IPS
The participating provider owns payer consent and the standard RTP/IPS exchange; IPS remains the national switching rail.

Components

Enablement Portal

Access applications, documentation, credentials, UAT evidence, downloads, and audit support outside the Core runtime.

Control Plane

Publishes versioned approved provider routes and adapter bindings consumed by Core.

MEMEH RTPO

Payment-request validation, CAS result handling, canonical instruction routing, dispatch, and lifecycle state.

Central Addressing Service (CAS)

Authoritative payer and payee alias resolution into verified financial addresses and servicer identifiers.

Bank Adapter

Relays canonical requests, stores provider correlation, and forwards provider lifecycle events. It does not create IPS messages.

Provider RTP Platform and IPS

The provider owns customer consent and RTP processing; IPS executes the standard inter-participant exchange.

Request lifecycle

The same sequence shown in the diagram, mapped to stages 1–8.

  1. 1
    Checkout submits request
    The approved request submitter calls Core with a bearer credential and a JSON idempotency_key.
  2. 2
    Core validates and normalizes
    Core validates aliases, merchant identity, amount, currency, reference, description, and duplicate-request rules.
  3. 3
    CAS Resolver calls CAS V2
    The resolver authenticates with the assigned participant identity, maps MEMEH RTPO alias types, and obtains verified payer and payee FinAddresses from the Central Addressing Service.
  4. 4
    Published route is selected
    Core matches the CAS payee servicer to an active participant, route, and Bank Adapter from the Control Plane snapshot.
  5. 5
    Canonical instruction is dispatched
    Core persists one instruction and posts it to the selected Bank Adapter.
  6. 6
    Provider starts its RTP flow
    The adapter posts to the configured provider RTP API. The provider owns customer consent and IPS interaction.
  7. 7
    Provider returns lifecycle
    The provider posts a stable lifecycle event to the adapter; the adapter restores correlation and forwards it to Core.
  8. 8
    Core exposes outcome and history
    Core deduplicates the event, enforces the state machine, and serves current status plus immutable event history.

Security model

The current implementation uses boundary-specific credentials, TLS requirements for production configuration, request and event idempotency, rate limits, controlled enablement, and auditable runtime configuration.

Authentication

Public client APIs use an issued bearer key. Internal and participant boundaries use separately governed service credentials and verified TLS under restricted implementation contracts.

Duplicate protection

A required JSON idempotency_key protects payment creation; stable provider event_id values protect lifecycle processing. HMAC nonce signing is not currently implemented in Core.

Controlled enablement

The portal records applications, review decisions, sandbox credentials, signed partner invitations, downloads, and audit events. Production enablement remains a formal operational gate.

Read the Security guide →
© 2026 MEMEH RTPO — MEMEH Request-to-Pay Orchestrator
Developer & Integration Portal