MEMEH — RTP Guide

RTP Guide

This page explains how MEMEH handles RTP status updates and what partner applications should consume. It is an implementation guide (simplified). The RTP specification remains the canonical reference.

pain.014.001.10 Bank → MEMEH

One truth

MEMEH treats the RTP status code as the single lifecycle truth. Internals may contain more detail, but partner contracts stay stable.

Partner safety

Partners should not parse ISO 20022 objects. MEMEH forwards a simplified message: status + optional reason.

Fulfilment rule

ACSP is the only state that implies “paid” and safe to fulfil. Everything else is pending or terminal negative.

Bank integration → Fintech integration → Open callback simulator

Lifecycle

The lifecycle is intentionally small. These are the outcomes partners need to implement reliably.

ISO code	Business label	Meaning	Merchant action	Terminal
RCVD	RECEIVED	Request to Pay received/acknowledged by the ecosystem. Awaiting payer action or completion.	Show Pending. Do not fulfil.	No
ACSP	PAID	Payment completed and confirmed. This is the fulfilment confirmation.	Fulfil / deliver.	Yes
RJCT	REJECTED	Request was rejected (payer declined or validation failed). Include a reason code.	Stop. Do not fulfil. Show reason.	Yes
CANC	CANCELLED	Request was cancelled. Reason is optional depending on flow.	Stop. Mark cancelled.	Yes

Operational note

Avoid inventing extra states in partner payloads. If a bank reports an error, represent it as RJCT with a reason.

Status codes

Bank/adapter systems typically set TxSts and often mirror it in GrpSts. MEMEH stores the status code and maps it to a partner-friendly status.

RCVD — Received

Acknowledged; awaiting payer decision or completion. Not safe to fulfil.

ACSP — Paid

Completed. This is the fulfilment confirmation used by merchant applications.

RJCT — Rejected

Final negative outcome. Include a reason code wherever possible.

CANC — Cancelled

Final termination. Reason optional depending on flow.

Reason codes

Negative outcomes can include a reason via StsRsnInf → Rsn → Prtry plus optional AddtlInf. MEMEH forwards the reason to partners as reason_code and may include a safe message.

DCBP

Declined by payer

LTXD

Limit exceeded / insufficient funds

ORXP

Original RTP expired

ORPD

Original RTP already paid

TXTO

Timeout / delivery failure

TNFN

Transaction not found

INVC

Invalid currency / amount

DTID

Duplicate transaction ID

RQNF

Request not found

ORCD

Original RTP already cancelled

ORDC

Original RTP already declined

ICRQ

Invalid cancel request

IDRQ

Invalid decline request

MEMEH mapping

ISO-aligned input from bank/adapter is stored and normalized. Partners receive a stable contract.

ISO to partner mapping

TxSts / GrpSts	Partner status	What it means
RCVD	RECEIVED	Acknowledged; pending payer action.
ACSP	PAID	Completed; fulfilment confirmation.
RJCT	REJECTED	Rejected; include reason code.
CANC	CANCELLED	Cancelled; terminated.

Recommended partner contract

Partners should implement exactly one lifecycle field: status_code, and optionally reason_code for negative states.

Partner payload (shape)

{
                                  "rtp_id": "TXN-123",
                                  "status": "PAID|RECEIVED|REJECTED|CANCELLED",
                                  "status_code": "ACSP|RCVD|RJCT|CANC",
                                  "reason_code": "DCBP|LTXD|...|null",
                                  "message": "safe message",
                                  "event_time": "ISO-8601"
                                }

Bank/adapter input (simplified snippet)

pain.014 fields (JSON mapping)

{
  "OrgnlGrpInfAndSts": { "GrpSts": "RJCT" },
  "OrgnlPmtInfAndSts": {
    "TxInfAndSts": {
      "OrgnlEndToEndId": "TXN-123",
      "OrgnlUETR": "ef73139a-2efb-4279-aa27-5d9b350121cb",
      "TxSts": "RJCT",
      "StsRsnInf": {
        "Rsn": { "Prtry": "DCBP" },
        "AddtlInf": "Declined by payer"
      }
    }
  }
}

Partner output (paid example)

Partner notification

{
  "rtp_id": "TXN-123",
  "status": "PAID",
  "status_code": "ACSP",
  "reason_code": null,
  "message": "Payment confirmed (paid). You may fulfil/deliver.",
  "event_time": "2026-03-28T05:42:41Z"
}

Examples

Partners should implement these three cases and treat them as contract tests.

Received (RCVD)

Pending state. No fulfilment.

Partner notification

{
  "rtp_id": "TXN-123",
  "status": "RECEIVED",
  "status_code": "RCVD",
  "reason_code": null,
  "message": "Request received and acknowledged. Awaiting payer action.",
  "event_time": "2026-03-28T05:41:02Z"
}

Paid (ACSP)

Fulfilment confirmation.

Partner notification

{
  "rtp_id": "TXN-123",
  "status": "PAID",
  "status_code": "ACSP",
  "reason_code": null,
  "message": "Payment confirmed (paid). You may fulfil/deliver.",
  "event_time": "2026-03-28T05:42:41Z"
}

Rejected (RJCT)

Terminal negative. Include reason.

Partner notification

{
  "rtp_id": "TXN-123",
  "status": "REJECTED",
  "status_code": "RJCT",
  "reason_code": "DCBP",
  "message": "Request to Pay rejected. Do not fulfil.",
  "event_time": "2026-03-28T05:44:02Z"
}

Implementation checklist

• Treat ACSP as the only fulfilment confirmation.
• Render RCVD as “Pending”. Do not fulfil.
• For RJCT, store and display the reason code (and safe message).
• Make status updates idempotent per RTP identifier and event time.

Glossary

ISO 20022 field meanings used in RTP status updates. This glossary is shared across the portal for consistency.

Glossary

Plain English meaning of common ISO 20022 fields used in RTP status updates. Partners should consume the MEMEH notification payload rather than parsing ISO fields.

GrpSts / TxSts

Group status and transaction status. MEMEH uses these as the authoritative lifecycle state: RCVD, RJCT, CANC, ACSP.

OrgnlMsgId / OrgnlMsgNmId

Correlation back to the original request message (usually pain.013). Used for traceability and audit.

OrgnlPmtInfId / OrgnlInstrId

References the original payment information block and instruction identifiers used by the bank/rail.

OrgnlEndToEndId

The RTP identifier recognized across participants (what your app typically stores as the RTP reference).

OrgnlUETR

Unique end-to-end transaction reference (UUIDv4). Used for cross-system correlation and dispute traceability.

StsRsnInf → Rsn → Prtry + AddtlInf

Status reason. Prtry is the reason tag and AddtlInf is optional human-readable detail. Mainly used for RJCT (rejected).

Tip: In MEMEH, the partner-facing contract is a single status + optional reason. ISO 20022 fields remain an internal/adapter concern.