Appendix C – Test Plan *
**
The purpose of the following section is to validate the implementation of the Generic POS Channel protocol for the transaction sets chosen by the Integrator. An Integrator may choose to only implement a subset of all the Test Cases (1, 2, 3, 4 and 5) below but, having chosen a Test Case, all sub Test Cases and the transaction types applicable to these Test Case must be performed. By way of example, if an Integrator only wants to perform Debits then only Test Case 3 comprising 3.0, 3.1, 3.2, 3.3 and 3.4 need to be tested and logs for these submitted. In this case logs for 3.0a, 3.1a, 3.1b, 3.2a, 3.3a, 3.3b, and 3.4a would need to be submitted.
Integrators should keep logs of all requests sent to the Indigo Server as well as the responses received and the data and
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
IYS Implementation Guide
**
NewPos Release Notes *
**
The Mauritius Central Automated Switch (MauCAS), a digital hub exclusively owned and managed by the Bank of Mauritius, facilitating seamless 24/7 payment routing among various operators. CIM Finance is introducing QR-code-based payments through seamless integration with MauCAS, thereby diversifying the payment options for their valued merchants.
How Automatic Billing Updater works *
**
Below is a high-level visual representation of how Automatic Billing Updater works:
JSON Request *
**
{
"Command": "Authorisation",
"DeviceSerialNumber": "81546628",
"MerchantReference": "Roland20190212.1",
"Currency”: “ZAR”,
"Amount": 1001,
"BudgetPeriod" : 0,
"CashAmount": 0,
"Terminal" : "Roland"
}
DiVert Batch Upload File XML Specification *
**
Divert Batch Upload *
This section describes the contents of the Divert batch file uploadable in Backoffice with Command “DivertUpload”. The Divert Backoffice user guide on how to upload the Divert Batch XML file in Backoffice. The same functionality can be implemented using Enterprise API.
The Divert Batch Upload File has the following XML tags:
V_XML Version="2.0" Direction="Request">
<DiVert Version="1.0" Command="DiVertUpload" Count="" Amount="">
<Date></Date>
<Filename></Filename>
<CreateTransactionUrl></CreateTransactionUrl>
<DiVertItem ApplicationID="" Mode="test" Command="Debit">
<Amount></Amount>
<Currency></Currency>
<OrderDescription></OrderDescription>
<MerchantReference></MerchantReference>
<AllowBudgetPeriod>false</AllowBudgetPe
Settlement of a previously successful Authorisation *
**
* *
Below is a step-by-step illustration of how to create a new BIN. This request will come from authorized personnel ONLY at the Acquiring bank for the creation of a new BIN.
Navigation Path:*
From the main menu select:
Systems > iVeriDB BIN > Local BIN*
1. Select the ‘Create New’ tab to initiate the process of creating a new BIN.
The following General information’s tab will appear.
2. Here the user will complete the information relating to the BIN as received from the Acquirer.
BIN – BIN number will be provided by the Acquirer. This applies to the creation of a new BIN as well as amending the parameters of an existing BIN.
Card Number Length – We require confirmation from the Acquirer regarding the Card Number length. Specifically, we need confirmation of both the minimum (referencing the fi