Electrum Regulated Payments Events API (26.1.1)

The Electrum Regulated Payments Events API is a synchronous API that describes the events emitted by the Electrum Regulated Payments platform during the course of transaction processing.

This document describes the single endpoint that you will need to implement in order to receive event notifications posted by Electrum.

As transactions are processed by Electrum, events are emitted to provide information about the status of the transactions and the operations preformed on them. These events do not affect processing, but provide information that can be used for operational support and monitoring purposes.

All events are posted to the same single URL. Event are differentiated by a unique descriptor contained in the name field of the message body. This descriptor serves to allow the receiver to determine whether the particular event is of interest.

Download OpenAPI description
Overview
Languages
Servers
Payments API sandbox

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

state

Transactions transition through different states. As each state is entered, an event is emitted. This event provides information about the state entered by the transaction. Included in this information is the message payload of the operation that triggered the state transition in the Electrum Regulated Payments. Note: The message payload attached to an event might be an internally-triggered message and not the message sent to or received from the Electrum Regulated Payments API.

Operations

Schema

ZaEftFiToFiPaymentCancellationPaymentSchemeData

cancellationTypestringrequired

Identifies the type of EFT payment cancellation.

  • SYSTEM_ERROR_CORRECTION_REQUEST: Only expected for inbound use and represents the case where a bank from industry has experienced a technical issue that resulted in payments to or from the partner bank being reflected incorrectly (e.g. credits or debits were duplicated) and the industry bank is requesting that the partner bank attempt to correct the error. A successful correction means that the partner bank will initiate a financial Payment Return.

    This case is notably different from unpaids, standard recalls and disputes in that: (1) it strictly requires prior industry/PASA authorisation to invoke (2) the system error correction request is expected to be best effort and may be rejected by the partner bank if the request cannot be honoured (e.g. due to insufficient funds or a closed account) (3) the bank from industry may retry system error correction requests for the same transaction on different days if an earlier request was rejected.

Value"SYSTEM_ERROR_CORRECTION_REQUEST"
{ "cancellationType": "SYSTEM_ERROR_CORRECTION_REQUEST" }

ZaEftFiToFiPaymentCancellationPaymentScheme

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"
schemeDataobject(ZaEftFiToFiPaymentCancellationPaymentSchemeData)required
schemeData.​cancellationTypestringrequired

Identifies the type of EFT payment cancellation.

  • SYSTEM_ERROR_CORRECTION_REQUEST: Only expected for inbound use and represents the case where a bank from industry has experienced a technical issue that resulted in payments to or from the partner bank being reflected incorrectly (e.g. credits or debits were duplicated) and the industry bank is requesting that the partner bank attempt to correct the error. A successful correction means that the partner bank will initiate a financial Payment Return.

    This case is notably different from unpaids, standard recalls and disputes in that: (1) it strictly requires prior industry/PASA authorisation to invoke (2) the system error correction request is expected to be best effort and may be rejected by the partner bank if the request cannot be honoured (e.g. due to insufficient funds or a closed account) (3) the bank from industry may retry system error correction requests for the same transaction on different days if an earlier request was rejected.

Value"SYSTEM_ERROR_CORRECTION_REQUEST"
{ "schema": "ZA_RTC", "schemeData": { "cancellationType": "SYSTEM_ERROR_CORRECTION_REQUEST" } }

FiToFiPaymentCancellationPaymentScheme

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

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(ZaAcFiToFiPaymentCancellationPaymentSchemeData)required
schemeData.​cancellationTypestringrequired

Identifies the specific business process applicable to the cancellation request.

  • RECALL: A request to revoke a payment instruction that has not yet settled or is currently in tracking. If successful, the instruction is cancelled without financial movement (no settlement occurs). If the partner makes use of Electrum's collections capabilities, this type is only expected for outbound use.

  • SYSTEM_ERROR_CORRECTION_REQUEST: Represents the case where a bank has experienced a technical issue that resulted in settled debit collections being processed incorrectly (e.g., a batch of debits was duplicated), and the industry bank is requesting that the partner bank correct the error.

    A successful correction means the partner bank initiates a financial Payment Return to recover the funds from the industry bank in order to refund the debtor.

    This case is notably different from standard recalls and disputes in that: (1) This strictly requires prior industry/PASA authorisation to invoke, (2) it may be rejected by the partner bank if the correction cannot be applied (e.g., original transaction not found, or the transaction was already reversed via a customer dispute), (3) partial reversals are not permitted, and (4) the bank from industry is limited to exactly 2 (two) retry attempts for the same transaction if an earlier request was rejected.

Enum"RECALL""SYSTEM_ERROR_CORRECTION_REQUEST"
{ "schema": "ZA_AC", "schemeData": { "cancellationType": "RECALL" } }