When more than one application can be loaded onto a terminal belonging to a bank or an institution, it is called a Shared POS.
You need to analyze whether your institution's devices require additional development to work as a shared POS and, if necessary, get information from the vendor. Some manufacturers state that no additional development is needed for a shared POS, while others state that additional development is required.
Therefore, if we proceed on the assumption that it is necessary, the software processes required for the shared POS must be completed first.
In parallel with the software processes, the following steps must also be taken:
- For devices operating over a GSM line, defining a shared POS APN in addition to the APN definition currently in use,
- Granting authorization so that all traffic coming from the defined shared POS APN, such as transactions, end-of-day (batch close), parameter loading and RKL, can reach the servers,
- Completing the shared POS screen designs; once these processes are complete, application testing can begin.
Points to pay attention to in shared POS testing:
- Testing your own bank's application on a POS device owned by a different bank,
- Testing applications of other banks on your own bank's POS device,
- Running the tests separately for every connection type,
- Testing the application according to the BINs defined in the issuer data,
- Running tests with multiple, different banks, on either your own bank's POS device or a POS device owned by a different bank, are important steps.
The test steps above generally cover the points to watch in the shared POS process. Beyond these items, of course, countless test cases can be created.
In addition, using the infrastructure provided by the manufacturer is one of the key points to consider for user experience. Moreover, going outside this structure or providing additional developments does not seem very feasible.
Once all the processes are complete, what remains is the contracts to be made with the banks or institutions.
