The payment flow can be described by the picture below.
Steps
The payment flow has these steps:
Common step Authentication - first your system needs to be authenticated to Everifin Paygate. See Authentication
API v1
Payment initialization - payment is initiated via API and user is redirected to Everifin Paygate to process the payment. See Redirect Flow (v1)
Get payment(s) - you can get payment data for single payment or payment list. This can be used to check payment status in case you do not use hooks. See https://everifin.atlassian.net/wiki/spaces/EPAD/pages/2467561608/Payment+Resources#Get-payments
API v2
Order initialization - redirect URL and payment ID are present in the response
Order processing - Redirecting to URL obtained in step 1. Details can be found here: Redirect Flow
Checking status
Either by getting the order detail (Get Order endpoint) - it provides detail of the order together of details of all its payments
Or by getting the detail of the specific payment in the order (Get Order Payment endpoint)
Payment statuses
During the payment process the payment changes its status. The status defines not only state of the payment, but also possible operations - payments in some statuses cannot be updated or cancelled.
Status | Final | Withdrawable | Description |
|---|---|---|---|
CREATED | no | yes | Payment is created and waiting for the user. |
SEEN | no | yes | User opens the Everifin Paygate web page or processing via Process Order endpoint is started. |
PROCESSING | no | no | The payment is being processed (user is authorizing payment on bank`s page or authorization is done and payment is being processed in the bank). |
CONFIRMED | yes | no | The payment has been successfully authorized in the bank by the payer. |
BOOKED | yes | no | The payment has been booked (settled) in the bank. |
WITHDRAWN | yes | no | The payment has been withdrawn by merchant. |
FAILED | yes | no | Payment has failed. Field |
EXPIRED | yes | no | Payments that stay in CREATED or SEEN for a long time are eventually moved to this state. |
PROCESSING_EXPIRED | yes | no | The payment is being processed, but we are unable to retrieve its status from the bank, because access granted by the payer has expired. |
Following diagram ilustrates possible transitions between payment states:
Payment status flow chart
Payment Failure reason codes
Reason code | Description |
|---|---|
CANCELED_BY_PAYER_AT_EVERIFIN | Payer rejected the payment on Everifin Paygate page before authorization has been initiated. |
BANK_NOT_FOUND | Payer has not found the desired bank and wants to choose different payment method at the merchant's site. |
MANUAL_TRANSFER_REQUESTED | Payer has not found the desired bank and decided to receive payment details for the manual bank transfer via email (generating and sending the email to customer need to be handled by merchant). This feature is turned off by default. |
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.) |
Order statuses
Status | Withdrawable | Description |
|---|---|---|
UNPAID | yes | Payment of the order is not paid yet. The order is withdrawable in this status in case the related payment is in one of statuses CREATED and SEEN. |
PARTIALLY_PAID | no | Payment of the order is paid but order amount is higher than the paid payment amount (this can happen by updating the order with higher amount what creates another payment in the order which is to be paid). |
PAID | no | The order is fully paid. |
API v1 vs. v2
Main differences between API v1 and v2 are:
API v2 introduced concept of orders and refunds, which are not supported in API v1
API v1 is considered deprecated and can be removed in the future.
Edge cases
This section describes rare edge cases that can appear during payment processing.
AML checks
As part of the payment processing the banks do the AML checks. If the transaction does not pass the AML checks successfully (e.g. the payment is identified by the bank’s rules as suspicious, the payer is on some AML lists etc.), the bank blocks the funds and the payment ends up in FAILED state (reason code: AML_BLOCKED). The payer needs to contact his bank in such situation.
Non-compliant banks
Even though the situation is still improving, some banks, however, do not comply with the PSD2 regulation in all details.
We are working very proactively with the regulators and the bank’s support teams in order to achieve better quality PSD2 APIs.