Current security model
MEMEH RTPO applies controls at each platform boundary instead of relying on one credential for the entire journey. The contracts below describe the current code. HMAC nonce signing and Ed25519 message signatures are not implemented in the current MEMEH RTPO API and must not be treated as integration requirements.
Client, platform-service, Central Addressing Service, and participant credentials are configured independently.
The services enforce JSON content types, request-size limits, timeouts, bounded responses, rate limits, secure headers, and structured validation.
The caller cannot choose a provider route. Core uses the Central Addressing Service payee servicer and the approved runtime snapshot.
Stable event identifiers, correlation checks, an inbox record, and an explicit state machine protect lifecycle processing.
Boundary controls
Credentials must be unique per environment, stored outside source control, rotated under change control, and transmitted only over approved TLS connections in deployed environments.
| Boundary | Current control | Wire contract | Purpose |
|---|---|---|---|
| Request submitter to MEMEH RTPO | Bearer API key | Authorization: Bearer <MEMEH_CORE_API_KEY> | Protects alias, payment-request, status, and event-history APIs. |
| CAS Resolver to Central Addressing Service V2 | CAS participant identity and access token | participant-id + Authorization over verified TLS | Protects authenticated alias-to-FinAddress lookups. Tokens are cached and refreshed once after HTTP 401. |
| MEMEH RTPO internal services | Isolated service credentials and verified TLS | Private service contract | Protects runtime configuration, alias resolution, routing, and orchestration boundaries. |
| Financial service participant connection | Participant-specific authentication and verified TLS | Restricted participant contract | Protects canonical instruction delivery and lifecycle-event return. |
Duplicate and lifecycle safety
Every payment request carries a JSON idempotency_key. Reusing it with the same logical payload returns the original request; conflicting reuse returns HTTP 409.
Provider platforms must send a stable event_id. Core records callback intake and prevents repeated processing of the same event.
The lifecycle event identifies the original instruction_id and request. Core validates the transition before changing current state.
| Current state | Allowed next state | Terminal |
|---|---|---|
| RECEIVED | ROUTABLE, FAILED | No |
| ROUTABLE | DISPATCHED, FAILED | No |
| DISPATCHED | PDNG, RCVD, ACSP, ACSC, RJCT, CANC, FAILED | No |
| PDNG / RCVD | Progress or a final outcome | No |
| ACSP | ACSC, RJCT, CANC | No |
| ACSC | RETURNED only | No* |
| RETURNED / RJCT / CANC / FAILED | None | Yes |
Enablement Portal controls
Laravel Fortify and Jetstream sessions, verified accounts, role middleware, forced password change, and signed expiring partner invitations protect the human workflow.
Administrative review, credential issuance, download management, and invitation acceptance create audit records with actor and request context.
Rate limiting, validation, safe file handling, and controlled status changes reduce abuse of the public access-request path.
Sandbox access does not imply production approval. Production credentials and routing publication require separate operational authorization.
Production hardening requirements
These are deployment and governance requirements around the current contracts. They do not change the Request-to-Pay flow.
- Use a managed secrets store and rotate every environment-specific key.
- Require TLS; use mTLS at institutional boundaries where the deployment profile permits it.
- Restrict Core, Control Plane, Central Addressing Service, adapter, and provider routes with network policy.
- Centralize logs and alerts without recording aliases, financial addresses, credentials, or authorization headers.
- Run one active adapter instance with its SQLite database on encrypted persistent local storage. Do not place the database on a network-shared filesystem.
- Monitor durable callback backlog age and retained delivery exceptions, and govern replay through an approved operations process.
- Run dependency, static-analysis, container, and penetration checks before release.
- Treat HMAC or public-key message signing as a future approved contract change, not a current client requirement.