Appendix D – Receipt Requirements * ** At the conclusion of each transaction a customer receipt for the cardholder to keep as a record of the transaction needs to be printed. In addition, a merchant receipt for the merchant to keep as a record of the transaction needs to be printed as well. Not all fields are returned for every transaction depending on the type of transaction, the result and other circumstances so, in the event that a field is not returned in the Response then it is not required that it be printed on the receipts. Data Element Source Customer Receipt Merchant Receipt Notes AcquirerReference Response Y Y If available Address Merchant Y* Y* ApplicationIdentifier Response Y* Y* If available ApplicationLabel Response Y* Y* If available AuthorisationCode Response Y Y If availab

Preface * ** Changes included in this document include: Original Document. Changes made by R. Elferink changing the Merchant Invoice Field to 32 characters and adding the Merchant Reference Field as well as the Budget Period Added the reconciliation status to indicate whether the transaction has been reconciled with the bank and if so, if it is correct. Changed the brand name to iVeri from Set2Go Added the ability to Perform Authorisations and Authorisation Reversal. Corrected CCYY to YYYY to clear up confusion with 2101 being the year 01 in the 21st Century. Corrected formatting in “Reference Invoice Number” Change the names of the following fields in line with that used though out the iVeri Gateway (previous name – new name): Merchant Invoice Number – Merchant Reference Transaction Reque

Batch Processing Xml Specification * **

Field and Reply Codes * ** Result Status Code * Result Status Code ResultDescription 0 N/A (Approved) -1 Timeout waiting for response. Try again -3 Hot card -4 Denied -5 Please call -6 Card Address Failure -7 Card Security Code Failure -8 Card Type not accepted -9 Unable to process the transaction -11 Invalid Amount -12 Invalid Budget Period -14 Invalid Card Number -15 Invalid Track2 -16 Invalid Expiry Date/Card Period -18 Invalid Authorisation code -255 * Unknown Error * Recon Status * * VALUE* * DESCRIPTION* "-1" Unreconciled - The reconciliation process for this transaction has not taken place yet. "0" Reconciliation has taken place and the result code accurately depicts the status of the transaction "1" Reconciliation has taken place and the transaction could not be found. "2" Reconcil

How Automatic Billing Updater works * ** Below is a high-level visual representation of how Automatic Billing Updater works:

*iVeri needs to:* Provide 1st line support to the merchant. Provide support on the Back End Admin enquiries . Inform eCommerce 3rd Party on merchants to be onboarded. Onboard the merchant on the Admin Gateway & Cardinal for IYS. Provider merchant with credentials in order for them to add iVeri as their payment processor on their IYS Backend System. * eCommerce 3rd Party needs to: * Set up and Create the merchant on the IYS Platform (Store ID). Provide 2nd line support. Address technical queries that the merchant may have. * Merchant needs to: * Sign in and Set up their Online Store Configure and enable iVeri as the Payment processor using the iVeri provided store credentials Send iVeri their Store ID in order for iVeri to complete the onboarding

Merchant BIN management is crucial. The BIN configuration determines what actions a merchant is permitted or restricted to perform.  A Merchant may request certain restrictions within a BIN The below scenario will demonstrate the importance of the BIN Management process that may be amended at a Merchant level: Meet John. John is a merchant who has expanded his business over the past 5 years. He has international clients but has decided to shift his business focus from international to local, highlighting economic downturn and the fees attached to international cards as his main reasons. John no longer wishes to do business internationally. In line with his cost cutting initiatives, he has also decided that he will no longer accept credit cards. John proceeds lodges a query with support to

Below we will look at the step-by-step process of enabling a merchant for MauCAS via the Administration Website. Navigation Path: To navigate to this screen, Select Applications > Update > Provider Specific. 1. Click on the ‘Common Provider’ expansion tab. 2. Navigate to the ‘Third Party’ parameter and click on the expansion tab. 3. Navigate to the ‘MauCAS enabled’ parameter. This parameter defaults to ‘No’. 4. To enable MauCAS, untick the default value. 5. From the dropdown, select ‘Yes’. 6. The next parameter that needs to be populated is the ‘MauCAS Merchant ID’. This parameter needs to be populated with the Merchant ID. The Merchant ID is provided / supplied by the Acquirer. 7. Untick the default value and enter the MauCAS Merchant ID. 8. Lastly, save the changes that you have captured

Application Identifiers: There are 2 application modes: Live and Test. To ensure updates and changes are configured for a merchant’s application, select the LIVE application. BackOffice Services: How to navigate to the BackOffice Services screen: Applications > Update > BackOffice Services 1. This is where BackOffice Services are created for the merchant. This is a mandatory step that would need to be updated in order to activate an application for a Merchant. b1 [1] 2. Under BackOffice Services, under ‘Local’, click on the dropdown and navigate your way to ‘FNB Back Office’. This update will provide the Merchant access to BackOffice. Once the user has captured the details under Local, click on the ‘Update’ tab. This following screen will now appear. b2.1 [2] 3. Under the ‘Update BackOffic

The release notes provided in V1 of this document serve as an initial preview of the changes expected in the upcoming production release of the PocketPos application *** Summary *** The PocketPos release notes will contain information related to the new PocketPos application release. The release notes will include the impact of software release to the intended target audience. *The release notes will adopt the format outlined below, as applicable:* *Compliance* Refers to the adherence of the software to specific industry standards, regulations, or internal policies. This includes ensuring that the software meets legal and regulatory requirements, follows best practices, and aligns with established security and quality *Optimisation* The process of refining or improving a software solution