MEMEH RTPO — Concepts

Platform concept

One Request-to-Pay platform, with clear ownership

MEMEH RTPO is the official Request-to-Pay orchestration platform of the Bank of Sierra Leone National Payment Switch. It gives approved businesses, billers, government services, payment platforms, and fintechs one standard way to request a customer payment while preserving the authority of the Central Addressing Service, participating providers, and IPS.

The central idea: MEMEH RTPO standardizes enablement, payment-request submission, trusted routing, provider connectivity, and lifecycle visibility. It does not take over alias ownership, payer consent, provider RTP processing, or the National Payment Switch.

Enable

Controlled access and readiness

Organizations apply, are reviewed, receive sandbox access, integrate, complete UAT, and pass readiness gates.

Orchestrate

Trusted request and route

Core validates the request, uses CAS results, applies the approved route, and creates one canonical instruction.

Connect and observe

Provider delivery and lifecycle

The Bank Adapter relays the instruction to the provider and returns authoritative lifecycle events to Core.

Current platform components

MEMEH RTPO is implemented as coordinated products and services. Each component has a distinct operational owner and data boundary.

Component	Current responsibility	Primary users or callers
Enablement Portal	Public documentation, access requests, administrator review, sandbox credentials, partner workspace, downloads, UAT guidance, and audit records.	Applicants, partner users, administrators, integrators
Runtime Control Plane	Governed participants, CAS endpoints, Bank Adapters, routing rules, change requests, approvals, audit logs, and published runtime snapshots.	Switch administrators, approvers, auditors, MEMEH RTPO
MEMEH RTPO	Authenticated request intake, validation, idempotency, CAS resolution, route selection, canonical instruction creation, adapter dispatch, lifecycle state, and event history.	Approved request submitters and Bank Adapters
Central Addressing Service (CAS)	Resolves payer and payee aliases into verified financial addresses and servicer identifiers.	MEMEH RTPO
Bank Adapter	Pushes Core instructions to the provider internal RTP API, stores correlation, receives provider events, and forwards them to Core.	MEMEH RTPO and provider RTP platform
Provider RTP platform	Owns customer consent, ISO 20022/RTP processing, the provider IPS connection, and authoritative outcomes.	Participating provider and its customers
IPS / National Switch	Executes the standard inter-participant Request-to-Pay and related payment flow.	Registered switch participants
Reference checkout and banking mock	Demonstrates request submission, payer OTP/consent, approval or rejection, callbacks, and status polling for local/UAT use.	Developers, testers, trainers

Enablement journey

This is the human and organizational journey before live API use. It is implemented in the Enablement Portal and remains separate from payment processing.

1 Discover The organization reviews the product, architecture, security, and relevant integration guide.
2 Apply It submits organization, contact, regulatory, use-case, volume, and environment information.
3 Review An authorized administrator records review notes and approves or rejects the request.
4 Activate For approved access, sandbox credentials are issued and a partner user receives a signed, expiring invitation.
5 Integrate The partner uses the workspace, credentials, documentation, downloads, and sandbox tools.
6 Certify The organization executes UAT, records evidence, closes defects, and completes production-readiness review.

The current portal records applications, decisions, sandbox credentials, partner invitations, downloads, and administrative audit events. Checklist progress beyond issued credentials is still guidance-driven and is not yet a persisted certification workflow.

Current Request-to-Pay journey

This is the implemented runtime journey from checkout to the provider-owned customer decision and back to the submitting platform.

Current end-to-end flow

Business / Biller / Government Service
  → Approved checkout or payment platform
  → POST /api/v1/payment-requests
  → MEMEH RTPO validates, normalizes, and applies idempotency
  → Central Addressing Service resolves payer and payee aliases
  → Control Plane snapshot supplies the approved payee-provider route
  → Core creates one canonical RTP initiation instruction
  → The instruction is delivered through the approved participant connection
  → Provider RTP platform owns consent and RTP/IPS processing
  → Customer approves or rejects through the provider-owned channel
  → Authoritative lifecycle events return through the participant connection
  → Core records current status and immutable event history
  → Request submitter polls status and events

Routing rule

The CAS-resolved payee servicer determines the eligible provider. A merchant-specific route may authorize that pairing but cannot redirect the request to a different servicer.

Completion rule

Adapter acceptance and ACSP are intermediate. ACSC is successful payment completion, while a later confirmed payment return becomes RETURNED. RJCT, CANC, and FAILED are terminal negative outcomes.

Ownership boundaries

These boundaries are part of the product design and prevent MEMEH RTPO from obstructing the standard IPS flow.

MEMEH RTPO does

Accept and deduplicate approved payment requests.
Use CAS-authoritative payer and payee financial addresses.
Use governed provider routes and adapter bindings.
Create a canonical provider instruction and track its lifecycle.
Provide enablement, documentation, sandbox, UAT, and audit support.

MEMEH RTPO does not

Become CAS or own alias master data.
Replace the National Payment Switch or become an IPS participant.
Take payer consent away from the participating provider.
Create IPS messages inside Core or the Bank Adapter.
Settle funds, hold wallet balances, or replace provider banking systems.

Key terms

Request submitter: An approved business, biller, government service, payment platform, or fintech that calls MEMEH RTPO directly or through its checkout backend.
Central Addressing Service (CAS): The trusted authority that resolves payer and payee aliases into verified financial addresses and servicer identifiers.
Canonical instruction: The versioned RTP initiation request Core creates after validation, CAS resolution, and approved route selection.
Control Plane snapshot: The published runtime configuration containing active participants, CAS endpoints, routes, and Bank Adapter targets.
Bank Adapter: The lightweight provider connector that relays Core instructions and provider lifecycle events.
Provider RTP platform: The participating provider system that owns payer consent, RTP/ISO 20022 processing, and the IPS connection.
Idempotency: The rule that an identical retry returns the original logical result without creating a second payment request or instruction.
Lifecycle event: A stable provider event, correlated by instruction and participant request identifiers, that advances the Core state machine.