Where MEMEH RTPO meets Request-to-Pay
MEMEH RTPO does not replace the National Payment Switch Request-to-Pay flow. It prepares and routes a canonical instruction to the payee's participating provider, then monitors the authoritative lifecycle returned by that provider. The payee provider owns RTP initiation and creditor-side IPS communication. The payer provider owns customer presentation, approval or rejection, and the linked payment after approval.
A request submitter does not send pain.013 to IPS through MEMEH RTPO.
The payee's registered participant receives MEMEH RTPO's canonical initiation instruction and uses its own RTP platform
to perform the standard switch interaction.
End-to-end journey
- 1. Payment request: a business, biller, government service, payment platform, or fintech submits payer and payee aliases, amount, merchant identity, reference, and idempotency key.
- 2. Trusted resolution: MEMEH RTPO resolves both aliases through the Central Addressing Service and obtains their financial addresses and servicers.
- 3. Provider selection: the payee servicer returned by the Central Addressing Service selects the active participant and adapter route from the published Control Plane snapshot.
- 4. Canonical dispatch: MEMEH RTPO delivers the canonical initiation request through the approved participant connection.
- 5. Provider trigger: the adapter pushes the same business instruction to the provider's configured internal API.
- 6. RTP request: the payee/creditor participant's RTP platform sends pain.013 through IPS to the payer/debtor participant.
- 7. RTP response: the payer participant returns pain.014. A received or accepted response is still not payment completion.
- 8. Payer decision and payment: after customer approval, the payer participant sends the linked pacs.008 payment through IPS.
- 9. Payment outcome: the provider observes the authoritative pacs.002 status and normalizes the business outcome.
- 10. Lifecycle return: the provider posts each material canonical event to the adapter. The adapter correlates it to the original MEMEH RTPO instruction and forwards it to Core.
- 11. Status visibility: Core validates the transition, stores the event, updates current state, and exposes status and history to the request submitter.
System ownership
| System | Owns | Does not own |
|---|---|---|
| Request submitter | Customer-facing request context, retry key, polling, fulfilment decision after completion. | Provider route, financial-address authority, ISO/IPS processing. |
| MEMEH RTPO Platform | Enablement, alias resolution, approved routing, canonical orchestration, correlation, monitoring, audit. | Payer consent, RTP scheme processing, settlement, participant customer records. |
| Bank Adapter | Authenticated transport, validation, provider push, correlation, lifecycle relay. | pain.013, pacs.008, IPS connection, customer approval. |
| Payee/creditor provider | RTP initiation, creditor-side ISO 20022 processing, IPS interaction, and lifecycle observation. | Payer approval or linked-payment origination. |
| Payer/debtor provider | Customer presentation and approval, pain.014 response, and linked pacs.008 after approval. | MEMEH RTPO routing or merchant enablement. |
| National switch / IPS | Standard participant-to-participant RTP and payment rail. | MEMEH RTPO portal access and request-submitter integration. |
Lifecycle states
Core also uses RECEIVED, ROUTABLE, and DISPATCHED for its internal orchestration stages.
| Code | Meaning | Operational interpretation | Terminal |
|---|---|---|---|
| PDNG | Pending | Provider processing or payer action remains outstanding. | No |
| RCVD | Received | The provider acknowledged the Request-to-Pay lifecycle message. | No |
| ACSP | Accepted for processing | Processing continues. This is not payment completion. | No |
| ACSC | Completed | The provider reports successful payment completion. A later confirmed return may supersede this state. | No* |
| RETURNED | Returned | A previously completed payment was confirmed returned. | Yes |
| RJCT | Rejected | The Request-to-Pay or linked payment was rejected. | Yes |
| CANC | Cancelled | The Request-to-Pay lifecycle was cancelled. | Yes |
| FAILED | Failed | MEMEH RTPO recorded an unrecoverable orchestration or downstream failure. | Yes |
Do not fulfil on DISPATCHED, RCVD, or
ACSP. The current Core state machine treats only
ACSC as successful completion. A later confirmed return moves
that completed payment to RETURNED.
RTP message-to-lifecycle crosswalk
These messages are created and exchanged by participating provider RTP platforms and IPS. MEMEH RTPO does not generate them. The provider reports the observed message in message_type and supplies the normalized business state in status.
| Observed message | What happened | MEMEH RTPO treatment |
|---|---|---|
| pain.013.001.10 | Payee/creditor participant submitted the RTP request. | Keep active. Sending a request is not payment completion. |
| pain.014.001.10 | Payer/debtor participant returned RTP progress or outcome. | Apply the provider state, such as RCVD, ACSP, or RJCT. Do not infer ACSC. |
| pacs.008.001.10 | Payer participant submitted the approved linked payment. | Keep active until the authoritative payment status is known. |
| pacs.002 | Payment status was reported. | Use the authoritative outcome. ACSC is successful completion; RJCT is rejection. |
| pacs.028.001.05 | A participant requested current payment status. | Inquiry only; apply the status returned by the provider. |
| camt.055.001.10 | The RTP initiator requested cancellation. | Keep active. Do not set CANC before confirmation. |
| camt.029.001.10 | The cancellation result was reported. | Set CANC only when cancellation is confirmed. |
| pacs.004.001.11 | A completed payment was returned. | Set RETURNED only after the return is confirmed. |
| acmt.023.001.03 | Supporting account verification was requested. | Verification evidence only; never payment completion. |
Canonical lifecycle event
The provider platform posts the first shape to the adapter. The adapter supplies trusted participant identity, preserves correlation, and publishes the second shape to Core. message_type records the provider-observed standard message; MEMEH RTPO does not generate or route that message.
Provider to adapter
{
"schema_version": "1.0",
"event_id": "provider-event-0003",
"participant_request_id": "provider-rtp-90041",
"instruction_id": "inst-8a10",
"request_id": "2a838d95-38cc-45cf-98fc-635fb1157ce1",
"rtp_id": "rtp-90041",
"status": "RCVD",
"message_type": "pain.014.001.10",
"reason_code": "",
"reason": "",
"occurred_at": "2026-07-30T09:00:18Z"
}
Adapter to Core
{
"schema_version": "1.0",
"event_id": "provider-event-0003",
"instruction_id": "inst-8a10",
"request_id": "2a838d95-38cc-45cf-98fc-635fb1157ce1",
"rtp_id": "rtp-90041",
"participant_code": "PAYEE-BANK",
"source": "BANK_RTP_PLATFORM",
"message_type": "pain.014.001.10",
"status": "RCVD",
"reason": "",
"occurred_at": "2026-07-30T09:00:18Z"
}
This example records an RTP response as RCVD. A successful linked
payment completion is reported separately with message_type: pacs.002
and status: ACSC.
Implementation rules
- Use a stable, globally unique event_id for every provider event.
- Return the adapter's participant_request_id on every lifecycle update.
- Preserve instruction_id and request_id when available.
- Use the provider's authoritative status; never infer completion from HTTP 202.
- Do not infer completion from pain.014 or from sending pacs.008.
- Use RETURNED only after a return of a completed payment is confirmed.
- Send UTC occurred_at and a safe reason for negative outcomes.
- Retry callback publication with the same event ID; do not create a new event identity for a transport retry.