Documentation version 3.03, 12.08.2024

Here at Inbank we strive to help our partners sell more by simplifying purchases and making financing more accessible to customers. For exactly this reason we offer a number of sales financing solutions. Our most known credit offering is hire-purchase, also known as payment by installments.

There are several methods of how partners can integrate with Inbank, this document covers our e-POS solution. With Inbank e-POS, partners only need to add Inbank as a payment method and redirect clients to our environment, Inbank will take care of all the rest. After a successful financing process we will redirect the customer back to you.

Inbank e-POS is supplemented with Inbank Partner Portal where merchants can see detailed overview of submitted credit applications, create applications for customers and conduct contract withdrawals.

If you would like to make a partial return for a Hire Purchase or a Split into parts contract, please refer to the Partial Returns Guide.

For any questions regarding the e-POS integration process, contact Inbank at:

• Estonia: integration@inbank.ee
• Latvia: integration@inbank.lv
• Poland: integration@inbank.pl
• Czechia: integration@inbank.cz
• Lithuania: integration@inbank.lt

We will be happy to help.

In general, the flow looks like this:

Inbank also sends server-to-server notification messages to ensure delivery of information about the payment session even if the customer does not return to the e-shop.

Inbank will provide you with everything you need to start using our Partner API. This includes the necessary keys, product configuration, etc. For any questions regarding the integration process, contact Inbank at:

• Estonia: integration@inbank.ee
• Latvia: integration@inbank.lv
• Poland: integration@inbank.pl
• Czechia: integration@inbank.cz

Inbank provides a separate environment for development and integration testing. The demo environment remains available during the later life cycle of our cooperation, after the integration on production environment has been launched. The demo and production environments are different, each having individual data sets.

Note that the access credentials and product codes are different in the production environment. You will be provided production specific information later on.

For testing purposes, the demo environment returns preconfigured decisions:

• For Inbank Hire Purchase and Split into parts payment products, positive decision is given for amounts 0 - 500, 15 000 - 16 000.
• For the Pay next month payment product, a positive decision is given for amounts 0 - 100, 150 - ...

The credit application process may include an OTP code exchange via SMS. The demo environments do not send out SMS messages. If you are testing Pay next month or Split into parts payment products, the SMS message is hardcoded to value 0000.

Before you can initiate a session, Partner API connectivity must be configured.

Inbank will provide you an API key, used for authentication, and a unique identifier of your shop, required for building API URLs (for example POST /shops/YOUR_SHOP_UUID/pos_sessions). The keys should remain private at all times.

The authentication process consists of the following two steps:

1. Merchant places the API key in the Authorization header of the request.
2. API server verifies the API key authenticity.

Authorization header must have the Bearer scheme and value of your API key, for example:

Authorization: Bearer e93174d3b9158a01c861c65fab0e7f96

In case of unsuccessful authorization, the system will return the following response:

{
    "error": [
        "unauthorized"
    ]
}

The HTTP header Content-Type application/json is expected in all requests, unless otherwise specified in the endpoint description. Example:

Content-Type: application/json

Estonia:

Latvia:

Poland:

Czechia:

Lithuania:

For the easiest integration we have designed the session status model to be similar to other payment channels that the e-shop integrates with.

The integration flow can be configured to require a final merchant-side confirmation step, before the credit application process is completed. This is somewhat similar to the credit card flows where the amount is first reserved on the credit card account (transaction is approved), and is later 'captured' after the merchant has completed the transaction.

This may be handy if the stock is limited and the merchant does not allocate stock items before it is ensured that the customer can get the credit. If the merchant does not send the final approval (i.e. items are out of stock, order can not be completed), the granted credit is not completed.

Inbank will send callbacks about changes to the credit contract status. Contracts can have the following statuses:

When initiating the payment session in Inbank Partner API the e-shop should provide 3 URLs:

• redirect URL - the URL to which the customer's browser will be redirected back after the customer has completed the credit application dialog. Regardless of the outcome of the credit application process, the customer is redirected here, even if the credit is not granted.
• cancel URL - the URL to which the customer's browser is redirected if the customer deliberately chooses to cancel the credit application dialog.
• callback URL - the URL to which Inbank will send server-to-server callback notifications on session status change events.

Inbank sends callbacks about the following state transition events:

• Credit application is cancelled
• Credit application is denied
• Contract is cancelled
• Contract is granted (applicable if the flow requires merchant approval of credit contracts)
• Contract is activated (state indicating that the financing of the purchase has been completed)

If you are integrating with Inbank's Pay next month payment product, there can be cases when a customer already has an active credit contract and the new purchase is added to it. In this case, the following callbacks will be sent:

• Purchase is rejected (credit for the purchase has been declined by Inbank, the payment session status becomes Declined)
• Purchase is cancelled (the customer has cancelled the financing process, the payment session status becomes Cancelled)
• Purchase is activated (financing for the purchase has been successfully provided, the payment session status becomes Completed)

Once the financing process is finalized, Inbank will send two callbacks, both with the same structure and content:

• First one is performed on redirect_url, via the customer's browser.
• Second one is server-to-server callback which ensures that the merchant receives the callback. It is done on callback_url.

Note that the first callback may not arrive if the customer does not press the "back to merchant" button, or if there are connectivity or technical problems at the customer's device/browser. Thus there is no guarantee that the first callback will arrive, or which one of the two callbacks will arrive first. Callback requests are lightweight triggers for initiating activities on the merchant side. They contain only minimal information.

