There are three basic types of payments supported by Everifin Paygate service:
One-time payments - for every payment the user must select a bank, log-in, select a bank account and authorize the payment.
Payments from returning customers who connect their bank accounts with limited permissions only to perform payments at merchants vetted and trusted by Everifin
Payments from Everifin accounts - the user is already using another Everifin service (Multibanking or Wallet) and has already at least one bank account connected there. These bank accounts are not limited for a specific payment use-case and therefore can be re-used in Everifin Paygate with user’s consent.
Integration scenarios
In all cases above the integration can be done using Everifin UI (recommended) or Everifin API. The following table shows which combinations are allowed for which service:
One-time payment | Returning customers who connect bank accounts limited to payments | Everifin customers (existing Everifin users with already connected bank accounts) | |
|---|---|---|---|
User registration/login | not applicable | not applicable, the merchant is logged-in via API | Everifin UI (Multibanking or Wallet) * |
Connecting bank accounts | not applicable | Everifin UI (Paygate Redirect flow) | Everifin UI (Multibanking or Wallet) * |
Payment initiation | Everifin UI (Paygate Redirect flow) / Everifin API (Paygate Embedded flow) | Everifin UI (Paygate Redirect flow) | Everifin UI (Paygate Redirect flow) / Everifin API (Paygate Embedded flow) |
* - this step is done outside Paygate as a pre-requisite
Everifin UI
The UI can be customized to match the look & feel of the client application.
Everifin UI is the simplest method of integration. It takes the user to a trusted and licensed payment services provider Everifin (e.g. using a redirect or a modal window). The user can safely authorize the payment and return back without sharing any sensitive data with the original client application (an accounting system, an ERP, an e-shop, etc).
Everifin API
Everifin API is a more complex integration method which requires the client application to take care about the specifics of the payment authorization process itself. E.g. it must store the list of connected bank accounts, monitor the status of each connection, handle different types of payment authorization processes supported by the banks (redirect to a bank, embedded in the application and decoupled) each with multiple types of authorization factors (push notification, SMS, one-time code, QR code scan, etc).