Electrum Regulated Payments Partner API (17.1.0)

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.

Download OpenAPI description
Languages
Servers
Mock server

https://docs.electrumsoftware.com/_mock/openapi/elpapi/elpapi-partner/

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

Schema

SchemeVerificationData

This object contains fields specific to the scheme being interacted with and determined by the chosen schema. Typically these are fields that are not standard within ISO20022 ACMT.023

schemastringrequired
Discriminator
checkCreditsAllowedboolean

Sets whether or not the response should indicate if credits are allowed on the account.

checkDebitsAllowedboolean

Sets whether or not the response should indicate if debits are allowed on the account.

checkOlderThanThreeMonthsboolean

Sets whether or not the response should indicate whether the account is older than 3 months.

initialsstring<= 70 characters

Initials of the individual account owner that is to be verified.

lastNamestring<= 70 characters

Family name of the individual account owner that is to be verified.

{ "schema": "ZA_AVS", "checkCreditsAllowed": true, "checkDebitsAllowed": true, "checkOlderThanThreeMonths": true, "initials": "string", "lastName": "string" }

ZaAccountVerificationData

Fields specific to account verification services in South Africa. The fields checksDebitsAllowed, checksCreditsAllowed and checksOlderThanThreeMonths indicate to the receiving FI whether or not to return the associated information (i.e. true or false in respect to those items)

schemastringrequired
Discriminator
checkCreditsAllowedboolean

Sets whether or not the response should indicate if credits are allowed on the account.

checkDebitsAllowedboolean

Sets whether or not the response should indicate if debits are allowed on the account.

checkOlderThanThreeMonthsboolean

Sets whether or not the response should indicate whether the account is older than 3 months.

initialsstring<= 70 characters

Initials of the individual account owner that is to be verified.

lastNamestring<= 70 characters

Family name of the individual account owner that is to be verified.

{ "schema": "ZA_AVS", "checkCreditsAllowed": true, "checkDebitsAllowed": true, "checkOlderThanThreeMonths": true, "initials": "string", "lastName": "string" }

Verification

accountobject(PaymentAccount)required

Representation of an account for payment purposes. Note that at least one of identification or proxy is expected to be present.

account.​currencystring^[A-Z]{3}$

Identification of the currency in which the account is held.

account.​identificationobject(BankingIdentifier)
account.​namestring<= 70 characters

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.

account.​proxyobject(NonBankingIdentifier)
account.​typeobject(AccountType)
agentobject(InstitutionIdentification)
identificationstring[ 1 .. 35 ] characters

Uniquely identifies this verification. Used in cases where a list of verifications are necessary, in such cases a verification may need to be uniquely identified independently from other verifications.

partyobject(Party)required

This model is the basic representation of a Party. It is expanded on depending on whether the party is a person or an organisation.

party.​addressobject(PostalAddress)
party.​contactDetailsobject(ContactDetails)
party.​countryOfResidencestring(CountryCode)[A-Z]{2,2}

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).

party.​identificationobject(PartyIdentification)

The identification of a party, either a person or an organisation.

party.​knownAsNamestring[ 1 .. 140 ] characters

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.

party.​legalNamestring[ 1 .. 140 ] characters

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).

schemeVerificationDataobject(SchemeVerificationData)

This object contains fields specific to the scheme being interacted with and determined by the chosen schema. Typically these are fields that are not standard within ISO20022 ACMT.023

{ "account": { "currency": "string", "identification": {}, "name": "string", "proxy": {}, "type": {} }, "agent": { "additionalIdentifications": [], "address": {}, "bicfi": "string", "branch": {}, "clearingSystemMemberId": {}, "companyRegistration": "string", "lei": "string", "memberId": "string", "name": "string" }, "identification": "string", "party": { "address": {}, "contactDetails": {}, "countryOfResidence": "string", "identification": {}, "knownAsName": "string", "legalName": "string" }, "schemeVerificationData": { "schema": "string" } }

operational

Operations

bulk

Operations

request-to-pay

Operations

refund

Operations

account-verification

Operations