Design considerations
A number of business and technical decisions must be made before integrating with the Electrum Direct Top-Up Airtime 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 |
|
|
| Product list (catalogue) | You can maintain your list of available products through Electrum's catalogue management feature or you can use your own catalogue system. |
|
| Purchase confirmations |
|
|
| Routing |
|
|
| Connectivity and security |
|
|
Electrum's Catalogue Management
It is important to maintain an up-to-date catalogue listing the full array of airtime products offered, especially where there are many products offered by one or more service providers.
Electrum can help you set up your initial product catalogue. The catalogue lists the full range of airtime products and their associated codes, and also indicates the mappings where a single product has different client and service provider product codes.
If there are changes to the product list (e.g., a service provider adds additional products to their offering and you want to offer these to your customers) the service provider can notify you. You can access your catalogue via the Electrum Console and make changes as required.
In order for you to retrieve your built-in list of products, you will need to perform a listProducts call. This can be done frequently or infrequently depending on circumstances:
- If your system is not able to save the catalogue, then you will need to perform the call each time you need to access the catalogue.
- If there are frequent updates to the product list then you will need to perform this call frequently to ensure you have the latest product list.
- If the product list has not changed and your system is able to save the catalogue then you do not need to perform this call again – you can simply refer to the stored catalogue.
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.
Once airtime is sent directly to the consumer’s mobile device, this cannot be reversed. Therefore we advise that you only initiate direct top-up airtime transactions after the consumer has provided tender.
Purchase status lookup transactions are helpful in a scenario where there is a timeout on the response. Lookups allow the originator to determine what has happened to the transaction. It can functionally be used as a retry or a lookup.