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
IYS Implementation Guide
**
Ingenico RA1 based devices ***
Index
Prompt
Description
01
Amount
02
Please enter new total
03
Total
04
amount again
05
Please enter
06
Add
07
Input
09
Balance
10
Tip
11
Gratuity
12
Service
13
Donation
20
Waiter ID
21
Waiter logon
22
Table number
23
Bill number
24
Location reference
25
Tab Number
26
Operator ID
37
Split by
38
number of parties
39
to pay
3A
Auth code
3B
Cashback
3C
Due
3D
Maximum
3E
Minimum
3F
Multiples of
40
Format
41
Date
42
Incorrect
43
ID incorrect
44
Number incorrect
45
Bill not found
46
Cash
47
Card
48
Cheque
49
Voucher
4A
Payment
4B
Refund
4C
Voucher number
4D
Identity code
4E
Kilometers
4F
Car number
50
Product code
51
Number of items
52
Room number
53
Plu number
Default
Input
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
JSON Request *
**
{
"Command": "Authorisation",
"DeviceSerialNumber": "81546628",
"MerchantReference": "Roland20190212.1",
"Currency”: “ZAR”,
"Amount": 1001,
"BudgetPeriod" : 0,
"CashAmount": 0,
"Terminal" : "Roland"
}
Settlement of a previously successful Authorisation *
**
* *
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.
JSON Request *
**
{
“Command” : “GetSystemInfo”,
“DeviceSerialNumber” : “”,
}
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