Why MEMEH exists
MEMEH Core is a lightweight, API-first payment orchestration gateway for Request-to-Pay initiation. Payment platforms and fintechs submit a consistent payment-intent request without implementing direct IPS message complexity.
Multiple approved payment platforms use one stable authenticated API with a consistent canonical request format.
MEMEH resolves aliases through trusted CA/CAS and selects the active payee-side participant route from runtime configuration.
Request, alias-resolution, instruction, dispatch, callback, and lifecycle events can be reconstructed for support and audit.
What MEMEH is not
Clear boundaries prevent wrong assumptions during architecture and compliance reviews.
- × Not the onboarding workflow: MEMEH Core does not host participant onboarding or issue merchant-bank relationship contracts. This portal supports access enablement outside the Core runtime.
- × Not the Control Plane: Core consumes published runtime snapshots; it does not manually edit route or adapter records.
- × Not the CA/CAS: Core uses trusted alias-resolution services but does not become the trust authority.
- × Not a Bank Adapter: Core dispatches canonical instructions to adapters but does not implement bank-specific translation or IPS mechanics.
Operating model
The Core runtime path from payment intent to callback and event history.
Payment Platform
↓
MEMEH Core
↙ ↘
CA/CAS Control Plane Snapshot
↓
Canonical Instruction
↓
Bank Adapter
↓
Payee Participant / IPS
↓
Callbacks → MEMEH → PlatformSends an authenticated, idempotent payment-intent request and consumes lifecycle status.
Validates, resolves aliases, builds the canonical instruction, selects the route, and dispatches.
Initiates the pain.013 path and returns standard RTP lifecycle updates.
Key terms
Definitions used across the documentation. Keep these consistent in engineering, ops, and compliance reviews.
The normalized payload containing verified financial addresses, amount, currency, reference, and platform context.
The trusted alias-resolution authority that produces verified financial addresses and servicer identifiers.
The published runtime configuration Core consumes to select active participant routes and adapters.
The integration boundary that communicates with the payee-side participant and IPS path.
The deduplicated record of inbound status updates used to validate transitions and close the lifecycle.
The retry guarantee that returns the original result without creating a second dispatch.