Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

This section describes the minimum set of items that should be checked before going live in case of custom integration.

Minimum set of endpoints

The list of endpoints to be used in redirect flow integration type and their proper usage is described below.

Endpoint

Mandatory?

Purpose

Actions

Doc

Get Access Token

Mandatory

Endpoint to get access token which is required to call Everifin Paygate API.

As the token has very short validity, you need to make sure you have valid one before calling any API endpoint.

It is up to merchant to choose the way of getting it:

  • active approach - based on its lifetime, before it expires

  • or passive approach - get new one once 401 error response is obtained

https://everifin.atlassian.net/wiki/spaces/EPAD/pages/2467561515/Authentication#Get-authentication-token

Create Order Payment

Mandatory

Endpoint to initiate payment and get payment link

Beside all mandatory fields, populate these fields:

  • reference/variableSymbol - these are important to identify the payment and also to map it to particular money transfer on merchant’s bank account statement. In Slovakia and Czechia also the fields specific and constant symbol can be used.

  • paymentMessage - it is good practice to use appropriate message so your customers can easily identify the payments in their bank even after some time (e.g. text containing eshop name)

  • recipientName - name of the eshop/merchant. This is also important for the customers to identify the money transfer in their bank

  • userLocale - please send proper value in this field to display the paygate page in correct language to your customers.

The response provides payment ID which needs to be stored to the purchase order in merchant’s system and also redirect URL the customer should be redirected to.

https://everifin.atlassian.net/wiki/spaces/EPAD/pages/2562228372/Payment+Orders#Order-initialization

Get Order Payment Detail

Mandatory

Endpoint to get payment detail after redirect back to merchant (and/or after reasonable time when no redirect happens)

This endpoint needs to be called after the payer is redirected back to merchant’s page/app (thank you page or failure page in case of cancel) to get current status of the payment (merchant receives payment ID in the query parameter when redirect URL is called).

The order needs to be find based on the payment ID provided in the redirect (merchant need to ensure the order related to this particular payment is being processed based on the payment result).

This endpoint can be called also in some reasonable time period after the payment has been initiated in the case the payer does not come back to merchant’s site/app (e.g. when the payer closes the browser before she/he is redirected back to merchant).

Response of this endpoint can be used to double check the data against the data in initial order (amount, reference etc.)

https://everifin.atlassian.net/wiki/spaces/EPAD/pages/2562228372/Payment+Orders#Order-detail

Ordinary process flow

Standard process consists of the following steps.

  1. Getting or refreshing existing API access token

  2. Calling Create Order Endpoint (providing payment data, redirect URL). Storing received Payment ID and redirecting customer to received redirect URL for payment authorization.

  3. The customer authorizes the payment via her/his bank and finally is redirected back to merchant’s redirect URL. During the payment authorization process, merchant’s webhooks are being called (merchant is getting payment status updates).

  4. Once redirected back to merchant’s web site (or application), the merchant’s payment entity status is checked in the background (it can be in successful status already - updated via webhooks). If payment is not in the final status yet (via webhooks), the endpoint to get payment detail should be called (certain polling interval should be set up as backup for webhooks).

  5. Customer is presented with web page informing about payment success and further information about order processing.

Edge cases handling

Situation

Handling

After redirect back to merchant, the payment is still in PROCESSING status.

In some rare cases it may happen the payment is not in final status at the moment of redirection back to merchant but still in PROCESSING status (i.e. the bank has not processed the payment yet).

Merchant should inform the customer the payment is still being processed and that the customer will be notified once the payment is processed successfully (via email, in the customer’s e-shop account etc.). The merchant needs to implement background process of payment status checking (webhooks or polling payment detail endpoint in some intervals as backup).

Customer interrupts the payment process and does not return to merchant’s e-shop page.

These situations can be handled by webhooks functionality. As a backup solution, process of polling the payment detail endpoint by the client in some interval should be implemented by the merchant.

Webhooks integration - Highly recommended

We highly recommend to implement webhooks functionality. It has multiple advantages:

  • Your system gets information about payment status update instantly at the time the change happens

  • Your system gets information about payment status changes even in case the payer left the payment process flow

The details of the webhooks that can be integrated are here: Webhooks

  • No labels