SIBS PAYMENT GATEWAY - Getting Started

spaceship
Form Integration

Form Integration is based on three simple steps:

Prepare the checkout

Create the payment form

Get the payment status

credit-card
Server-to-Server Integration

Server-to-Server Integration is based on the following steps:

Prepare the checkout

Display payment method option to customer

Create the transaction

Get the payment status

box-3d-50
BackOffice APIs

There are also provided BackOffice APIs to perform a:

Capture

Cancellation

Refund

Recurring

customer-support
Webhooks

Webhooks are HTTP callbacks that notify you of all events you subscribed for on an entity.

Form Integration


The Form integration solution enables merchants to integrate either to the SIBS Gateway thru a secure Form avoiding a PCI-DSS Certification.

This the quickest and simplest way to integrate allowing merchants to use 3 different payment methods (MB WAY, Credit Cards and MB Reference) using a single Form.

Besides this, Form integration offers three types of layouts to suit better the merchant needs.

Form Integration is based on three simple steps:

  • Prepare the checkout: sends payment data, including payment method data.
  • Create the payment form: displays a Payment Form to allow customers submit payment method data.
  • Get the payment status: gets the payment status.


  • Prepare the Checkout

    First, perform a server-to-server POST request to prepare the checkout with the required data,where you should include the payment type, amount, currency and payment methods allowed.

    The JSON of your POST body, can be composed of various Complex Types:

    "merchant": {

    "terminalId": {{terminalId}},

    "channel": "web",

    "merchantTransactionId": "gp9253eg4o"

    }

    For more info check SIBS API Market

    "transaction": {

    "transactionTimestamp": "Current Date",

    "description": "My transaction -> Order Order Id: gp9253eg4o",

    "moto": false,

    "paymentType": "PURS",

    "amount": {

    "value": 5,

    "currency": "EUR"

    },

    "paymentMethod": [

    "REFERENCE",

    "CARD",

    "MBWAY"

    ],

    "paymentReference": {

    "initialDatetime": "Current Date",

    "finalDatetime": "Expiration Date",

    "maxAmount": {

    "value": 5,

    "currency": "EUR"

    },

    "minAmount": {

    "value": 5,

    "currency": "EUR"

    },

    "entity": "24000"

    }

    }

    For more info check SIBS API Market

    "customer": {

    "customerInfo": {

    "customerName": "Client Name",

    "customerEmail": "client.name@hostname.pt",

    "shippingAddress": {

    "street1": "Rua 123",

    "street2": "porta 2",

    "city": "Lisboa",

    "postcode": "1200-999",

    "country": "PT"

    },

    "billingAddress": {

    "street1": "Rua 123",

    "street2": "porta 2",

    "city": "Lisboa",

    "postcode": "1200-999",

    "country": "PT"

    }

    }

    }

    For more info check SIBS API Market

    "recurringTransaction": {

    "validityDate": "2022-09-28T17:37:31.4095147+00:00",

    "amountQualifier": "DEFAULT",

    "description" : "My transaction -> Order XPTO"

    }

    For more info check SIBS API Market

    "tokenisation":{

    "tokenisationRequest":{

    "tokeniseCard":true

    }

    }

    For more info check SIBS API Market


    The response to a successful request is a JSON with an transactionID, which is required in the second step to create the payment form.

    With the transactionID, will be present as well a formContext that will be used on teh following step

    POST https://spg.qly.site1.sibs.pt/api/v1/payments

    Request URL:
    /api/v1/payments
    Request Headers:

    Request Body:




    Create the payment form

    To create the payment form you just need to add the following lines of HTML/Javascript to your page and populating the following variables:

  • The checkout's transactionID that you got in the response from step 1:
  • <script src="/assets/js/widget.js?id={transactionID}"></script>

  • The {formContext} that you get in response from the firs step, a {formConfig} and optionally {formStyle}
  • <form class="paymentSPG" spg-context="{formContext}" spg-config="{formConfig}" spg-style="{formStyle}"><form>
    Your   transactionID , and   formContext   from step 1:

    TransactionID :

    The

    {formConfig} and optionally {formStyle} are importante to being able to create the from correctly. About this two below you can find an example of each:

    { "paymentMethodList": [],

    "amount": { "value": 5, "currency": "EUR" },

    "language": "en",

    "redirectUrl": "https://ww.pay.sibs.com/documentacao/sibs-gateway",

    "customerData": null }


    { "transaction": {

    {

    "layout": 'default',

    "theme": 'default',

    "color": {

    "primary": "",

    "secondary": "",

    "border": "",

    "surface": "",

    "header": {

    "text": "",

    "background": ""

    },

    "body": {

    "text": "",

    "background": ""

    }

    },

    "font": ""

    }




    Get the payment status

    Once the payment has been processed, the customer is redirected to your redirectUrl (defined in "spg-config"

    code>), you can check the status of your transaction making a GET request.

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

    Request URL:

    /api/v1/payments/{transactionID}/status

    Request Headers:

    Server-to-Server

    The Server to Server Integration is a direct integration that enables direct communication between the merchant and SIBS.

    Thru this integration the cardholders can finalize the payment without being redirected to the SIBS's form.

    For Card payment method The integration is suitable for PCI-DSS Certificated merchants that need more flexible workflows on frontend and backend processes.

    Server-to-Server Integration is based on the following steps:

  • 1. Prepare the checkout: sends payment data, including payment method data.
  • 2. Display payment method option to customer: displays payment method option to customer.
  • 3. Update payment method data: sends payment method and its required data.
  • 4. Get the payment status: gets the payment status


  • Create Checkout Server-to-Server

    First, perform a server-to-server POST request, the same as Form Integration, to prepare the checkout with the required data,where you should include the payment type, amount, currency and payment methods allowed.

    The JSON of your POST body, can be composed of various Complex Types:

    "merchant": {

    "terminalId": {{terminalId}},

    "channel": "web",

    "merchantTransactionId": "{{mti}}"

    }

    For more info check SIBS API Market

    "transaction": {

    "transactionTimestamp": "Current Date",

    "description": "My transaction -> Order XPTO",

    "moto": false,

    "paymentType": "PURS",

    "amount": {

    "value": 5,

    "currency": "EUR"

    },

    "paymentMethod": [

    "REFERENCE",

    "CARD",

    "MBWAY"

    ],

    "paymentReference": {

    "initialDatetime": "Current Date",

    "finalDatetime": "Expiration Date",

    "maxAmount": {

    "value": 5,

    "currency": "EUR"

    },

    "minAmount": {

    "value": 5,

    "currency": "EUR"

    },

    "entity": "24000"

    }

    }

    For more info check SIBS API Market

    "customer": {

    "customerInfo": {

    "customerName": "Client Name",

    "customerEmail": "client.name@hostname.pt",

    "shippingAddress": {

    "street1": "Rua 123",

    "street2": "",

    "city": "Lisboa",

    "postcode": "1200-999",

    "country": "PT"

    },

    "billingAddress": {

    "street1": "Rua 123",

    "street2": "",

    "city": "Lisboa",

    "postcode": "1200-999",

    "country": "PT"

    }

    }

    }

    For more info check SIBS API Market

    "recurringTransaction": {

    "validityDate": "2022-09-28T17:37:31.4095147+00:00",

    "amountQualifier": "DEFAULT",

    "description" : "My transaction -> Order XPTO"

    }

    For more info check SIBS API Market

    "tokenisation":{

    "tokenisationRequest":{

    "tokeniseCard":true

    }

    }

    For more info check SIBS API Market


    The response to a successful request is a JSON with an transactionID, which is required in the second step to create a transaction.

    With the transactionID, will be present as well a transactionSignature that will be used on the following step

    POST https://spg.qly.site1.sibs.pt/api/v1/payments

    Request URL:
    /api/v1/payments
    Request Headers:

    Request Body:




    Generate Transaction

    Configuration on Server-To-Server

    Note that all the following requests need an Authorization Header with the "transactionsSignature" returned from checkout operation.

    In this requests, the Bearer Token is replaced by the checkout response "transactionSignature".

    Example:


    Authorization: Digest {transactionSignature}

    Multibanco

    POST https://spg.qly.site1.sibs.pt/api/v1/payments/{transactionID}/service-reference/generate

    Generate Multibanco Reference
    Request URL:

    /api/v1/payments/{transactionID}/service-reference/generate

    Request Headers:

    Authorization: Digest {transactionSignature}

    Request Body:

    {}


    MBWAY
    Generate MBWAY Payment

    Insert the phone number to use:

    POST https://spg.qly.site1.sibs.pt/api/v1/payments/{transactionID}/service-reference/generate

    Request URL:

    /api/v1/payments/{transactionID}/mbway-id/purchase

    Request Headers:

    Authorization: Digest {transactionSignature}

    Request Body:




    Get the payment status

    Once the payment has been processed, the customer is redirected to your redirectUrl (defined in 2.1), you can check the status of your transaction making a GET request.

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

    Request URL:

    /api/v1/payments/{transactionID}/status

    Request Headers:

    Backoffice Operations

    The Backoffice APIs allows merchants to perform different Backoffice operations over their transactions, form example a capture, refund, cancelation and recurring transaction.



    Capture

    A capture is used to request clearing for previously authorized funds.

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

    Captures can happen 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:

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

    Request Headers:

    Request Body:




    Cancelation

    A cancelation is performed against a previous payment authorization (AUTH), by referencing 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, the cancelation 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 not paid, the reference will be cancelled


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

    Request URL:

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

    Request Headers:

    Request Body:




    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:

  • A refund is performed against a previous payment, referencing its transactionID by sending a POST request over HTTPS to the /payments/{transactionID}/refund endpoint.
  • A refund can be performed against purchase (PURS) or captured preauthorization (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, when a subtotal of the total purchase is refunded to the cardholder


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

    Request URL:

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

    Request Headers:

    Request Body:




    Recurring

    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 – Needed to register as initial recurring
  • Following Recurring – Triggers following payments
  • Webhooks

    A webhook is an API that providers with real-time information. SIBS uses webhooks to inform the merchants regarding changes on a Transaction payment status.

    The Merchant can receive the notifications either by email or endpoint (notification assembling to the status inquiry – Checkout Status), however only a notification will be sent for each transaction.

    Notifications are sent by endpoint are straight to the URL configured by the Merchant. The parameterization of this endpoint needs to be done on the SIBS Gateway Backoffice.

    Each time that SIBS Gateway receives an update on the payment status of a transaction a notification will be sent with the new transaction payment status.

    Every day SIBS Gateway send a summarized email with the newest failed notifications (email needs to be registered on the Backoffice).

    There is no guarantee on the order of messages, especially if the time difference between the notifications is smaller than the time it takes to process them or by any communication or systems issues. Once the issues are sort out, new notifications will arrive in real time and old notifications would be resent. In case no notification is received the option “Checkout Status” should be used before rejecting any transaction.

    Notifications are sent as HTTP callbacks (webhooks) to an endpoint on your server. Please ensure you have a valid SSL certificate chain. Self-signed certificates are not valid.

    To receive notifications, you need a server that has:

  • An endpoint that can receive an HTTP POST.
  • An open TCP port for HTTPS traffic (443, 80) with TLSv1.2.
  • Depending on your network and security requirements, you might also need to add our network to your firewall's whitelist.

    To ensure that your server is properly accepting notifications, we require you to acknowledge every notification of any type with an HTTP 200 and a response containing:

    {

    "statusCode": "200",

    "statusMsg": "Success",

    "notificationID": "2533e456-5e36-42c8-9eea-7961902f185e"

    }

    When your server receives a notification it should:

  • Decrypt the notification
  • Store the notification in your database.
  • Acknowledge the notification with an HTTP 200 OK and the following response body: { "statusCode": "200", "statusMsg": "Success","notificationID": "2533e456-5e36-42c8-9eea-7961902f185e" }


  • Decrypt

    The content of notification is encrypted to protect data from fraud attempts. When converting human-readable string to hexadecimal format, we use UTF-8.

  • Encryption algorithm : AES
  • Block mode : GCM
  • Padding : None
  • Initialization vector : In HTTP header (X-Initialization-Vector)
  • Authentication tag : In HTTP header (X-Authentication-Tag)
  • Format of body: Base64 Format of Initialization Vector: Base64

    Secret:

    O0Bur9uhZkS54NkwFhVyeutED6DhLbOQUBDt3i3W/C4=

    X-Authentication-Tag:

    Ytw9bzOS1pXqizAKMGXVQ==

    Content-Type:

    text/plain

    X-Initialization-Vector:

    Ldo3OyWNgRchSF3C

    Body before decryption:

    WgErmJOV6wg3BuRkrgZLUUnh57BYzhIzvBFdpadHRsc43UcjtZEevRGDIDu3YxocXMXe8O+xQpMRxwTJPv766IaNqUiUEjAIj

    ZSMEYCZ0pBursUYB+9nB4eqNUiAS2MJ9sR+Cj2iBf6G6KXLfp9K6dK7c0UED5XrJwbovY8X8pMyxktFTEaflp0e76ZywsCQvt

    qEtqNz9uYEyqmAANbsBwbwyWpkCC8H1kZN2fV3CYetW1CTPmWdPp3C18Yfh826NN4XlKu1VmUmea70PyjmRKSsjPXpfrRX8ud

    elVIK2WTFtnRxD4x588d1nlGY5D5DQmJ8KYZzfvjTmDXGAPiRIEGuXp8h6rBQXS8P/m1llBtboGgQv4MmW3zvq0G6KFlYIcM=

    Body after decryption:

    {

    "returnStatus": {

    "statusMsg": "Success",

    "statusCode": "000"

    },

    "paymentStatus": "Success",

    "paymentMethod": "CARD",

    "transactionID": "WebhookTest",

    "amount": {

    "currency": "EUR",

    "value": 10.0

    },

    "merchant": {

    "terminalId": 1000000

    },

    "paymentType": "PURS",

    "notificationID": "f153c248-e7be-4c12-8d88-6c9f1f3b83e4"

    }




    Examples

    Below there are 4 examples of how to decrypt the webhook notification

    using System;

    using System.Security.Cryptography;

    using System.Text;


    public static class Program {

    public static void Main() {

    byte[] secret = System.Convert.FromBase64String("6fNDiYU0T0/evFpmfycNai/AqF24i+rT0OmuVw0/sGQ=");


    byte[] ciphertext = System.Convert.FromBase64String("9bIjURJIcwoKvQr+ifOTH3HbMX+IqmsRqHuG/I1GfbSX89JE5DcWh/p8QROC5pRAuYZ7"+

    "ln7RSkHXJdZpVz1LFQ2859WsetvHHui7qYmfxATOO1j0AQuPdAD3FeRH0kR4s/v3c2nV8"+

    "1DnUXFCnQER/+VWrYdbu5vn8gm+diSE6CHvkK+ODy0ebVi5O6VBnWVjgBUG33VwWiAyIl"+

    "7Ik435V55WnZgynH3GfbVYoGwZ5UhYtn3yw2yruiLAKu6VTBvnh/ZJP21cHCJSF6NPSd+8"+

    "1gzWFU/+ECm3cf3uBbCkmKmL7HxRhRxhG0lMtX6ELZOXuw3eDJ1BTu+sSMkV/5Xk+5XX48"+

    "XmP6CGZ7KmP7Q3Fw1kZmhn0unFyv0Gw8PjT1Ohny/HMgNl16I=");


    byte[] nonce = System.Convert.FromBase64String("RYjpCMtUmK54T6Lk");


    byte[] tag = System.Convert.FromBase64String("FUajWHmZjP4A5qaa1G0kxw==");


    using (var aes = new AesGcm(secret))


    {

    var plaintextBytes = new byte[ciphertext.Length];

    aes.Decrypt(nonce, ciphertext, tag, plaintextBytes);


    string decrypt = Encoding.UTF8.GetString(plaintextBytes);


    Console.WriteLine(decrypt);


    }

    }


    }

    import java.security.Security;

    import java.util.Base64;


    import javax.crypto.Cipher;

    import javax.crypto.spec.IvParameterSpec;

    import javax.crypto.spec.SecretKeySpec;


    import com.google.common.base.Charsets;


    import org.apache.commons.lang3.ArrayUtils;

    import org.bouncycastle.jce.provider.BouncyCastleProvider;


    // For Java and JVM-based languages, you might need to install unrestricted policy file for JVM,

    // which is provided by Sun. Please refer BouncyCastle FAQ if you get

    // java.lang.SecurityException: Unsupported keysize or algorithm parameters or

    // java.security.InvalidKeyException: Illegal key size.


    // If you cannot install unrestricted policy file for JVM because of some reason, you can try with reflection: See here.


    public class Test {


    public static void main(String[] args) {


    try {

    Security.addProvider(new BouncyCastleProvider());


    // Data from configuration

    String keyFromConfiguration = "6fNDiYU0T0/evFpmfycNai/AqF24i+rT0OmuVw0/sGQ=";


    // Data from server

    String ivFromHttpHeader = "RYjpCMtUmK54T6Lk";

    String authTagFromHttpHeader = "FUajWHmZjP4A5qaa1G0kxw==";

    String httpBody = "9bIjURJIcwoKvQr+ifOTH3HbMX+IqmsRqHuG/I1GfbSX89JE5DcWh/p8QROC5pRAuYZ7"

    +"ln7RSkHXJdZpVz1LFQ2859WsetvHHui7qYmfxATOO1j0AQuPdAD3FeRH0kR4s/v3c2nV8"

    +"1DnUXFCnQER/+VWrYdbu5vn8gm+diSE6CHvkK+ODy0ebVi5O6VBnWVjgBUG33VwWiAyIl"

    +"7Ik435V55WnZgynH3GfbVYoGwZ5UhYtn3yw2yruiLAKu6VTBvnh/ZJP21cHCJSF6NPSd+8"

    +"1gzWFU/+ECm3cf3uBbCkmKmL7HxRhRxhG0lMtX6ELZOXuw3eDJ1BTu+sSMkV/5Xk+5XX48"

    +"XmP6CGZ7KmP7Q3Fw1kZmhn0unFyv0Gw8PjT1Ohny/HMgNl16I=";


    // Convert data to process

    byte[] key = Base64.getDecoder().decode(keyFromConfiguration);

    byte[] iv = Base64.getDecoder().decode(ivFromHttpHeader);

    byte[] authTag = Base64.getDecoder().decode(authTagFromHttpHeader);

    byte[] encryptedText = Base64.getDecoder().decode(httpBody);


    // Unlike other programming language, We have to append auth tag at the end of

    // encrypted text in Java

    byte[] cipherText = ArrayUtils.addAll(encryptedText, authTag);


    // Prepare decryption

    SecretKeySpec keySpec = new SecretKeySpec(key, 0, 32, "AES");

    Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");

    cipher.init(Cipher.DECRYPT_MODE, keySpec, new IvParameterSpec(iv));


    // Decrypt

    byte[] bytes = cipher.doFinal(cipherText);

    System.out.println(new String(bytes, Charsets.UTF_8));


    } catch (Exception e) {

    e.printStackTrace();

    }

    }


    }

    function sodium_decrypt( $webhookSecret, $iv_from_http_header, $http_body , $auth_tag_from_http_header ){

    $key = mb_convert_encoding($webhookSecret, "UTF-8", "BASE64");

    $iv = mb_convert_encoding($iv_from_http_header, "UTF-8", "BASE64");

    $cipher_text = mb_convert_encoding($http_body, "UTF-8", "BASE64") . mb_convert_encoding($auth_tag_from_http_header, "UTF-8", "BASE64");


    $result = sodium_crypto_aead_aes256gcm_decrypt($cipher_text, "", $iv, $key);


    return $result;


    }


    $webhookSecret = "6fNDiYU0T0/evFpmfycNai/AqF24i+rT0OmuVw0/sGQ=";

    $iv_from_http_header = "RYjpCMtUmK54T6Lk";

    $auth_tag_from_http_header = "FUajWHmZjP4A5qaa1G0kxw==";

    $http_body = "9bIjURJIcwoKvQr+ifOTH3HbMX+IqmsRqHuG/I1GfbSX89JE5DcWh/p8QROC5pRAuYZ7" .

    "ln7RSkHXJdZpVz1LFQ2859WsetvHHui7qYmfxATOO1j0AQuPdAD3FeRH0kR4s/v3c2nV8" .

    "1DnUXFCnQER/+VWrYdbu5vn8gm+diSE6CHvkK+ODy0ebVi5O6VBnWVjgBUG33VwWiAyIl" .

    "7Ik435V55WnZgynH3GfbVYoGwZ5UhYtn3yw2yruiLAKu6VTBvnh/ZJP21cHCJSF6NPSd+8" .

    "1gzWFU/+ECm3cf3uBbCkmKmL7HxRhRxhG0lMtX6ELZOXuw3eDJ1BTu+sSMkV/5Xk+5XX48" .

    "XmP6CGZ7KmP7Q3Fw1kZmhn0unFyv0Gw8PjT1Ohny/HMgNl16I=";


    // Decrypt message

    $result = sodium_decrypt($webhookSecret, $iv_from_http_header, $http_body , $auth_tag_from_http_header);


    print($result);

    import base64

    from Cryptodome.Cipher import AES


    def decrypt_AES_GCM(encryptedMsg, authTag, secretKey, iv):

    iv = base64.b64decode(iv)

    encryptedMsg = base64.b64decode(encryptedMsg)

    secretKey = base64.b64decode(secretKey)

    authTag = base64.b64decode(authTag)

    aesCipher = AES.new(secretKey, AES.MODE_GCM, iv)

    plaintext = aesCipher.decrypt_and_verify(encryptedMsg, authTag)

    return plaintext


    example = {

    "encoded" : "9bIjURJIcwoKvQr+ifOTH3HbMX+IqmsRqHuG/I1GfbSX89JE5DcWh/p8QROC5pRAuYZ7" \

    "ln7RSkHXJdZpVz1LFQ2859WsetvHHui7qYmfxATOO1j0AQuPdAD3FeRH0kR4s/v3c2nV8" \

    "1DnUXFCnQER/+VWrYdbu5vn8gm+diSE6CHvkK+ODy0ebVi5O6VBnWVjgBUG33VwWiAyIl" \

    "7Ik435V55WnZgynH3GfbVYoGwZ5UhYtn3yw2yruiLAKu6VTBvnh/ZJP21cHCJSF6NPSd+8" \

    "1gzWFU/+ECm3cf3uBbCkmKmL7HxRhRxhG0lMtX6ELZOXuw3eDJ1BTu+sSMkV/5Xk+5XX48"

    "XmP6CGZ7KmP7Q3Fw1kZmhn0unFyv0Gw8PjT1Ohny/HMgNl16I=",

    "iv" : "RYjpCMtUmK54T6Lk",

    "tag" : "FUajWHmZjP4A5qaa1G0kxw==",

    "secret" : "6fNDiYU0T0/evFpmfycNai/AqF24i+rT0OmuVw0/sGQ="

    }


    result = decrypt_AES_GCM(example['encoded'], example['tag'], example['secret'], example['iv'])

    print(result)

    API Reference

    For more info check SIBS API Market

    Credentials


    How to get your credentials ?


    Below you will be able to configure which credentials you will use on the Examples above.

    You can use the default one or change them to your Test Credentials, provided by onboarding@sibs.pt


    TerminalId

    Provided by Onboarding on your credential kit

    X-IBM-Client-Id

    Provided by Onboarding on your credential kit

    Bearer / Access Token

    Provided by Onboarding on your credential kit

    Payment type

    For one time transactions - AUTH

    For two time transactions - PURS

    Payment Entity

    Provided by Onboarding on your credential kit

    Payment Method

    Selected when you sign the contract with the Bank

    TerminalId

    Obtained on SIBS BackOffice, or provided by your bank

    X-IBM-Client-Id

    Obtained on SIBS BackOffice, or provided Onboarding

    Bearer / Access Token

    Obtained on SIBS BackOffice

    Payment type

    For one time transactions - AUTH

    For two time transactions - PURS

    Payment Entity

    Obtained on SIBS BackOffice, or provided by your bank

    Payment Method

    Selected when you sign the contract with the Bank