Versions Compared

Version Old Version 2 New Version 3
Changes made by

Michal Gregor

Michal Gregor

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

After the payment is initiated it can be processed using the endpoint described belowon this page.

The processing works like a state machine, i.e your system needs to react based on content of the response (status and step fields). The order of steps in the flow is bank-specific.

...

Request to Process Order Payment endpoint must contain following headers:

Header

Type

Optional

Description

Authorization

Bearer token

no

Authorization token to access API.

x-ef-sender-ip

IP address

no

IP address of your user.

x-ef-sender-user-agent

text

no

Your user`s user agent identification. A valid user agent must be provided, i.e. containing operation system info etc.

x-user-data-encryption-method

text

yes

Method of sensitive data encryption. Send this header, if you are encrypting e.g. user’s credentials.

Currently, only supported method is RSAES-OAEP/SHA-256.

Body

The set of required inputs (data that needs to be provided in body of this request) depends on the bank of the payment sender. Client of this API must react to requested inputs that are specified in the responses of this endpoint.

...

The data must be encrypted by client. At the moment, we also accept un-encrypted data during the transition period. For more instructions on how to encrypt data, see further.

Response

Field

Type

Optional

Response type

Description

id

number, unique

no

All

Payment id, which will be used for the next communication

status

enum

no

All

Status of the payment. Possible statuses are described below in separate table.

type

enum

yes

All

Processing flow step type (given by specific bank):

  • REDIRECT - you should redirect to redirectUrl

  • INPUT - some user input is required

  • NEXT - if status is

FINISHED

  • CONFIRMED/BOOKED or FAILED, processing is done and there is nothing else to do. Otherwise you should call process endpoint.

  • PUSH - waiting for the confirmation of PUSH notification (no action required but status needs to be checked after some time by calling this endpoint). Payer needs to handle the push notification in the mobile device

REQUEST_INPUT - you should call processing endpoint without any body

  • .

The response will have INPUT type.

redirectUrl

text

yes

REDIRECT

The URL for redirect (only for REDIRECT response types)

inputSet

InputObject[]

yes

INPUT

Array of input objects required for next processing. Values from this set has to be displayed to the user, so she/he can enter or select required values.

input

InputObject

yes

INPUT

Input object required for next processing. Input has to be displayed to the user, so she/he can enter or select required value. Response might contain this field, if only one input is requested. If multiple inputs are requested

, response

, response contains inputSet field.

inputsToEncrypt

string[]

yes

INPUT

List of inputs to encrypt, if sensitive user’s data are required in input or inputSet. These inputs must be encrypted in the request body.

inputEncryptionConfig

InputEncryptionConfig

yes

INPUT

If response contains inputsToEncrypt, this field specifies encryption method and encryption key.

Input Object

type

enum

no

INPUT

Type of the input:

  • TEXT - user has to enter some text, e.g. username, sms code etc.

  • PASSWORD - user has to input his bank password

  • BOOLEAN - user has to give consent to some action

  • SELECT - user has to select an option

  • IMAGE_SCAN - user has to scan some image into his mobile app, e.g. QR

  • IBAN - user has to enter his IBAN

Based on this field you can set the UI for the user like html input types and validation.

name

text

no

INPUT

Name of the input

identifies it on your side

to identify it by Everifin system. This name

is

must be returned back together with the value the user has provided.

selectOptions

SelectObject[]

yes

INPUT

Only for SELECT input type. User has to select one of offered options.

image

 

yes

INPUT

Only for IMAGE_SCAN input type. User has to scan the image into his mobile banking app.

Select Object

name

text

no

INPUT

Name of the select option.

value

text

no

INPUT

Value of the select option.

InputEncryptionConfig

encryptionKey

string

no

INPUT

Public key for data encryption.

encryptionMethod

string

no

INPUT

Method of data encryption. Currently, only supported value is RSAES-OAEP/SHA-256.

Payment statuses

During the payment process the payment changes its status. These are the possible status values.

Status

Final

Description

CREATED

no

Payment is created and waiting for further processing.

SEEN

no

This status is assigned once the process payment endpoint is called for the first time.

PROCESSING

no

The payment is being processed (user is authorizing payment on bank`s page or authorization is finished and payment is being further processed by the bank).

CONFIRMED

yes

The payment has been successfully authorized in the bank by the payer.

BOOKED

yes

The payment has been booked (settled) in the sending bank.

FAILED

yes

Payment has failed.

Field reasonCode will provide more information about the failure. Possible values are described below in separate table.

Payment Failure reason codes

Reason code

Description

CANCELED_BY_PAYER_AT_BANK

Payer canceled the payment on the bank’s page.

INSUFFICIENT_AMOUNT

Payer does not have enough funds on his account to make the payment.

AML_BLOCKED

Payer’s funds have been blocked at the bank as a result of bank’s AML checks. Payer needs to contact the bank to treat the situation further.

REJECTED_BY_BANK

The bank rejected the payment due to some failure. Issue needs to be further analyzed (sometimes the reason is the payer canceled the payment on the bank’s pages but we are not able to identify this situation because the bank does not inform about it).

OTHER

Other, unspecified failure reasons (e.g. payment authorization failed, bank API temporary outage etc.)