Bulk RTP
Electrum offers corporate clients the ability to make multiple payment requests in one transaction. This solution supports only pay-by-proxy bulk RTP. The RTPs in the bulk may have different destinations (paying banks).
Even though the initial request is sent as a bulk, Electrum will then extract each RTP to be sent to its intended destination and be processed and cleared individually with industry.
As in the case of single RTP, all RTP statuses are stored in Electrum’s RTP Store. Electrum will check and update the RTP status in the store as the transaction progresses.
Any RTP declines or cancellations will be handled according to the single RTP flows (see below).
RTP Acceptance
- Send a bulk RTP request to Electrum using the
outboundBulkRequestToPayoperation (RequestToPayInitiationschema). For each bulk request you must generate a bulk ID and populate this value in therequestToPayInformationIdfield. List the individual RTP requests as an array of objects in therequestToPayInitiationInstructionsfield.
RequestToPayInitiation Schema
Holds a point-to-point unique message identification string as well as a message's creation date time.
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
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.
A list of key-value pairs to support adding any supplementary/additional data to an Electrum Regulated Payments API message.
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.
This model is the basic representation of a Party. It is expanded on depending on whether the party is a person or an organisation.
The total number of transactions in the bulk.
Universally unique identifier to identify the bulk collection itself.
List of instructions to initiate each request to pay within the bulk with other financial institutions or the partner bank.
This model is the basic representation of a Party. It is expanded on depending on whether the party is a person or an organisation.
A code to identify a country, a dependency, or another area of particular geopolitical interest, on the basis of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
The identification of a party, either a person or an organisation.
The name by which this party is commonly known in day to day use. For example, a shortening of their legal name or a nickname that they commonly use. This is "non-official". However, it is acceptable for this field to be set to the same as legalName.
The legal name by which this party is known (the "FICA" name). This is the full name of the party as found on country-issued documentation (national identity, company registration documentation etc).
Representation of an account for payment purposes. Note that at least one of identification or proxy is expected to be present.
Identification of the currency in which the account is held.
Name of the account, as assigned by the account servicing institution, in agreement with the account owner in order to provide an additional means of identification of the account.
A code allocated to a financial or non-financial institution by the ISO 9362 Registration Authority as described in ISO 9362 Banking - Banking telecommunication messages - Business identifier code (BIC)
An organisation identified by a code allocated to a party as described in ISO 17442 Financial Services - Legal Entity Identifier (LEI).
Name by which an institution is known and which is usually used to identify that institution
A unique identifier assigned to a company or organisation by a duly appointed authority within a country.
Deprecated. Please use the preferred clearingSystemMemberId.memberId instead. Identification of a member of a clearing system.
This model is the basic representation of a Party. It is expanded on depending on whether the party is a person or an organisation.
Representation of an account for payment purposes. Note that at least one of identification or proxy is expected to be present.
Identification of the currency in which the account is held.
Name of the account, as assigned by the account servicing institution, in agreement with the account owner in order to provide an additional means of identification of the account.
Date and time at which the request to pay expires. Some schemes may still permit a payment after the request to pay expires. Upon expiry, the following schemes will reject an associated payment: ZA_RPP. The date must be formatted as defined by date-time in RFC3339
Further information related to the processing of the payment instruction, provided by the initiating party, and intended for the debtor agent.
Holds a point-to-point unique message identification string as well as a message's creation date time.
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
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.
Specifies the underlying reason for the payment transaction
Describes the various aspects of a request to pay which must be accepted or to what extent they may be altered.
A valid, active currency code as defined in ISO 4217 indicating the currency of the amount.
The payment amount in the denomination of the indicated currency, in the format '<major units>.<minor units> with the number of minor units (fractional digits) compliant with the number of decimal places published in ISO 4217.
| Currency Code | Example | Valid | Notes |
|---|---|---|---|
| USD | 10.0 | ✓ | Represents 10 USD and no cents. |
| USD | 10.00 | ✓ | |
| USD | 10.001 | ✗ | US dollar does not support three decimal places. |
| JPY | 10.0 | ✓ | Represents 10 Japanese Yen. |
| JPY | 10.1 | ✗ | Japanese Yen does not support decimal places. |
A valid, active currency code as defined in ISO 4217 indicating the currency of the amount.
The payment amount in the denomination of the indicated currency, in the format '<major units>.<minor units> with the number of minor units (fractional digits) compliant with the number of decimal places published in ISO 4217.
| Currency Code | Example | Valid | Notes |
|---|---|---|---|
| USD | 10.0 | ✓ | Represents 10 USD and no cents. |
| USD | 10.00 | ✓ | |
| USD | 10.001 | ✗ | US dollar does not support three decimal places. |
| JPY | 10.0 | ✓ | Represents 10 Japanese Yen. |
| JPY | 10.1 | ✗ | Japanese Yen does not support decimal places. |
Holds a series of identifiers to identify the transaction or an individual message that is part of a transaction.
Unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain. Note: this is distinct from the UETR.
Unique identification, as assigned by an instructing party for an instructed party, to unambiguously identify the instruction. The instruction identification is a point to point reference that can be used between the instructing party and the instructed party to refer to the individual instruction. It can be included in several messages related to the instruction.
Unique identification, as assigned by the first instructing agent, to unambiguously identify the transaction that is passed on, unchanged, throughout the entire interbank chain. Usage: The transaction identification can be used for reconciliation, tracking or to link tasks relating to the transaction on the interbank level. Usage: The instructing agent has to make sure that the transaction identification is unique for a pre-agreed period.
Universally unique identifier to provide an end-to-end reference of a payment transaction. This identifier remains the same for all messages related to the same transaction.
- Electrum checks that:
- The number of RTPs in the bulk matches the
numberOfTransactionsvalue that you have indicated in the request message. - The transaction amounts for each RTP are valid. (Note that any invalid RTPs will be deemed
REJECTEDand will not be processed further.)
Electrum debulks the request and sends each individual RTP to industry.
Once all valid RTPs have reached their destination banks, Electrum will rebulk the individual RTPs and send a bulk response to you using the
outboundBulkRequestToPayResponseoperation (RequestToPayInitiationResponseschema), showing the current status of the bulk.From this point, the message flow follows a single RTP flow: The payer at the industry bank accepts the request-to-pay and the industry bank initiates the payment. BankservAfrica sends the credit transfer request to Electrum.
Electrum retrieves the RTP status from the Store and determines that it is valid by:
Confirming the RTP exists and the status is either
PENDINGorPRESENTED, and is notCANCELLED,REJECTED,EXPIRED, orPAID. Note: the payment will still be accepted in the case that the RTP status is PENDING in the RTP store. For instance, in cases where theoutboundRequestToPayResponse(PRESENTED) message has gotten lost, or there was a timeout, or the payer paid very soon after receiving the RTP, before theoutboundRequestToPayResponse(PRESENTED) could reach the RTP store.When amount modification is not allowed, checking that the amount sent by the payer matches that of the amount requested in the original request.
When amount modification is allowed, checking that the amount sent by the payer is within the maximum and minimum requested amount.
Confirming that the creditor account number or proxy and domain belong to a listed corporate client.
If your institution participates in partner-authorisation, this additional clearing authorisation step will occur: Electrum sends an
inboundCreditTransferAuthorisationrequest to you, and you acknowledge with an ACK HTTP202. You send Electrum a positiveinboundCreditTransferAuthorisationResponsemessage when the validations pass, and Electrum returns a positive acknowledgement.Electrum sends an
inboundCreditTransferCompletionmessage (PaymentStatusReportschema) message to you to indicate clearing completion, and updates the RTP status to PAID.(Optional) You can query the status of the bulk itself by sending a
getOutboundBulkRequestToPayStatusoperation (RequestToPayInitiationStatusRequestschema). Electrum returns a bulk response to the corporate client, using theoutboundBulkRequestToPayResponseoperation (RequestToPayInitiationResponseschema), showing the current status of each RTP in the bulk.
Electrum collates the information for all the paid RTPs and sends a posting instructing the sponsor bank to credit your account with the paid amount.
You can request the status of the bulk at any point by sending a getOutboundBulkRequestToPayStatus message which must include the bulk reference ID, to Electrum. Set the includeIndividualRequestToPayStatuses field to true or false:
- If true: an aggregate of the bulk status as well as the status of each individual transaction within the bulk will be returned with the
outboundBulkRequestToPayResponseresponse. - If false: only an aggregate of the bulk status will be returned with the outboundBulkRequestToPayResponse.
The bulk status response will detail the number of transactions in each state: PAID, ACCEPTED, PENDING, PRESENTED, CANCELLED, REJECTED, EXPIRED, or UNSUBMITTED.
You can request the status of an individual RTP from the RTP Store at any time for any reason by sending a synchronous getRequestToPayWithPOST request, including the original RTP UETR, directly to the RTP Store.
You will only receive the outboundBulkRequestToPayResponse once all RTP transactions within the submitted bulk have received a response from industry. You will not receive an interim response unless you send a status request as described above.
RTP Decline
- Send a bulk RTP request to Electrum using the
outboundBulkRequestToPayoperation (RequestToPayInitiationschema). For each bulk request you must generate a bulk ID and populate this value in therequestToPayInformationIdfield. List the individual RTP requests as an array of objects in therequestToPayInitiationInstructionsfield.
RequestToPayInitiation Schema
Holds a point-to-point unique message identification string as well as a message's creation date time.
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
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.
A list of key-value pairs to support adding any supplementary/additional data to an Electrum Regulated Payments API message.
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.
This model is the basic representation of a Party. It is expanded on depending on whether the party is a person or an organisation.
The total number of transactions in the bulk.
Universally unique identifier to identify the bulk collection itself.
List of instructions to initiate each request to pay within the bulk with other financial institutions or the partner bank.
This model is the basic representation of a Party. It is expanded on depending on whether the party is a person or an organisation.
A code to identify a country, a dependency, or another area of particular geopolitical interest, on the basis of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
The identification of a party, either a person or an organisation.
The name by which this party is commonly known in day to day use. For example, a shortening of their legal name or a nickname that they commonly use. This is "non-official". However, it is acceptable for this field to be set to the same as legalName.
The legal name by which this party is known (the "FICA" name). This is the full name of the party as found on country-issued documentation (national identity, company registration documentation etc).
Representation of an account for payment purposes. Note that at least one of identification or proxy is expected to be present.
Identification of the currency in which the account is held.
Name of the account, as assigned by the account servicing institution, in agreement with the account owner in order to provide an additional means of identification of the account.
A code allocated to a financial or non-financial institution by the ISO 9362 Registration Authority as described in ISO 9362 Banking - Banking telecommunication messages - Business identifier code (BIC)
An organisation identified by a code allocated to a party as described in ISO 17442 Financial Services - Legal Entity Identifier (LEI).
Name by which an institution is known and which is usually used to identify that institution
A unique identifier assigned to a company or organisation by a duly appointed authority within a country.
Deprecated. Please use the preferred clearingSystemMemberId.memberId instead. Identification of a member of a clearing system.
This model is the basic representation of a Party. It is expanded on depending on whether the party is a person or an organisation.
Representation of an account for payment purposes. Note that at least one of identification or proxy is expected to be present.
Identification of the currency in which the account is held.
Name of the account, as assigned by the account servicing institution, in agreement with the account owner in order to provide an additional means of identification of the account.
Date and time at which the request to pay expires. Some schemes may still permit a payment after the request to pay expires. Upon expiry, the following schemes will reject an associated payment: ZA_RPP. The date must be formatted as defined by date-time in RFC3339
Further information related to the processing of the payment instruction, provided by the initiating party, and intended for the debtor agent.
Holds a point-to-point unique message identification string as well as a message's creation date time.
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
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.
Specifies the underlying reason for the payment transaction
Describes the various aspects of a request to pay which must be accepted or to what extent they may be altered.
A valid, active currency code as defined in ISO 4217 indicating the currency of the amount.
The payment amount in the denomination of the indicated currency, in the format '<major units>.<minor units> with the number of minor units (fractional digits) compliant with the number of decimal places published in ISO 4217.
| Currency Code | Example | Valid | Notes |
|---|---|---|---|
| USD | 10.0 | ✓ | Represents 10 USD and no cents. |
| USD | 10.00 | ✓ | |
| USD | 10.001 | ✗ | US dollar does not support three decimal places. |
| JPY | 10.0 | ✓ | Represents 10 Japanese Yen. |
| JPY | 10.1 | ✗ | Japanese Yen does not support decimal places. |
A valid, active currency code as defined in ISO 4217 indicating the currency of the amount.
The payment amount in the denomination of the indicated currency, in the format '<major units>.<minor units> with the number of minor units (fractional digits) compliant with the number of decimal places published in ISO 4217.
| Currency Code | Example | Valid | Notes |
|---|---|---|---|
| USD | 10.0 | ✓ | Represents 10 USD and no cents. |
| USD | 10.00 | ✓ | |
| USD | 10.001 | ✗ | US dollar does not support three decimal places. |
| JPY | 10.0 | ✓ | Represents 10 Japanese Yen. |
| JPY | 10.1 | ✗ | Japanese Yen does not support decimal places. |
Holds a series of identifiers to identify the transaction or an individual message that is part of a transaction.
Unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain. Note: this is distinct from the UETR.
Unique identification, as assigned by an instructing party for an instructed party, to unambiguously identify the instruction. The instruction identification is a point to point reference that can be used between the instructing party and the instructed party to refer to the individual instruction. It can be included in several messages related to the instruction.
Unique identification, as assigned by the first instructing agent, to unambiguously identify the transaction that is passed on, unchanged, throughout the entire interbank chain. Usage: The transaction identification can be used for reconciliation, tracking or to link tasks relating to the transaction on the interbank level. Usage: The instructing agent has to make sure that the transaction identification is unique for a pre-agreed period.
Universally unique identifier to provide an end-to-end reference of a payment transaction. This identifier remains the same for all messages related to the same transaction.
- Electrum checks that:
- The number of RTPs in the bulk matches the
numberOfTransactionsvalue that you have indicated in the request message. - The transaction amounts for each RTP are valid. (Note that any invalid RTPs will be deemed
REJECTEDand will not be processed further.)
Electrum debulks the request and sends each individual RTP to industry.
Once all valid RTPs have reached their destination banks, Electrum will rebulk the individual RTPs and send a bulk response to you using the
outboundBulkRequestToPayResponseoperation (RequestToPayInitiationResponseschema), showing the current status of the bulk.A payer at the industry bank declines an individual RTP request and BankservAfrica notifies Electrum.
Electrum sends an
outboundRequestToPayResponsemessage, containing a status code ofREJECTEDfor that individual rejected RTP, to you. You return an acknowledgement (ACK, HTTP202). The payee is informed that the payer declined to pay.Electrum updates the status in the RTP Store to
REJECTED.
RTP Cancellation
- Send a bulk RTP request to Electrum using the
outboundBulkRequestToPayoperation (RequestToPayInitiationschema). For each bulk request you must generate a bulk ID and populate this value in therequestToPayInformationIdfield. List the individual RTP requests as an array of objects in therequestToPayInitiationInstructionsfield.
RequestToPayInitiation Schema
Holds a point-to-point unique message identification string as well as a message's creation date time.
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
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.
A list of key-value pairs to support adding any supplementary/additional data to an Electrum Regulated Payments API message.
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.
This model is the basic representation of a Party. It is expanded on depending on whether the party is a person or an organisation.
The total number of transactions in the bulk.
Universally unique identifier to identify the bulk collection itself.
List of instructions to initiate each request to pay within the bulk with other financial institutions or the partner bank.
This model is the basic representation of a Party. It is expanded on depending on whether the party is a person or an organisation.
A code to identify a country, a dependency, or another area of particular geopolitical interest, on the basis of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
The identification of a party, either a person or an organisation.
The name by which this party is commonly known in day to day use. For example, a shortening of their legal name or a nickname that they commonly use. This is "non-official". However, it is acceptable for this field to be set to the same as legalName.
The legal name by which this party is known (the "FICA" name). This is the full name of the party as found on country-issued documentation (national identity, company registration documentation etc).
Representation of an account for payment purposes. Note that at least one of identification or proxy is expected to be present.
Identification of the currency in which the account is held.
Name of the account, as assigned by the account servicing institution, in agreement with the account owner in order to provide an additional means of identification of the account.
A code allocated to a financial or non-financial institution by the ISO 9362 Registration Authority as described in ISO 9362 Banking - Banking telecommunication messages - Business identifier code (BIC)
An organisation identified by a code allocated to a party as described in ISO 17442 Financial Services - Legal Entity Identifier (LEI).
Name by which an institution is known and which is usually used to identify that institution
A unique identifier assigned to a company or organisation by a duly appointed authority within a country.
Deprecated. Please use the preferred clearingSystemMemberId.memberId instead. Identification of a member of a clearing system.
This model is the basic representation of a Party. It is expanded on depending on whether the party is a person or an organisation.
Representation of an account for payment purposes. Note that at least one of identification or proxy is expected to be present.
Identification of the currency in which the account is held.
Name of the account, as assigned by the account servicing institution, in agreement with the account owner in order to provide an additional means of identification of the account.
Date and time at which the request to pay expires. Some schemes may still permit a payment after the request to pay expires. Upon expiry, the following schemes will reject an associated payment: ZA_RPP. The date must be formatted as defined by date-time in RFC3339
Further information related to the processing of the payment instruction, provided by the initiating party, and intended for the debtor agent.
Holds a point-to-point unique message identification string as well as a message's creation date time.
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
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.
Specifies the underlying reason for the payment transaction
Describes the various aspects of a request to pay which must be accepted or to what extent they may be altered.
A valid, active currency code as defined in ISO 4217 indicating the currency of the amount.
The payment amount in the denomination of the indicated currency, in the format '<major units>.<minor units> with the number of minor units (fractional digits) compliant with the number of decimal places published in ISO 4217.
| Currency Code | Example | Valid | Notes |
|---|---|---|---|
| USD | 10.0 | ✓ | Represents 10 USD and no cents. |
| USD | 10.00 | ✓ | |
| USD | 10.001 | ✗ | US dollar does not support three decimal places. |
| JPY | 10.0 | ✓ | Represents 10 Japanese Yen. |
| JPY | 10.1 | ✗ | Japanese Yen does not support decimal places. |
A valid, active currency code as defined in ISO 4217 indicating the currency of the amount.
The payment amount in the denomination of the indicated currency, in the format '<major units>.<minor units> with the number of minor units (fractional digits) compliant with the number of decimal places published in ISO 4217.
| Currency Code | Example | Valid | Notes |
|---|---|---|---|
| USD | 10.0 | ✓ | Represents 10 USD and no cents. |
| USD | 10.00 | ✓ | |
| USD | 10.001 | ✗ | US dollar does not support three decimal places. |
| JPY | 10.0 | ✓ | Represents 10 Japanese Yen. |
| JPY | 10.1 | ✗ | Japanese Yen does not support decimal places. |
Holds a series of identifiers to identify the transaction or an individual message that is part of a transaction.
Unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain. Note: this is distinct from the UETR.
Unique identification, as assigned by an instructing party for an instructed party, to unambiguously identify the instruction. The instruction identification is a point to point reference that can be used between the instructing party and the instructed party to refer to the individual instruction. It can be included in several messages related to the instruction.
Unique identification, as assigned by the first instructing agent, to unambiguously identify the transaction that is passed on, unchanged, throughout the entire interbank chain. Usage: The transaction identification can be used for reconciliation, tracking or to link tasks relating to the transaction on the interbank level. Usage: The instructing agent has to make sure that the transaction identification is unique for a pre-agreed period.
Universally unique identifier to provide an end-to-end reference of a payment transaction. This identifier remains the same for all messages related to the same transaction.
- Electrum checks that:
- The number of RTPs in the bulk matches the
numberOfTransactionsvalue that you have indicated in the request message. - The transaction amounts for each RTP are valid. (Note that any invalid RTPs will be deemed
REJECTEDand will not be processed further.)
Electrum debulks the request and sends each individual RTP to industry.
Once all valid RTPs have reached their destination banks, Electrum will rebulk the individual RTPs and send a bulk response to you using the
outboundBulkRequestToPayResponseoperation (RequestToPayInitiationResponseschema), showing the current status of the bulk.You send an
outboundRequestToPayCancellationRequestmessage (RequestToPayCancellationschema) to Electrum to cancel the RTP, and Electrum returns an acknowledgement (ACK, HTTP202).
RequestToPayCancellation Schema
Holds a point-to-point unique message identification string as well as a message's creation date time.
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
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.
Holds a point-to-point unique message identification string as well as a message's creation date time.
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
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.
Contains key elements related to the original request to pay that is being referred to.
Holds a series of identifiers to identify the transaction or an individual message that is part of a transaction.
Unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain. Note: this is distinct from the UETR.
Unique identification, as assigned by an instructing party for an instructed party, to unambiguously identify the instruction. The instruction identification is a point to point reference that can be used between the instructing party and the instructed party to refer to the individual instruction. It can be included in several messages related to the instruction.
Unique identification, as assigned by the first instructing agent, to unambiguously identify the transaction that is passed on, unchanged, throughout the entire interbank chain. Usage: The transaction identification can be used for reconciliation, tracking or to link tasks relating to the transaction on the interbank level. Usage: The instructing agent has to make sure that the transaction identification is unique for a pre-agreed period.
Universally unique identifier to provide an end-to-end reference of a payment transaction. This identifier remains the same for all messages related to the same transaction.
The reason the request to pay is being cancelled.
AC03: InvalidCreditorAccountNumber - Wrong account number in Credit Transfer.AGNT: IncorrectAgent- Agent in the payment workflow is incorrect.AM09: WrongAmount- Amount is not the amount agreed or expected.BE16: InvalidDebtorIdentificationCode- Debtor or Ultimate Debtor identification code missing or invalid.COVR: CoverCancelledOrReturned- Cover payments has either been returned or cancelled.CURR: IncorrectCurrency- Currency of the payment is incorrect.CUST: RequestedByCustomer- Cancellation requested by the Creditor.CUTA: CancelUponUnableToApply- Cancellation requested because an investigation request has been received and no remediation is possible.DS24: TimeOut- Cancellation requested because the original payment order expired due to time-out.DT01: InvalidDate- Invalid date (for example, wrong or missing settlement date).DUPL: DuplicatePayment- Payment is a duplicate of another payment.FRAD: FraudulentOrigin- Cancellation requested following a transaction that was originated fraudulently. The use of the FraudulentOrigin code should be governed by jurisdictions.FRNA: ForwardToNextAgent- To complement a rejection response, suggesting the request for cancelation should be forwarded to the next agent in the payment transaction chain.FRTR: FinalResponse- Direct Debit Tracking recalled as Mandate CancelledINDM: IndemnityRequired- To express the wish to establish a bilateral indemnity agreement.MODT: ModifiedTransaction- The underlying transaction in relation to an RTP was modified.PAID: TransactionAlreadyPaid- The underlying transaction in relation to an RTP was already paid (via other means).SVNR: ServiceNotRendered- The payment is cancelled since a cash amount rendered was not correct or goods or a service was not rendered to the customer, e.g. in an e-commerce situation.SYAD: RequestToSettlementSystemAdministrator- Cancellation requested by System Member to Settlement System Administrator to indicate that the cancellation request must not be forwarded further in the chain.TECH: TechnicalProblem- Cancellation requested following technical problems resulting in an erroneous transaction.UPAY: UnduePayment- Payment is not justified.ENUE: EndUserError- Cancellation or request for return requested by the Debtor specifically due to one or more errors by debtor in the original Credit Transfer. Usage: This code can be used for any error in the original Credit Transfer made by the Debtor. Can also be used if multiple errors were made in the original Credit Transfer.UAPA: UnauthorizedPayment- "The Debtor is requesting a return of the payment because the payment was not properly authorized. Usage: This code can be used in the case where a Credit Transfer was made without proper authorization from the Debtor. This could be due to compromised end user credentials."NARR: Narrative- Reason is provided as narrative information in the additional reason information.AC02: InvalidDebtorAccountNumber- Debtor account number invalid or missing.BIAS: BatchInstructionAlreadySettled- Process a cancellation request but batch already settled.INCR: InvalidCancellationRequest- Process a cancellation request with incorrect reference to original batch.DRTP: DuplicationRequestToPay- Duplication of a request-to-pay message.
A description of the reason the request to pay is being cancelled.
Electrum forwards the cancellation to BankservAfrica. Note: Electrum will not first verify that a cancellation request (
outboundRequestToPayCancellationRequest) received from a corporate client is linked to a prior RTP request. Electrum will merely forward the cancellation as soon as we receive it from you.Electrum receives notification from BankservAfrica that the payment was successfully cancelled.
Electrum sends an
outboundRequestToPayCancellationResponsemessage to you (RequestToPayCancellationResponseschema), and you return an acknowledgement (ACK, HTTP202).
RequestToPayCancellationResponse Schema
Holds a point-to-point unique message identification string as well as a message's creation date time.
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
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.
Holds a point-to-point unique message identification string as well as a message's creation date time.
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
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.
Contains key elements related to the original request to pay that is being referred to.
Holds a series of identifiers to identify the transaction or an individual message that is part of a transaction.
Unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain. Note: this is distinct from the UETR.
Unique identification, as assigned by an instructing party for an instructed party, to unambiguously identify the instruction. The instruction identification is a point to point reference that can be used between the instructing party and the instructed party to refer to the individual instruction. It can be included in several messages related to the instruction.
Unique identification, as assigned by the first instructing agent, to unambiguously identify the transaction that is passed on, unchanged, throughout the entire interbank chain. Usage: The transaction identification can be used for reconciliation, tracking or to link tasks relating to the transaction on the interbank level. Usage: The instructing agent has to make sure that the transaction identification is unique for a pre-agreed period.
Universally unique identifier to provide an end-to-end reference of a payment transaction. This identifier remains the same for all messages related to the same transaction.
A list of RequestToPayCancellationStatusReasonInfo values providing detailed reason information for the status.
CANCELLED: Cancelled - The cancellation was successfully processed and the request for payment has been cancelled.REJECTED: Rejected - The cancellation was rejected. Refer to thereasonInfofor further information.
Example
No content- Electrum updates the status in the RTP Store to
CANCELLED.