What is SIBS Backoffice?

SIBS Backoffice is an online platform that provides merchants access to a set of useful management and monitoring features for SIBS services. 

SIBS Backoffice is a dynamic, in real-time platform capable of offering omni-channel payment services, by providing an integrated vision of your business and ensuring you have all the insights and control over your payment’s workflow. 

Core functions

SIBS Backoffice offers a comprehensive and user-friendly interface designed to support your payment strategy in a variety of ways. 

One of SIBS Backoffice’s key features is the ability to setup and manage your payment operation in a much simpler, quicker, and straightforward way. 

In addition, SIBS Backoffice also provides analytics tools that allow you to gain deep insights into your payment data. These tools can help you identify trends, spot opportunities for optimization, and make data-driven decisions that can have a significant impact on your business. 

In SIBS Backoffice, merchants can: 

• Check transactional information in real-time; 
• Perform refunds; 
• Visualize payments data dashboards; 
• Extract transactional data; 
• Check reconciliation operations; 
• Configure current payment methods; 
• Add new payment methods. 

Easy Setup

1. Register into the onboarding process

If you haven’t had any onboarding process with SIBS regarding SIBS Backoffice, make sure you follow this link in order to receive credentials to the platform. 

Upon completing the onboarding process, you will receive credentials, including an e-mail and activation code needed to register your access on the SIBS Backoffice. 

2. Activate your account

After receiving the credentials needed (which are valid for 4 days), you must access the following login page and go to “Click here to activate your account”. 

In the form available on the page, insert the e-mail and activation code previously received and choose a password for your SIBS Backoffice account. 

The final step is to click on the “Click here to activate your account” button. 

For each transaction made by the user, SIBS Gateway sends a notification to the merchant by e-mail or via an endpoint configuration. This notification (Webhook) will inform the Merchant of the details and status of a transaction.

The type of webhook sent by the SIBS Gateway must be configured on the SIBS Gateway Backoffice platform. If the merchant chooses the Webhook URL type, the merchant must enter the URL where they wish to receive the webhook. If the Merchant chooses the Webhook E-mail type, the Merchant must enter the default e-mail address that will receive the notifications sent by SIBS Gateway. The webhook can be configured per payment method and per merchant, store or terminal.

To configure the Webhook URL type, the merchant needs to make the following technical settings:

• The webhook endpoint must be available in TLS 1.2 and on ports 80 or 443;
• The merchant must store and enter an encryption key on the SIBS Gateway V2 Backoffice platform or use the key suggested by the platform in order to decrypt the webhook received;
• The webhook is encrypted with AES-256;
• The Merchant must enter a specific e-mail address where they will receive notifications regarding problems with the webhook.
  

For the e-mail type Webhook, only one notification will be sent per transaction. If the Merchant chooses the Webhook URL type and does not acknowledge the reception of the notification, SIBS Gateway will trigger the Webhook Retry System.

In the webhook structure, the “notificationID” field plays a crucial part in the webhook sending process. This field identifies the webhook that was sent by SIBS Gateway and will be used by the Merchant to send the acknowledge of the reception of the webhook to SIBS Gateway, in addition to the “statusCode” field with value “200” and the “statusMsg” field with value “Success”. This will prevent the Webhook Retry System from triggering and, in case of URL type webhook, from sending an e-mail with the failed notifications.

In case there’s communication or system issues, the Webhook Retry System cannot guarantee the message sequence, especially if the time difference between the notifications is smaller than the time it takes to process them. Once the issues are resolved, new notifications will arrive in real-time and old notifications will be resent. If for some reason the webhooks are not retried or the Merchant is not able to open the webhook, SIBS Gateway provides the “Checkout Status” service where the Merchant can access information about the status of a transaction.

We offer a robust solution that provides you with real-time notifications or webhooks for specific events, ensuring you stay informed about changes in transaction payment status. 

By setting up event notifications, our platform sends API responses to your endpoint. For seamless integration with asynchronous cloud communications, these event notifications are essential. 

Furthermore, you can take advantage of outgoing messages that are generated and sent whenever transactions are performed, or updates are made to a SIBS Backoffice account. 

This transaction allows a Cardholder to pay for a good or service via an electronic operation that debits his account and will credit the Acceptors banking account. Consists in an immediate debit in the Client account and it is an effective payment on the moment of the transaction. 

A cancelation is performed using a previous payment authorization (AUTH), by referring its transactionID and sending a POST request over HTTPS to the /payments/{transactionID}/cancelation endpoint. 

