Electrum Regulated Payments Partner API (26.1.1)

The Electrum Regulated Payments API is an asynchronous API that allows partners to participate in various nationally regulated payment schemes.

As the Regulated Payments API is asynchronous, partners have a choice of how to integrate with Electrum:

  • Webhooks: Electrum will send events to the partner containing inbound payments to action, or responses to outbound payment requests. Webhooks are defined in the Electrum Regulated Payments Partner API.
  • Partner API: Electrum will call operations exposed by the partner containing inbound payments to action, or responses to outbound payment requests. The operations are defined in this document.

Receiving transactional events via webhooks or API are equivalent, except that it may be more familiar or convenient to implement one style or the other.

This document describes the operations a partner must implement for Electrum to consume in order to complete the integration with the Electrum Regulated Payments API.

Languages
Servers
Partner API sandbox

https://example.com/path/payments/partner-api/v1/

transactional

Operations that participate in transaction processing, which may or may not have financial impact.

Operations

financial

Operations that participate in transaction processing and have financial impact.

Operations

credit-transfer

Operations related to credit transfer transactions.

Operations

direct-debit

Operations related to direct debit transactions.

Operations

payment-return

Operations related to payment returns.

Operations

identifier-determination

Operations used to retrieve additional information related to an identifier

Operations

funds-management

Operations related to the management of funds, including reservations, postings, and voiding of reservations.

Operations

risk-assessment

Operations related to the assessment and identification of risk in transactions.

Operations

fraud-assessment

Operations related to the processing of fraud assessments for payment transactions.

Operations

account-management

Operations that involve customer account information.

Operations

sanctions-assessment

Operations related to the processing of sanctions assessment for payment transactions.

Operations

mandate-management

Operations related to the lifecycle management of direct debit mandates.

Operations

Schema

CustomerPaymentStatusReportPaymentScheme

Designates which scheme a customer payment status report is associated with and describes scheme-specific information for the customer payment status report.

schemastring(PaymentSchemeName)required

Identifies the scheme used for the payment

  • ZA_RTC: South African Realtime Clearing scheme.
  • ZA_RPP: South African Realtime Payments Platform scheme.
  • ZA_EFT: South African Electronic Funds Transfer scheme.
  • ZA_AC : South African Authenticated Collections scheme.
  • ZA_RMS: South African Registered Mandate Service scheme.
  • CBPR_PLUS: Cross-Border Payments and Reporting Plus.
Enum"ZA_RTC""ZA_RPP""ZA_EFT""ZA_AC""ZA_RMS""CBPR_PLUS"
Discriminator
schemeDataobject(ZaAcCustomerPaymentStatusReportPaymentSchemeData)required

The mandateRequestTransactionIdentifier and suspensionRequestIdentification are mutually exclusive fields

  • If the status report is responding to a standard mandate operation (Initiation, Amendment, Cancellation), it echoes the MRTI.
  • If the status report is responding to a Suspension, it echoes the Suspension Request Identification.
schemeData.​mandateRequestTransactionIdentifierstring(MandateRequestTransactionIdentifier)<= 35 characters^\d{4}\d{4}-\d{2}-\d{2}\d{9}$

Mandate Request Transaction Identifier (MRTI) A unique transaction identifier used for matching multiple messages to a single transaction. This identifier is created for each new mandate request to uniquely identify the transaction within the Authenticated Collections scheme.

Important: Usage of mandateRequestTransactionIdentifier**.

  • If the client is the host of the mandate register and is the source of truth for mandate state the client is required to always populate the MRTI. The format is validated and the provided MRTI is used by Electrum.
  • If Electrum is the source of truth for mandate state the MRTI should not be provided by the client when initiating new mandate transactions; Electrum will generate a compliant MRTI automatically which will be echoed back to the client.

Structure (23 characters):

  • Positions 1–4 (4 numeric): Originating bank number. Must be a valid, registered bank.
  • Positions 5–14 (10 alphanumeric): Origination date in the format YYYY-MM-DD. Must be a valid date.
  • Positions 15–23 (9 numeric): Mandate sequence number. Unique within the bank and date.

