Who should start here

The platform in one minute

MEMEH RTPO is the Request-to-Pay orchestration platform of the Bank of Sierra Leone National Payment Switch. It gives approved request submitters one canonical API, resolves payer and payee aliases through the Central Addressing Service, routes the request to the payee's participating provider, and tracks the lifecycle returned by that provider.

Enablement journey

1. 1. Understand the model.

   Review Concepts, Architecture, Security, and the guide for your role.

2. 2. Request access.

   Submit the public form with organization, use case, technical contact, bank/provider relationship, and requested environment.

3. 3. Complete review.

   The MEMEH RTPO administrator reviews, requests clarification where needed, records the decision, and issues a signed invitation for approved applicants.

4. 4. Enter the workspace.

   Accept the invitation, change the temporary password, receive sandbox credentials and approved downloads, and follow the role checklist.

5. 5. Integrate and test.

   Implement the current API contract, execute positive and negative UAT cases, and retain correlation and lifecycle evidence.

6. 6. Obtain production approval.

   Production credentials and routing publication follow separate security, operational-readiness, and change-approval controls.

Runtime journey

1. 1. Submit: the approved business, biller, government service, payment platform, or fintech sends payer alias, payee alias, merchant identity, amount, currency, reference, and idempotency key to MEMEH RTPO.
2. 2. Resolve: Core normalizes the aliases and asks the Central Addressing Service to resolve both parties to trusted financial addresses and servicers.
3. 3. Route: the payee servicer returned by the Central Addressing Service selects an approved participant route from the published Control Plane snapshot. The caller cannot override it.
4. 4. Dispatch: Core builds a canonical initiation instruction and posts it to the selected participant's Bank Adapter.
5. 5. Initiate: the adapter pushes the canonical request to the provider's configured internal RTP platform. The provider owns ISO 20022, customer consent, and IPS processing.
6. 6. Decide: the payer approves or rejects through their bank, mobile money operator, or fintech channel.
7. 7. Report: the provider posts lifecycle events to the adapter; the adapter correlates and forwards them to Core.
8. 8. Track: the request submitter polls current status and event history. Only ACSC is completed; ACSP remains in progress.

First request

The current Core API uses a bearer key and a JSON idempotency key. HTTP 202 confirms orchestration and dispatch acceptance, not payment completion.

curl -i -X POST "${MEMEH_CORE_URL}/api/v1/payment-requests" \
  -H "Authorization: Bearer ${MEMEH_CORE_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "idempotency_key": "govpay-20260730-0001",
    "payer_alias": "+23276123456",
    "payee_alias": "govpay@sandbox.sl",
    "merchant_id": "GOVPAY-SL",
    "amount": "250.00",
    "currency": "SLE",
    "reference": "TAX-2026-0001",
    "description": "Government service payment"
  }'

{
  "request_id": "2a838d95-38cc-45cf-98fc-635fb1157ce1",
  "status": "DISPATCHED",
  "normalized_aliases": {
    "payer": "+23276123456",
    "payee": "govpay@sandbox.sl"
  },
  "inferred_types": {
    "payer": "MSISDN",
    "payee": "EMAIL"
  },
  "dispatch": {
    "status": "DISPATCHED",
    "http_status": 202
  }
}