Manage Payments


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



Capture

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

A capture request is performed using a previous preauthorisation (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 Headers:

    Request Body example:

    To read more and try out all the capture flow use the Card authorisation and capture page.



    Cancellation

    A cancellation is performed against a previous payment authorisation (AUTH), by referencing its transactionID and sending a POST request over HTTPS to the /payments/{transactionID}/cancellation endpoint.

    When canceling a payment and if sent within the time-frame the authorisation is not captured yet, the cancellation causes an authorisation reversal request to be sent to the card issuer to clear the funds held against the authorisation.

    It can be a Full cancellation when the total amount of the authorisation is cancelled by the merchant , or a Partial, when a subtotal of the total authorisation is cancelled by the merchant


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


    Request Headers:

    Request Body example:


    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 preauthorisation (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 Headers:

    Request Body example:


    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

  • SPG Payment Form

    Available Payment Methods?

    Card

    The gateway offers integration with major international card processing schemes such as Visa and Mastercard.

    Pay by Link

    Pay by link is a reliable, convenient and secure way to get paid by consumers and businesses alike. Merchants handling telephone transactions can benefit from this solution, while this payment channel opens up a whole host of opportunities for businesses of all sizes, across sectors. It allows customers to make payments by sending them a web payment link, meaning card details do not have to be shared over the phone or text message.

    BLIK

    BLIK is the most popular mobile payment system in Poland that allows users to make instant payments using only the user's standard mobile banking app. BLIK payments are convenient and safe – you enter the BLIK code and confirm the transaction with your PIN in the banking app. You do not have to log in to online banking, enter SMS passwords or provide your payment card details.

    Credentials


    How to get your credentials ?


    Below you can find instructions on how to get your credentials.


    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 single message transactions - PURS

    For two-message transactions - AUTH

    Payment Method

    Selected when you sign the contract with your Acquiring entity

    TerminalId

    Obtained on SIBS BackOffice, or provided by Onboarding team

    X-IBM-Client-Id

    Obtained on SIBS BackOffice, or provided by Onboarding team

    Bearer / Access Token

    Obtained on SIBS BackOffice

    Payment type

    For single message transactions - PURS

    For two-message transactions - AUTH

    Payment Method

    Selected when you sign the contract with your Acquiring entity