1. Overview

This section provides an overview of the Allps Payment Stream integration process and the relationships between various entities within the system.

The Micro Lender will sign up with ALLPS to use the Payment Stream. ALLPS will then supply the Micro Lender with a payment terminal and website details. The GSA (General Services Agent) will be responsible for setting up the Users and the terminal.

Concurrently, the Micro Lender will sign up to use MaxMoney. Mycomax will assist the GSA with setting up the users on MaxMoney, as well as configuring the necessary events and MaxCollect functionalities.

The system architecture is structured as follows:

• One user may have access to one or more branches.

• One branch may have one or more employers defined.

• One employer may have one or more clients (borrowers) defined.

• One client (borrower) may have one or more Promissory Notes created.

• Each Promissory Note will have one or more instalments.

• Each instalment could have zero or more replies associated with it, depending on its status and the actions performed on it.

• Additionally, one client may have one or more client accounts defined.

• For each client account, one or more credit payments may have been made.

Important: An employer must be created and exist before creating a client (borrower). Similarly, a client (borrower) must be created and exist before creating a promissory note for that client (borrower). Additionally, a client account must be created and exist before a credit payment to the account can be requested.

Typical users of EFT Credits include:

• Micro Loans / Micro Finance institutions

• Employers

2. Prerequisites

To access Allps, you must meet the following prerequisites:

• Active internet connection: Essential for all Allps operations.

• Valid Allps Web Service user name and password: Provided by ALLPS.

• Assigned Allps branch: Your user account must be linked to a specific branch.

The user attempting to log on must have the user right "Allow access to Allps web services" assigned. User management, user right assignments, and branch allocations can be managed from within Allps-i and take immediate effect once changed.

2.1 AddClient

For a client to be successfully added or created:

• The client number must be unique for the specific branch.

• The employer code specified must exist for that branch.

• The cellular number of the client is compulsory to allow access to the Intecon Electronic Payment Modules. This cellular number must be unique per Client Number.

2.2 CreatePromissory

This function is used to create a payment instruction without requiring a card swipe or PIN, and thus no terminal interaction. It's applicable for creating NAEDO, EFT, or Social Grant EFT Promissory Notes.

When creating this type of Promissory Note, user presence cannot be verified, which means Intecon Transaction Fees cannot be recovered from the client.

2.3 CancelPromissory

This function allows for the cancellation of a promissory note, which prevents any of its instalments from being presented for collection.

2.4 PrintPromissory

This function provides for the printing of a Promissory Note and its related agreements that need to be signed by the payer. It is the responsibility of the Intecon client to ensure that all required mandates and agreements are signed for each Promissory Note created.

Printing will only succeed if the Promissory Note’s status is ACTIVE, PENDING, or CANCELLED. If the status is CANCELLED, the necessary cancellation document will be returned instead of the creation documentation.

2.5 EditInstalment

This function is used to change the action date, amount, or tracking parameter of an existing Promissory Note. However, amounts can only be changed for Promissory Notes in the  EFT, and Social Grant EFT payment streams.

2.6 AddClientAccount

This function is used to register a client or beneficiary account in the system against which credit payments can be made. The account details will be associated with the specified client number. Future client credit payments can only be made to accounts that have been registered in the system.

2.7 PayToClientAccount

This function is used to register a credit payment request to an existing client. The request accommodates the payment of an amount to one or two previously registered client accounts, as well as specifying an additional cash component that should form part of the credit payment transaction.

It's important to note that this only initiates a payment request. A successful reply indicates only that the initial validation of the request (in terms of system parameters and account validity through a CDV check) was successful.

• For normal bank accounts, payments will typically reflect in the client’s account on the next working day (standard EFT "sameday" credit payment rules apply).

• For Wallets, credit payments will generally reflect in the client's wallet account within 10 minutes under normal circumstances.

• No action, other than validating future due amounts, will be taken on amounts specified as "cash."

2.8 PrintClientCredit

This function provides for the printing of a client credit payment confirmation document to be handed to the Allps client. This document only reflects the payment status from an Intecon perspective and does not reflect the payment status at the recipient bank.

Depending on the recipient account type, the payment confirmation document will reflect:

• The delivery status of a payment requested to a FEZA Wallet.

• The delivery status of a payment requested to a normal bank account via the SDV EFT payment stream.

For the SDV EFT payment stream, successful delivery could be followed by a separate payment return transaction from the recipient bank on the payment request date or a few days later.

2.9 CreateWallet

This function is used to request the creation of a Wallet for an existing client in the branch. A Wallet is associated with a cellular telephone number, so the client's cellular telephone number must be defined and unique among clients in a branch. Additionally, the client's date of birth and gender must be populated with valid values before calling this method.

If the initial validation passes, the request will be processed externally (normally within 10 minutes).

• A new wallet can be requested without a card and PIN mailer, in which case the wallet will only be accessible from the client's cellular telephone.

• If a card and PIN mailer are specified during creation, they will be linked to the Wallet if successfully created. In this case, the Wallet can be accessed from any Point of Sale or ATM using the assigned card and PIN from the PIN mailer envelope.

If a Wallet is successfully created, the Wallet account will automatically be added to the client’s account list and can be used in a credit payment request to the client. It's important to note that the wallet number is not a valid bank account number and can only be used for activities within the Allps environment.

2.10 PrintCardIssueReceipt

This function provides for the printing of an acknowledgement of FEZA card and PIN Mailer receipt that needs to be signed by the bank card recipient. It is the responsibility of the Intecon client to ensure that all required documentation is signed. This function will only succeed if a successful request was made to assign the specified card number to the Allps client.