Lifecycle behaviour:

  • Mandate Initiation Request: The originating bank creates a new, unique MRTI for the initiation request. If not provided by the client, Electrum generates one automatically.
  • Mandate Amendment Request: A new, unique MRTI is required for the amendment request. If not provided by the client, Electrum generates one automatically. The amendment is linked back to the original mandate using the Mandate Reference Number (MRN).
  • Mandate Cancellation Request:
    • In-flight cancellation: If cancelling a mandate request that is still in-flight (e.g. awaiting debtor authentication), the MRTI must exactly match the MRTI of the in-flight request being cancelled. If not provided, Electrum handles this automatically by retrieving the MRTI of the in-flight transaction.
    • Active mandate cancellation: If the mandate is already fully registered and active, a new, unique MRTI must be issued for the cancellation request. If not provided, Electrum determines the mandate state and applies the correct rule automatically.
  • Mandate Acceptance Report: The response echoes back the MRTI from the request being responded to. For API-level correlation, clients use originalMessageIdentifiers.messageIdentification instead.
  • Mandate Status Report: The status report echoes back the MRTI from the request being reported on. For API-level correlation, clients use originalMessageIdentifiers.messageIdentification instead.

Validation rules enforced by the scheme:

  • Must not be blank or spaces.
  • The bank number (positions 1–4) must be a valid, registered bank.
  • The date (positions 5–14) must be a valid calendar date.
  • Must conform to the 23-character structured format.
  • Must be unique at the time of request origination.
schemeData.​requestTransmissionNumberinteger(MandatePaymentSchemeRequestTransmissionNumber)[ 1 .. 4 ]

Sequence number for the message's transmission. Used exclusively for real-time (TT1/TT3) messages to track message retries. 1 = original message transmission, 2-4 = retries.

schemeData.​suspensionRequestIdentificationstring(MandateSuspensionRequestIdentification)<= 35 characters^STP/\d{4}/20\d{2}-\d{2}-\d{2}/\d{9}$

Suspension Request Identification A unique transaction identifier used to unambiguously identify the mandate suspension request to the clearing house.

Important: Usage of suspensionRequestIdentification**.

  • If the client is the host of the mandate register and is the source of truth for mandate state the client is required to always populate the suspensionRequestIdentification in the MandateSuspensionRequest. The format is validated and the provided suspensionRequestIdentification is used by Electrum.
  • If Electrum is the source of truth for mandate state the suspensionRequestIdentification should not be provided by the client when initiating new mandate suspension; Electrum will generate a compliant suspensionRequestIdentification automatically which will be echoed back to the client.

Lifecycle behaviour:

  • Mandate Suspension Request: The originating bank creates a new, unique suspensionRequestIdentification for the suspension request. If not provided by the client, Electrum generates one automatically.
  • Customer Payment Status Report: The suspensionRequestIdentification is echoed in CustomerPaymentStatusReports that confirm the outcome of a mandate suspension.

Structure (29 characters): The identifier is composed of 4 components separated by forward slashes (/), matching the pattern STP/<BankCode>/<Date>/<Sequence>:

  • Prefix (STP): Fixed string indicating a Suspension.
  • Bank Code (4 numeric): The 4-digit identifier of the initiating bank.
  • Date (10 alphanumeric): The date the suspension is generated in YYYY-MM-DD format.
  • Sequence Number (9 numeric): Mandate Suspension sequence number. Must be unique within the bank and date.
{ "schema": "ZA_AC", "schemeData": { "mandateRequestTransactionIdentifier": "string", "requestTransmissionNumber": 1, "suspensionRequestIdentification": "string" } }

CustomerPaymentStatusReport

An extension of BaseMessage which includes additional information pertinent to an asynchronous response message. In particular, original message identifiers.

messageIdentifiersobject(MessageIdentifiers)required

Holds a point-to-point unique message identification string as well as a message's creation date time.

messageIdentifiers.​creationDateTimestring(date-time)required

The date and time at which the message was created, in senders local timezone or UTC. The date must be formatted as defined by date-time in RFC3339

messageIdentifiers.​messageIdentificationstring<= 35 charactersrequired

A reference used to unambiguously identify the message between the sending and receiving party. Take note that this uniquely identifies a single message in a potentially multi-message exchange to complete a payment.

supplementaryDataobject(SupplementaryData)

A list of key-value pairs to support adding any supplementary/additional data to an Electrum Regulated Payments API message.

originalMessageIdentifiersobject(MessageIdentifiers)required

Holds a point-to-point unique message identification string as well as a message's creation date time.

originalMessageIdentifiers.​creationDateTimestring(date-time)required

The date and time at which the message was created, in senders local timezone or UTC. The date must be formatted as defined by date-time in RFC3339

originalMessageIdentifiers.​messageIdentificationstring<= 35 charactersrequired