To avoid processing accidental or malicious traffic to callback endpoints, the handlers should first verify the authenticity of the request. For more details, see the Callback authenticity validation chapter.

E-shop should process the incoming messages, at a minimum, in the following way:

• Validate the authenticity of the request, to avoid further processing of invalid traffic.
• Look up the pos_session identifier either from the incoming message, or from the internal database as it was persisted when the session was initiated.
• Inspect pos_session status and process the order payment status based on the pos_session state. If needed, you can also check the purchase reference.
• Redirect the user to the respective dialog, i.e. the "payment complete" page.

Both of the callbacks are sent as http POST requests, ("Content-Type" => "application/x-www-form-urlencoded"). The POST form has the following structure:

Request header

{"Content-Type":"application/x-www-form-urlencoded"}

Request body

message=%7B%22uuid%22%3A%223241a6d5-051b-415b-afc7-0a5aad115fcc%22%2C%22status%22%3A%22cancelled%22%2C%22
purchase_reference%22%3A%221234%22%7D&hmac=4c4686db2aac832dd2e001fdc02e2b4021dc5e49c064552215dab2ca9c564
9435562bc60e96b812ca8ea40223f500ced9c257541b43ab7fb482067c8bae7a963&timestamp=1553072069

The message contains minimal information, it is meant as a trigger to obtaining more detailed information over Partner API.

• uuid - POS session UUID.
• status - status of the POS session at the moment of message dispatch. For more details, see the State model chapter.
• purchase_reference - merchant side reference, i.e. order ID. For more details, see the Session initiation chapter.

We use message authenticity hash (HMAC) transported within the POST request form field hmac. To validate the message authenticity you need to calculate the verifying HMAC based on data from the request and your secret api_key, and compare the calculated HMAC with the HMAC value passed in the request.

Verifying HMAC is calculated as SHA512 HMAC, over the timestamp and message from the request, concatenated with . delimiter. Your shop API key is used as HMAC secret.

Pseudocode for example verifying HMAC calculation:

key = your_api_key;
req_timestamp = request[timestamp];
req_message = request[message];
req_data = req_timestamp+'.'+req_message;
v_hmac = hmac("sha512", key, req_data);

JavaScript example (Postman):

key = your_api_key;
req_timestamp = decodeURIComponent(request[timestamp]);
req_message = request[message];
req_data = req_timestamp + '.' + req_message;
v_hmac = CryptoJS.HmacSHA512(req_data, key);

PHP example:

$key = $settings->api_key;
$req_timestamp = $_POST['timestamp'];
$req_message = stripslashes($_POST['message']);
$v_hmac = hash_hmac('sha512', $req_timestamp . '.' . $req_message, $key);

This section lists the API request required for the integration with the Inbank e-POS system. The following pages contain charts with demonstration of the request sequence. The enlisted API requests are used in the following way:

1. The shop retrieves a primary credit calculation using the POST /calculations request. The response includes an approximate monthly payment based on the credit amount and period. The final conditions will be presented in e-POS after the customer submits an application.
   
   

   Please note: Inbank payment methods should be available only for cart values that are within the price range agreed with Inbank. If you would like to receive the price range and other details of your Inbank product over API, please use the GET /products endpoint.

   
   

2. The e-shop initiates a payment session using the POST /pos_sessions endpoint. The request includes merchant domain name as one of the parameters. The redirect_url from the response indicates the link to which the client is redirected to complete the financing process.
   
   

3. The e-shop redirects the client to the e-POS environment. In e-POS customers are guided through a number of dialogs to complete the financing of the purchase. After the e-POS dialogs, customers are redirected back to the e-shop. The return_url is the one the e-shop included in the POST /pos_sessions request.
   
   

4. If the flow is configured to request merchant approval before contract activation, the e-shop waits for the callback indicating that the payment session received the status granted. At this point, the e-shop retrieves the identifier of the contract using the GET /pos_sessions request. After that, the merchant can either approve the credit contract, using POST /:contract_uuid/merchant_approval request, or cancel it, using the POST /:contract_uuid/cancel. The following step is necessary only if the contract was approved.
   
   

5. Once the e-shop receives the callback indicating that the payment session received the status completed, the e-shop needs to check the contract status. First, the e-shop retrieves the identifier of the contract using the GET /pos_sessions request. Retrieving the contract identifier again is not required if it was previously done to approve the contract. Then the e-shop checks the status of the credit contract using the GET /contracts request. If the contract received status activated, the financing of the purchase has been successful. Note that this step should not be performed if you are integrating with the Pay next month payment product.

If you would like to make a partial return for a Hire Purchase or a Split into parts contract, please refer to the Partial Returns Guide.

The chart demonstrates the sequence in which the API requests should be applied to successfully initiate the payment session, redirect the customer to e-POS and later check the credit contract status to confirm that the financing has been successful.

Please note that if you are integrating with the Pay next month payment product, you do not need to perform steps 3 and 4.

The chart below applies to cases when the flow requires merchant approval prior to contract activation. The chart demonstrates the sequence in which the API requests should be applied to successfully initiate the payment session, redirect the customer to e-POS and later check the credit contract status to confirm that the financing has been successful.

Please note that if you are integrating with the Pay next month payment product, you do not need to perform step 5.