Design considerations
A number of business and technical decisions must be made before integrating with the Electrum Digital Vouchers 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 |
| Decide which service providers you wish to interact with. | Discuss commercial agreements directly with the selected service providers. |
| Channels |
| Decide which transaction initiation channels you will be supporting. | Ensure your channel development teams are familiar with the Electrum Single Use Vouchers Service Interface and implementation guidelines. |
| 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. | Decide on whether you want to manage your product list via Electrum's catalogue management feature. | If you decide to use Electrum's catalogue then you will need to implement product lookup transactions. |
| Optional transactions |
| Decide which optional transactions you wish to implement. | |
| Messaging |
| This will depend on the channels used and on business needs. | |
| Connectivity and security |
| Decide on which method you wish to use for securing communication between the originating system and the Electrum API. |
Electrum's Catalogue Management
It is important to maintain an up-to-date catalogue listing the full array of digital voucher 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 voucher 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 lookupProducts 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 listed 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.
Stellr does not support reversals. Once a voucher is issued it is considered to be exposed (and therefore must be paid for). If Stellr issues a voucher and a timeout occurs downstream, then the originating system will not receive the voucher – however the originating system may still be liable for the cost depending on the commercial contract between the two parties.
This risk can be mitigated through commercial agreements between the originating system and service provider – stating, for example, that discrepancies can be settled during mark-up/mark-off reconciliation in favour of one party or the other, or a mix.
We recommend that originating systems implement retries. In the event of a timeout, the originating system can retry the transaction for as many times as required to retrieve the voucher that was issued but not received. Retries are idempotent, meaning that they do not create new transactions (with associated financial liability), but rather try to retrieve a previous transaction.