When canceling a payment and, if sent within the time-frame, the authorization is not captured yet, instead it causes an authorization reversal request to be sent to the card issuer to clear the funds held against the authorization. If requested over a MULTIBANCO Reference generated but not paid, the reference will be cancelled. 

POST /api/v1/payments/{transactionID}/cancelation 

The purpose of this operation is to refund the amount of a previous payment, crediting the cardholder account and debiting the Merchant account. 

A refund can be: 

Performed against a previous payment, referring its transactionID by sending a POST request over HTTPS to the /payments/{transactionID}/refund endpoint. 

Performed against a purchase (PURS) or captured pre-authorization (AUTH > Capture) payment types. 

It can be a full refund, when the total amount of the purchase is refunded to the cardholder, or a partial refund, when a subtotal of the purchase is refunded to the cardholder. 

POST /api/v1/payments/{transactionID}/refund

A capture is used to request a debit to previously authorized transaction. 

A capture request is performed using a previous payment authorization (AUTH) payment by referring its transactionID and sending a POST request over HTTPS to the /payments/{transactionID}/capture endpoint. 

Capture can occur in different ways:

• Full: capture the full amount authorized and finish the purchase.
• Partial: split the capture over one or several capture requests, up to the total amount authorized.

POST /api/v1/payments/{transactionID}/capture 

Request URL

https://spg.qly.site1.sibs.pt/api/v1/payments/{transactionID}/capture 

Request headers

Authorization: Bearer 0276b80f950fb446c6addaccd121abfbbb.eyJlIjoiMTk4N (...)
X-IBM-Client-Id: 8247e05b-e64d-4948-843d-6e8b30224e39
Content-Type: application/json 

Request body

{ 
"transactionID": "s2CB2CH3U91PdGDHsacJ", 
    "execution": { 
        "startTime": "2023-11-09T16:19:11.924Z", 
        "endTime": "2023-11-09T16:19:12.052Z" 
    }, 
    "paymentStatus": "Timeout", 
    "returnStatus": { 
        "statusCode": "000", 
        "statusMsg": "Success", 
        "statusDescription": "Success" 
    }    
    "maxAmount": {
        "value": 5.5, 
         "currency": "EUR" 
    }, 
     "minAmount": { 
         "value": 5.5, 
         "currency": "EUR" 
    }, 
     "entity": "24000"  
}

Consists in an authorization for a future payment.

Various transaction types available to meet your payment needs. 

In this documentation webpage, you will find how to use our APIs and Webhooks in order to control your QR Code Express.

Our QR Code Express APIs and Webhooks enable you to:

• Trigger notifications
• Check details from QR Code Express purchases
• Manage and edit QR Code Express prices and stock

Get purchase information

Webhook notifications

You can use Webhooks to proactively receive, in real-time, the payment status of QR Code Express purchases and its associated information (e.g. client data).

For more information on how to configure Webhooks for QR Code Express, click here.

Request purchase details via API

Use this API to request the payment status of QR Code Express purchases and its associated information (e.g. client data). Information is provided transaction by transaction.

If you don’t have access to this API yet, please register at SIBS Payment Gateway.

Follow the instructions below to configure the API.

Step 1: Configura the endpoint

Step 2: Define the header

Step 3: Get the response

Step 1: Configure the endpoint

Step 2: Define the header

Header parameters

Step 3: Get the response

{
    "merchant": {
    "terminalId": "{{terminalId}}"
    },

    "transactionID": "{{transactionID}}",
    "amount": {
    "currency": "EUR",
    "value": "1.23"
    },

    "paymentType": "PURS",
    "paymentStatus": "Success",
    "token": {
    "tokenType": "MobilePhone",
    "value": "351#911111111"
    },

    "execution": {
    "endTime": "2024-02-22T10:27:25.371Z",
    "startTime": "2024-02-22T10:27:25.258Z"
    },

    "returnStatus": {
    "statusCode": "000",
    "statusMsg": "Success",
    "statusDescription": "Success"
    }
}

Manage Stock

You can use the QR Code Express stock API to perform the following actions:

• Add stock units
• Remove stock units
• Define stock units
• View stock units

Add Stock Units

This action is used to add stock units to an existing QR Code Express. The available request fields are the following:

The response fields are the following:

Remove Stock Units

This action is used to remove stock units from an existing QR Code Express.

The available request fields are the following:

The response fields are the following:

Define Stock Units

This action is used to define the stock units of an existing QR Code Express. The available request fields are the following:

The response fields are the following:

Obtain Stock Units info

This action is used to obtain the current stock units info of an existing QR Code Express.

The available request fields are the following:

The response fields are the following:

Error Codes

When performing API call, the following errors can appear: