The purpose of this operation is to allow the merchant to charge a recurrent service, in the first stage the cardholder requests the payment as an initial recurring and authorize the merchant to do future debits (following recurring) accordingly with the service 

• Initial Recurring: Required to register as initial recurring 
• Following Recurring: Triggers following payments 

Token

The token is a reference from the card converted into a different code (i.e. identifier/token), allowing the Merchant to save the card for future payments without having the card information for PCI DSS purposes.

Tokenization

Tokenization is the process of substituting a sensitive data element with a non-sensitive equivalent to save this information in the Client wallet and improve the Client experience on the next visit. The token is a reference (i.e. identifier) that maps back to the sensitive data through a tokenisation system. 

The mapping from original data to a token uses a method that render tokens infeasible to reverse in the absence of the tokenisation system, for example using tokens created from random numbers. 

Card-on-file (CoF) consists of a merchant storing a customer’s card details, with the customer’s consent, in order to re-use the details for future payments and to carry out faster checkouts. 

Card-on-file transactions

Card-on-file transactions are initiated by the cardholder and involve either the cardholder giving permission to a company to store their card information for future use, or an agreement between the cardholder and the merchant for the merchant to initiate payments using stored payment information. In the latter case, it is usually used for subscription billing. 

Subscription transactions

Subscription transactions take place on a regular basis, usually at predetermined intervals, as is the case, for example, with a streaming network that has a file of a customer’s card information and makes automatic monthly payments for using the service. In this way, the customer doesn’t need to manually renew their payment on a regular monthly basis, giving the merchant the possibility of storing their card details and thus making the payment without any additional procedure. 

The 3-D Secure authentication protocol is based on a three-domain model where the Acquirer Domain and the Issuer Domain are connected by the Interoperability Domain for the purpose of authenticating a Cardholder during an electronic commerce (e-commerce) transaction or to provide identity verification and account confirmation. 

Card payment is a widely used method for carrying out financial transactions conveniently and securely. 

The card features that will be active will depend on the agreement that the Merchant has with their Acquirer.

SIBS offers card transaction acceptance services in an e-commerce environment, covering the international brands Visa, Mastercard, American Express and UnionPay (UPI).

The solution is fully compliant with the efficiency and security standards stipulated by these brands, using international security standards such as PCI-DSS and 3D Secure, guaranteeing the protection of transactions.

Solutions:

• Tokenization of card data – Tokenization consists of replacing a payment card’s sensitive data, such as the Primary Account Number (PAN) and expiry date, with a unique and secure identifier called a token. The main objectives of this process are to guarantee the security of cardholder information and to reduce the exposure of merchants and the platform to PCI-DSS compliance requirements.
• Merchant Initiated Transactions (MIT) – The Merchant Initiated Transactions (MIT) operation, integrated into the SIBS Gateway platform, represents an excellent solution for processing card payments, combining operational flexibility, robust security and compliance with the highest regulatory standards. This functionality has been designed to meet the growing needs of a dynamic global market, providing Merchants with a powerful tool to carry out automatic, secure and efficient collections, without the need for continuous intervention on the part of the cardholder.
  

SIBS Gateway differentiates itself by integrating these features into a secure, high-performance ecosystem, fully compliant with PSD2 and the strictest industry standards. By automating collections and eliminating operational barriers, it enables global merchants to optimize revenue streams, improve the customer experience and increase loyalty.

Integrated checkout with MULTIBANCO Reference

MULTIBANCO (MULTIBANCO Payment Reference)

It is an asynchronous payment that requests the generation of a MULTIBANCO Reference related to the payment registered by the previous Checkout. With the MULTIBANCO Reference returned in this operation, the customer can perform the payment. 

Front office operations

The SIBS Gateway supports purchases, which are made using the MULTIBANCO Payment Reference method, in which the purchase triggers payment immediately. 

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. 

Backoffice operations

At a back-office level, MULTIBANCO Payment Reference supports the following types of operations: 

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 or MULTIBANCO Reference generated, but not paid. 

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.

^*1 Validity

The Payment Start Date (EPS_INIDAT) field must be a valid date, greater than or equal to the current date, but never more than 5 years from the current date.
The Payment Limit Date (EPS_LIMDAT) field must be a valid date, greater than or equal to the Payment Start Date (EPS_INIDAT), but never more than 5 years from the current date.

MB WAY is a Wallet created and developed by SIBS, in the scope of the most existing technologies that meets the market demands. This payments solution offers to the Merchants and Service Suppliers the possibility of providing to their clients a remote payment platform in unattended channels, such as vending machines and parking meters, as well as in attended channels such as tv-commerce, e-commerce, m-commerce and others. 

In order to meet the market demands, the MB WAY service introduced a more integrated payment experience for purchases performed in a Merchant mobile app. The in-app operative allows the Merchant app to invoke the MB WAY app to authenticate the transaction; afterwards, the Merchant app reappears, displaying the operation result (In-App Operative). 

All communications between the Merchant and SIBS are carried out using the HTTPS protocol and authenticated by a certificate.