...
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:
| ||||||
Get Banks | Optional | Endpoint to get list of banks. | List of available/supported banks can be displayed to customer so he can decide before he chooses the payment method. | ||||||
Create Order Payment | Mandatory | Endpoint to initiate payment and get payment link | Beside all mandatory fields, populate these fields:
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 | Order Withdrawal | Optional | Endpoint to withdraw the initiated payment by the merchant | In case the merchant needs to withdraw the payment that has been already initiated (endpoint Create Order Payment called successfully), this endpoint can be called. It is possible to withdraw the payment only in case the payment authorization has not start yet. The details when the withdrawal is possible is described in the doc |
Ordinary process flow
Standard process consists of the following steps.
Getting new API access token
Calling Create Order Endpoint (providing payment data, redirect URL). Storing received Payment ID (and Order ID as it is needed later to get payment detail) and redirecting customer to received redirect URL for payment authorization.
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).
Once redirected back to merchant’s web site (or application), the merchant should proceed with the following actions:
Only if Webhooks are implemented - Merchant should check the status of his entity (it might have been updated via webhook, type payment.statusChange, and already in final status - success or failure).
If payment is not in the final status yet (via webhooks), the endpoint to get payment detail https://everifin.atlassian.net/wiki/spaces/EPAD/pages/2562228372/Payment+Orders#Order%E2%80%99s-payment-detail should be called (certain polling interval should be set up as backup for webhooks).
Customer is presented with web page informing about payment success and further information about order processing.
in case of failed payment, customer should be presented with page where he can restart checkout procedure (i.e. kept goods/services in the shopping cart and possibility to choose again from payment methods).
Recommended reactions to payment statuses
Please follow the recommendations described here: https://everifin.atlassian.net/wiki/spaces/EPAD/pages/
...
...
Flow#Recommended-reactions-to-payment-statuses
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 (polling payment detail endpoint in some intervals, or, once available, use web hooks). The possible reactions are described here: https://everifin.atlassian.net/wiki/spaces/EPAD/pages/2467561491/Paygate+Payment+Flow#Recommended-reactions-to-payment-statuses |
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:
...