Design considerations
A number of business and technical decisions must be made before integrating with the Electrum Bill Payments Service. The outcome of these decisions will impact the design of the originating system, and how the Electrum platform needs to be configured. The following sections outline various items that need to be considered with respect to online transaction switching and back-office processing. For further details of the product features and available options, read the Product Overview page.
Once the design decisions have been made, these need to be documented and shared with Electrum in a Business Requirements Document.
Your design may require support for an option that is not specified here, for example, an additional service provider, payment provider, or routing rule. If this is the case, then raise a feature request with Electrum to facilitate the necessary development.
Online Transaction Processing
The table below summarises the choices that determine how the Electrum Switch is configured for processing requests from an originating system in real time.
| Feature | Options | Decisions and Actions |
|---|---|---|
| Service providers |
|
|
| Channels |
|
|
| Types of bill payments |
|
|
| Catalogue | Biller list |
|
| Routing |
|
|
| Connectivity and Security |
|
|
Electrum Finance
Processes that happen after transactions have been completed in real time include reconciliation, reporting, and settlement. The items below need to be considered to inform how Electrum Finance is configured for handling these processes:
- Input file specifications for transaction matching
- Transaction matching rules
- Reporting requirements
- Details of the parties involved in each process
- Time-based rules (e.g. reconciliation period, automatic exception resolution, transaction expiry)
- Settlement posting requirements to finance system
Ensure that the requirements for the above have been agreed upon with Electrum before proceeding with your implementation. Read more about the Electrum Finance processes here.
Potential Financial Risks
Electrum's APIs, and those of many providers, are not idempotent. This means that provision or purchase (financially impacting) transactions that fail or time out cannot be repeated without potentially incurring further financial obligations.
It is necessary that you implement dual messaging for your Bill Payments solution. This means that you must support confirmations and reversals.
This is most important in cases where you are topping up an e-wallet with cash. Consider the following scenario:
- A consumer requests a top-up of their e-wallet.
- The service provider authorises top-up of the e-wallet.
- The consumer tenders for the purchase.
- The originating system confirms that tender has been made. - The confirmation message is sent via a store-and-forward (SAF) queue.
- Once the service provider receives the confirmation message they top up the e-wallet.
If the above process is not followed, financial risk is introduced in the following way:
If the service provider does not support confirmations, it may top up the wallet upon the initial request. If the consumer then cannot pay, or a timeout happens and the response does not arrive at the originating system, the originating system can initiate a reversal, which is sent via a SAF queue. The SAF queue ensures that advice messages (confirmation or reversal) will reach its destination. However, it may take a while for a reversal to reach the service provider – by which time the consumer may already have used up the money in the e-wallet.
This scenario would also introduce the possibility of intentional fraud – consumers who request wallet top-ups then purposefully fail to pay, but quickly use the money topped up before the reversal can occur.
The above risk can be mitigated if all parties support confirmations. Electrum will always support advice messaging via SAF queues. The originating system must implement dual messaging. The originating system must also host a SAF queue to ensure that advice messages reach their intended destination.
If the service provider does not support dual messaging, the originating system could also enforce a rule that tender must be taken before the transaction can be initiated.
Financial Action Task Force Compliance
Integrations between Retailers and certain bill payment service providers must comply with the regulations set by the South African Financial Action Task Force (FATF). FATF, as an independent global authority, develops and promotes policies to prevent illegal activities within the global financial system.
These regulations stipulate the retailer capture the details of the biller and payer during transaction processing. The retailer must ensure that customers consent to sharing their details with the service provider to fulfil the bill payment request. Customer details can be masked so that only the retailer and the service providers can view them.
The retailer shares the customer details with the service provider by populating various fields in the customer object of a Bill Payment Request message:
- The customer name and/or surname - in the firstName and
lastNamefields respectively - The customer ID Number – in the
idNumberfield - The customer’s ID Type – in the
idTypefield
If the retailer fails to comply with this requirement, it could face penalties, including fines or suspension of the bill payment channel. Non-compliance also puts the channel at risk of fraudulent bill payment transactions.