A reference used to unambiguously identify the message between the sending and receiving party. Take note that this uniquely identifies a single message in a potentially multi-message exchange to complete a payment.

instructedAgentobject(InstitutionIdentification)
instructingAgentobject(InstitutionIdentification)
mandateInformationobject(MandateInformation)

Provides a reference to the direct debit mandate signed between the creditor and the debtor.

Note: This model is not relevant to the ZA_EFT scheme. Electrum will not process these fields for EFT payments (e.g. tracking days are not honoured for EFT).

originalMessageNameIdentificationstring<= 35 charactersrequired

Specifies the original message name identifier to which the message refers. In ELPAPI, this should be the ELPAPI message type name (e.g. MandateInitiationRequest, MandateAmendmentRequest, CreditTransfer).

paymentSchemeobject(CustomerPaymentStatusReportPaymentScheme)required

Designates which scheme a customer payment status report is associated with and describes scheme-specific information for the customer payment status report.

paymentScheme.​schemastring(PaymentSchemeName)required

Identifies the scheme used for the payment

  • ZA_RTC: South African Realtime Clearing scheme.
  • ZA_RPP: South African Realtime Payments Platform scheme.
  • ZA_EFT: South African Electronic Funds Transfer scheme.
  • ZA_AC : South African Authenticated Collections scheme.
  • ZA_RMS: South African Registered Mandate Service scheme.
  • CBPR_PLUS: Cross-Border Payments and Reporting Plus.
Enum"ZA_RTC""ZA_RPP""ZA_EFT""ZA_AC""ZA_RMS""CBPR_PLUS"
Discriminator
paymentScheme.​schemeDataobject(ZaAcCustomerPaymentStatusReportPaymentSchemeData)required

The mandateRequestTransactionIdentifier and suspensionRequestIdentification are mutually exclusive fields

  • If the status report is responding to a standard mandate operation (Initiation, Amendment, Cancellation), it echoes the MRTI.
  • If the status report is responding to a Suspension, it echoes the Suspension Request Identification.
paymentScheme.​schemeData.​mandateRequestTransactionIdentifierstring(MandateRequestTransactionIdentifier)<= 35 characters^\d{4}\d{4}-\d{2}-\d{2}\d{9}$

Mandate Request Transaction Identifier (MRTI) A unique transaction identifier used for matching multiple messages to a single transaction. This identifier is created for each new mandate request to uniquely identify the transaction within the Authenticated Collections scheme.

Important: Usage of mandateRequestTransactionIdentifier**.

  • If the client is the host of the mandate register and is the source of truth for mandate state the client is required to always populate the MRTI. The format is validated and the provided MRTI is used by Electrum.
  • If Electrum is the source of truth for mandate state the MRTI should not be provided by the client when initiating new mandate transactions; Electrum will generate a compliant MRTI automatically which will be echoed back to the client.

Structure (23 characters):

  • Positions 1–4 (4 numeric): Originating bank number. Must be a valid, registered bank.
  • Positions 5–14 (10 alphanumeric): Origination date in the format YYYY-MM-DD. Must be a valid date.
  • Positions 15–23 (9 numeric): Mandate sequence number. Unique within the bank and date.

Lifecycle behaviour:

  • Mandate Initiation Request: The originating bank creates a new, unique MRTI for the initiation request. If not provided by the client, Electrum generates one automatically.
  • Mandate Amendment Request: A new, unique MRTI is required for the amendment request. If not provided by the client, Electrum generates one automatically. The amendment is linked back to the original mandate using the Mandate Reference Number (MRN).
  • Mandate Cancellation Request:
    • In-flight cancellation: If cancelling a mandate request that is still in-flight (e.g. awaiting debtor authentication), the MRTI must exactly match the MRTI of the in-flight request being cancelled. If not provided, Electrum handles this automatically by retrieving the MRTI of the in-flight transaction.
    • Active mandate cancellation: If the mandate is already fully registered and active, a new, unique MRTI must be issued for the cancellation request. If not provided, Electrum determines the mandate state and applies the correct rule automatically.
  • Mandate Acceptance Report: The response echoes back the MRTI from the request being responded to. For API-level correlation, clients use originalMessageIdentifiers.messageIdentification instead.
  • Mandate Status Report: The status report echoes back the MRTI from the request being reported on. For API-level correlation, clients use originalMessageIdentifiers.messageIdentification instead.

