Production Setup Prequisites
In order for a new tenant to be set up on the production system, various prerequisites must be met to ensure a smooth launch. These prerequisites depend on the Eclipse functionality that will be used.
Functionality Dependent Prerequisites
Text highlighted in yellow indicated prerequisites to be provided prior to commencement of the tenant setup in production. Other prerequisites are things that should be set up prior to the tenant going live
| Functionality | Prerequisites |
|---|---|
| Any | - Name - Trading Name |
| Any when launching in RSA | - A Nedbank corporate bank account - A Nedbank pool account created by Ukheshe specifically for the Tenant - Details on doing the above can be obtained from Finance operations |
| Generation of ZA_MASTERPASS QR Codes | - The tenant must be signed up as a Masterpass merchant - The masterpass merchant setup must settle to the Nedbank acquiring pool account - API access must be enabled in the masterpass portal Then when the tenant is being configured in production: - The notification key must be set in the tenants configuration as masterpass.config.aesKey - API access enabled in the masterpass portal and the user and password set in config properties masterpass.config.apiUser and masterpass.config.apiPassword - The masterpass notification URL must be set to https://ukheshe.live/eclipse-conductor/rest/v1/masterpass/incoming-payments?configId=XXX where XXX is the tenantId in production |
| Any | - The Permissions Eclipse Admin Portal section must be completed with the tenant and signed off and understood. This is simple enough for tenants only accessing the API’s with TENANT_SYSTEM role but is fairly detailed when allowing end users to call Eclipse APIs with their own identities |
| Any | - Tenants must use PKI authentication for TENANT_SYSTEM access. If they choose not to then an email must be sent notifying them of the risk of their password being leaked and confirmation received that they accept this risk. |
| Mastercard Card issuing (virtual or physical) | - The process/requirements to launch card programs are beyond the scope of the integration guide and are dealt with by the issuing team in detail. The outcome of that process is the Mastercard program Code e.g. PRG55 that must be configured as ProgramCode on a Card wallet type set up on the tenant. Then when the tenant is being configured in production: - Config params must be set up: institutionName, acceptorTerminalId, acquirerCountryCode, acquiringInstitutionCode, pointServiceCodes, posEntryMode, posPinCaptureCode, mcc - A virtual card should be set up to hold any reservations on other cards. The wallet id of this card should be set as config element reservationWalletId |
| Any when launching in RSA | - As Ukheshe is the accountable institution, Eclipse must hold all KYC data and run KYC checks even if pre-done by the tenant. - Before moving to production, the sandbox wallet types must be configured to run KYC checks and the tenant must demonstrate that all is working. |
| Withdrawals of type ZA_NEDBANK_EFT or ZA_NEDBANK_EFT_IMMEDIATE | - Nedbank must set up a CPS profile and provide the information required to populate the config values nedbank.cps.config.* |
| Any | - If any fees are to be charged by Eclipse for withdrawals and payments then these should be specified. Then when the tenant is being configured in production: - The config elements fees.amount.config.* should be set up. If not provided they default to 0. If provided then config elements fees.wallet.config.* should be set up to specify where the fees should accumulate. |
| ZA_PNP_CASH withdrawals, ZA_PNP_TENDER withdrawals, ZA_PNP_CASH top-ups | - A system wallet must be set up under the tenant for PNP top-ups and withdrawals. Ukheshe will do this. |
| VAS Catalog & Payments | - Accounts must be created or configured on the applicable VAS partners and system wallets set up to be credited when VAS is purchased |
| Message Integrity | - HMACOutboundSignatureKey HMACInboundSignatureKey - HMACInboundSignaturePositions should all be set. A good way of generating a random secret for HMAC is: OpenSSL rand -base64 33 |
Technical Prerequisites
The tenants sandbox access logs will be checked to ensure the following practices are being adhered to:
- JWT’s are being reused and not obtained too often
- Unnecessary calls, polling etc are not being done
- Callback URLs are being processed
- If card details are being provided to an end user then the tenant must provide an overview of the process they are following and written confirmation that at no point are they calling APIs to get unmasked card details from their servers.
Updated about 2 years ago