The MULTIBANCOConnect is a type of integration that enables the connection of point-of-sale software with a serviced SmartPOS terminal through the MULTIBANCOConnect application and the SIBS protocol. Once the connection is established, the point-of-sale system sends requests to the MULTIBANCOConnect application. These requests can include purchase transactions, returns, closures, receipt information, among others. In an integration with MULTIBANCOConnect, authentication is carried out using credentials, so there is no need for recurring login. More information on the integration coming soon.

What type of problem does your Castles terminal has? Screen and Display Connection Battery/Charging Printer PIN PED Updating apps

Screen and Display Connection Battery Printer PIN PED Updating apps

Check out the latest updates for SIBS Smart Terminals, dating back to January 2025. May 2025 March 2025 January 25

The process to certify your SmartPOS terminal at SIBS begins with its validation and applicability for SmartPOS.  If business accreditation is successful, the manufacturer will initiate the process to certify its terminal to be accepted within SIBS managed networks.   The certification process itself consists of the following five (5) major stages . Each stage is composed of different activities. In the table belowe provide descriptions over them, outlining the correspondent responsibility. Step Description Responsability (1). Evaluation Request for certification by the partner and opening of the process by SIBS. SIBS / Partner (2).Development Development and testing of the solution by the partner. Partner (3).Certification Delivery of the solution to SIBS to begin certification. Testing of the MULTIBANCO network and international brands. SIBS / Partner (4).Pilot Installation of a limited number of terminals in PRD to evaluate the robustness of the solution. SIBS / Partner (5). Closure Completion of the certification process and rollout of the PRD solution. SIBS

Hardware Abstraction Layer (HAL) The SmartPOS HAL is a standard for the development of SmartPOSAPP* that operates independently to the Hardware. It utilizes an abstraction architecture based on the Android Interface Definition Language (AIDL). The AIDL enables the definition of the programming interface agreed upon by both the client (the high-level payment SMARTPOSAPP) and service (the low-level layer that takes care of the hardware) for communication through inter-process communication (IPC). The HAL acts as an intermediary layer that facilitates the integration of multiple applications within the SmartPOS terminals (except Nexgo). Positioned between the SMARTPOSAPP and the vendor’s specific SDK, the HAL serves as a middleware. Its inclusion signifies that SmartPOS software interface is hardware-agnostic. During payment operations the payment application resorts to the HAL to deal with card processing, PIN processing, security related processing, some level of user interface and printing. Remote Key Loading (RKL) RKL is the process of transmitting the DUKPT (Derived Unique Key per transaction) from our Key distribution Host (SIBS) to a terminal. This involves the use of asymmetric techniques for authentication and encryption on both ends, streamlining and securing the key-loading proccess. This not only improves operating efficiency but also enhances security, guarding terminals against tampering. […]

Accepted payments Service enrollment Backoffice browsers Activating your account Card Reader in the mPOS Using the App Account management Proof of payment (receipt) Operation records Security

Here you will find Troubleshooting actions to perform directly with the terminals belonging to the SIBS catalog – Nexgo and Castles, within different scenarios. For support or troubleshooting matters related to terminal models other than Nexgo and Castles, users should contact the correspondent merchant.  

This is a dedicated section with resources that will help you fix problems with the terminal and the SIBS Payment Application.

The Card Reader Interface is a mechanism that runs in the background and allows the reading of a Portuguese Citizen Card Data – i.e., personal data and address. The interface also allows generic card data reading by running a list of APDU commands.  This section aims to support integrators in providing the necessary elements for configuring their applications to use the Card Reader Interface Service and is divided into three sections:  Step 1: Declaring the AIDL file with the service methods Step 2: Connect to the service Step 3: Defining the methods for card reading Step 1:  Declaring the AIDL file with the service methods  To use this interface, the app that invokes it must declare an AIDL file with the methods that the service provides. This file is identical both in the service and in the app and must be in the same package in both cases.   The methods will be available after the first build.  Step 2: Connect to the service When starting the application/feature that needs to use the service, the first thing to do is to create a BrodcastReceiver to receive the intents coming from the service. For that purpose, you can create an extended class […]