Front office operations

The SIBS Gateway supports two types of operations, purchases and authorisations, where the purchase triggers the payment immediately and the authorisation keeps the amount captive until a capture is performed. 

Purchase: 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. 

Authorisation: Consists in an authorisation for a future payment. It allows the Merchant to get an authorisation from the Issuer keeping the amount captive in the Cardholders banking account; the transaction is authorised and the purchase will be triggered in a second moment, when the merchant needs to trigger a “Capture” on the Backoffice. 

Backoffice operations

At a back-office level, Cards supports the following types of operations: 

Capture

Used when the Cardholder has provided an authorisation for the payment on a 1st stage and the amount is captured. Used on a 2nd stage to execute the payment, which can happen in different ways (always triggered over an authorisation): 

• Full: capture the full amount authorised and finish the purchase; 
• Partial: split the capture and do several payments up to the total amount authorised. 

Refund

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: 

• Full: when the total amount of the purchase is refunded to the Cardholder; 
• Partial: when a subtotal of the total purchase is refunded to the Cardholder. 

Cancellation

Requests the cancellation of the amount (full or partial) of a previous authorisation. 

Merchant Initiated Transaction 

The purpose of this operation is to allow the Merchant to charge a service. In the first stage the Cardholder requests to register the payment as a Cardholder Initial Transaction and authorise the Merchant to do future debits (Merchant Initiated Transactions) in accordance with the service. 

Cardholder Initiated Transaction: needed to register as initial conditions. Authentication and consent collected from Cardholder.

Merchant Initiated Transaction: triggers following payments. 

Currently, two types of Merchant Initiated Transactions are accepted: 

• Recurring: Transactions processed at fixed, regular intervals not to exceed one year between Transactions, representing an agreement between a Cardholder and a Merchant to purchase goods or services provided over a period of time; 
  
  
• Unscheduled Card On File: A transaction using a stored credential for a fixed or variable amount that does not occur on a scheduled or regular occurring transaction date, where the Cardholder has provided consent for the Merchant to initiate one or more future transactions that are not initiated by the Cardholder.

It is possible to establish the relationship below among the Front office & Backoffice operations, having in mind that Backoffice operations will act on the Front office operations: 

	Purchase	Authorisation	Capture
Capture		1
Refund	4		3
Cancellation		2

1. A capture can act over an authorisation of the total or partial amount; 
2. An authorisation can be cancelled and the amount kept on hold will be released; 
3. An effective payment through a capture can only be refunded; 
4. An effective purchase only allows to trigger a refund in the Backoffice; 

Integration options

SIBS Gateway provides a collection of APIs that enables our Clients to process, manage payments and accept payments from banking cards. 

It is not necessary to choose all the SIBS Gateway payment solutions, our Clients can choose which API to use. 

Form integration

Simple form integration with javascript based widget, on three simple steps: 

Step 1: Prepare the checkout

Step 2: Get the payment status

Step 3: Merchant Notification: Receive payment status

Step 1: Prepare the checkout

Sends payment data, except payment method data. 

1. First, perform a server-to-server POST request to prepare the checkout with the required data, including the order type, amount and currency. The response to a successful request is a JSON with a transactionID, which is required in the second step to create the payment form.

2. Create the payment form: displays a payment form to allow customers to submit payment method data. To create the payment form you just need to add the following lines of HTML/Javascript to your page and populate the following variables:

• The checkout transactionID that was returned in the response from step 1.

<script src="https://{QLY/PRD}/assets/js/widget.js?id={transactionID}"></script> 

3. The {formContext} that you get in response from step 2.   

{formConfig}; 
{formStyle} (optionally)  

4. Configures the Merchant redirectUrl, which is the page on your website where the customer should be redirected after the payment.

5. Optional parameter that allows the user to change the form style. 

Step 2: Get the payment status

Once the payment is processed, the customer is redirect to your redirectUrl.

Step 3: Merchant Notification: Receive payment status. 

SIBS Gateway will send the notification of the asynchronous payment status. 

Server-to-server integration

The Server to Server integration is also known as direct integration as it enables communication between the two servers, SIBS and Merchant. Cardholders can finalise a payment without being redirected to the SIBS Gateway Form. This integration is suitable for Merchants that store the payment data before sending them to the SIBS Payment Gateway. 

Financial operations

Step 1: Prepare the checkout

Step 2: Display payment method options to customer

Step 3: Update payment method data

Step 4: Get the payment status

Step 5: Merchant Notification: Receive payment status

For financial operations, Server-to-Server Integration is based on the following steps: 

Step 1: Prepare the checkout

Prepare the checkout: sends payment data, except payment method data. 

First, perform a server-to-server POST request to prepare the checkout with the required data, including the order type, amount and currency. The response to a successful request is a JSON with a transactionID, which is required in the second step. 

Step 2: Display payment method options to customer

The next step is to provide the payment method options and get payment data from the customer: 

• Card
• MULTIBANCO
• MB WAY ID
• Authorised payment

Step 3: Update payment method data

Sends payment method and its required data. 

Perform a payment request, call SIBS Gateway API with the collected data accordingly with the method. 

Step 4: Get the payment status

Get the payment status: gets the payment status. 

Step 5: Merchant Notification: Receive payment status. 

SIBS Gateway will send the notification of the asynchronous payments to the merchant server.