Validation rules enforced by the scheme:

  • Must not be blank or spaces.
  • The bank number (positions 1–4) must be a valid, registered bank.
  • The date (positions 5–14) must be a valid calendar date.
  • Must conform to the 23-character structured format.
  • Must be unique at the time of request origination.
paymentScheme.​schemeData.​requestTransmissionNumberinteger(MandatePaymentSchemeRequestTransmissionNumber)[ 1 .. 4 ]

Sequence number for the message's transmission. Used exclusively for real-time (TT1/TT3) messages to track message retries. 1 = original message transmission, 2-4 = retries.

paymentScheme.​schemeData.​suspensionRequestIdentificationstring(MandateSuspensionRequestIdentification)<= 35 characters^STP/\d{4}/20\d{2}-\d{2}-\d{2}/\d{9}$

Suspension Request Identification A unique transaction identifier used to unambiguously identify the mandate suspension request to the clearing house.

Important: Usage of suspensionRequestIdentification**.

  • If the client is the host of the mandate register and is the source of truth for mandate state the client is required to always populate the suspensionRequestIdentification in the MandateSuspensionRequest. The format is validated and the provided suspensionRequestIdentification is used by Electrum.
  • If Electrum is the source of truth for mandate state the suspensionRequestIdentification should not be provided by the client when initiating new mandate suspension; Electrum will generate a compliant suspensionRequestIdentification automatically which will be echoed back to the client.

Lifecycle behaviour:

  • Mandate Suspension Request: The originating bank creates a new, unique suspensionRequestIdentification for the suspension request. If not provided by the client, Electrum generates one automatically.
  • Customer Payment Status Report: The suspensionRequestIdentification is echoed in CustomerPaymentStatusReports that confirm the outcome of a mandate suspension.

Structure (29 characters): The identifier is composed of 4 components separated by forward slashes (/), matching the pattern STP/<BankCode>/<Date>/<Sequence>:

  • Prefix (STP): Fixed string indicating a Suspension.
  • Bank Code (4 numeric): The 4-digit identifier of the initiating bank.
  • Date (10 alphanumeric): The date the suspension is generated in YYYY-MM-DD format.
  • Sequence Number (9 numeric): Mandate Suspension sequence number. Must be unique within the bank and date.
schemastringrequired
Value"CustomerPaymentStatusReport"
statusobject(Status)required
status.​outcomestringrequired
  • APPROVED: The instruction has been approved.
  • CANCELLED: The instruction has been cancelled.
  • PENDING: The instruction is pending.
  • REJECTED: The instruction has been rejected.
Enum"APPROVED""CANCELLED""PENDING""REJECTED"
status.​reasonInfoArray of objects(StatusReasonInfo)non-empty

A list of StatusReasonInfo values providing detailed reason information for the outcome.

{ "messageIdentifiers": { "creationDateTime": "2019-08-24T14:15:22Z", "messageIdentification": "string" }, "supplementaryData": { "property1": "string", "property2": "string" }, "originalMessageIdentifiers": { "creationDateTime": "2019-08-24T14:15:22Z", "messageIdentification": "string" }, "instructedAgent": { "additionalIdentifications": [], "address": {}, "bicfi": "string", "branch": {}, "clearingSystemMemberId": {}, "companyRegistration": "string", "lei": "string", "memberId": "string", "name": "string" }, "instructingAgent": { "additionalIdentifications": [], "address": {}, "bicfi": "string", "branch": {}, "clearingSystemMemberId": {}, "companyRegistration": "string", "lei": "string", "memberId": "string", "name": "string" }, "mandateInformation": { "mandateIdentification": "string", "trackingDays": 99 }, "originalMessageNameIdentification": "string", "paymentScheme": { "schema": "ZA_RTC", "schemeData": {} }, "schema": "CustomerPaymentStatusReport", "status": { "outcome": "APPROVED", "reasonInfo": [] } }

MandateAcceptanceResult

Result of a mandate maintenance request.

acceptedbooleanrequired

Indicates whether the mandate maintenance request was accepted (true) or rejected (false).

additionalRejectionInformationArray of strings

Additional information about the rejection reason.

rejectionReasonobject(MandateReason)

Specifies the reason for a mandate action (amendment, cancellation, rejection).

{ "accepted": true, "additionalRejectionInformation": [ "string" ], "rejectionReason": { "schema": "string", "value": "AC01" } }

operational

Operations

bulk

Operations

request-to-pay

Operations

refund

Operations

account-verification

Operations