Introduction
BLIK Recurring payments are the automatic collection of a payment from customers who have agreed to it. There are two key events in BLIK recurring payment method process:
Recurring Payment which is the User's expressed consent to initiate Recurring Transactions by the Merchant. Such consent is initiated by the User in merchants's website/app and confirmed in banking app. User can also see and cancel all Recurring Payments in the banking app.
Example:
Starting new subscription in a music streaming service.
Recurring Transaction is a single Transaction initiated by the Merchant based on a Recurring Payment made by the User.
Example
Automatic monthly fee collection for a music streaming service.
Recurring Payments are available in three implementation models:
|
|
Model A |
Model M |
Model O |
|
User Confirmation of Recurring Transaction in Banking App |
No Confirmation |
Confirmation Required |
No Confirmation |
|
Amount |
Fixed |
Variable |
Variable |
|
Frequency |
Fixed |
Variable |
Variable |
|
Expiration |
Until Fixed Expiration Date |
Idefinite or until fixed Expiration date |
Idefinite or until fixed Expiration date |
Model A
In this model, after creating Recurring Payment, Recurring Transactions initialized by merchant are authorized by the Bank automatically (without confirmation by the User in the banking app), for a fixed amount, at a fixed frequency, until the set expiration date.
Example market areas:
Streaming services
Games
SaaS
Product subscriptions (cosmetics, fresh vegetables, animal food)
Other subscription businesses with flat fee
Info
Read more about this implementation in the document Model A
Model M
In this model after creating Recurring Payment, User's confirmation is required every time to complete every Repeat Transaction. Transactions may have variable amounts and different frequency. The validity of a Recurring Payment A Recurring Payment may be specifically dated or marked as indefinite/until cancellation.
Example market areas:
Household Bills: Recurring Payments with Variable amount enable paying for bills which are based on the usage
SaaS: Payments for online services based on the usage like cloud or games
Delivery services: Leveraging the ability to adapt to variable payment amounts, M Model streamline the process of making substitutions prior to delivery, particularly advantageous for grocery and meal delivery transactions.
Info
Read more about this implementation in the document Model M
Model O
In this model, after creating Recurring Payment, Repeat Transactions initialized by merchant are authorized by the Bank automatically (without confirmation by the User in the banking app) Repeat Transactions may have variable amounts and different frequency. The validity of a Recurring Payment may be specifically dated or marked as indefinite/until cancellation.
Example market areas:
Like Model M but the absence of user confirmation is crucial for the efficacy of your business model.
Mobility apps - electric scooters taxi
Subscriptions with variable amounts requiring seamless flow
Info
Read more about this implementation in the document Model O
Frequency
Frequency settings vary depending on the model used. This results in differences in information provided by merchant during Recurring Payment set-up.
|
|
Model A |
Model M |
Model O |
|
Frequency |
Required to specify |
Optional to specify (information purpose only) |
N/A |
|
Date of 1st Recurring Transaction |
Required to specify |
N/A |
Optional to specify (information purpose only) |
Refer to the specific model's page for more detailed information.
Supporting Banks Management
Given that the BLIK Recurring Payments payment method may not be accessible in all banks within the market at given time, merchants are obligated to ensure a proper user experience by informing users about its availability in specific banks. Additionally, adequate error management should be implemented in cases where users attempt to establish BLIK Recurring Payments through banks that do not support this feature. It is important to note that over time, more banks are expected to support this feature, enhancing accessibility for users across various banking institutions.
Merchants should verify with their acquirers which banks currently supports BLIK Requrring Payments
refusePAYID mechanism
To provide a possibility for Merchants to execute a Transaction only when it comes from supporting Bank, a refuseNoPayid mechanism was introduced. Sending this flag set on "true" (refuseNoPayid=true) causes BLIK system to reject the Transaction upon determining that the identified Bank (designated based on the BLIK code provided as the authorization tool) does not support Recurring Payments.
Through this feature, merchants can receive the appropriate error code and manage it effectively with suitable information, providing list of supporting banks and the option to retry with another (supporting) bank or alternative payment method.
Merchants should contact their Acquirers if they wish to use the refusePAYID mechanism. All Acquirers are required to support this feature.
If the refuseNoPayid flag is not sent with Transaction, and the identified Bank has not Recurring Payment support, then:
in case the Transaction to which the invitation was attached is for an amount higher than 0, only the Transaction to which the invitation was attached is presented to the User for confirmation in AM, and the invitation is not presented.
in case the Transaction to which the invitation was attached is for the amount of 0, the request to reprocess the Transaction is rejected by BLIK's system with the error code ER_PAYID_UNHANDLED and is not forwarded to the Bank.
Unsuccessful Recurring Transactions
There is a possibilty that due to infufficient funds or exceeded limits Recurring Transaction won't be authorized in a designated moment.
In that case, within the next 72 hours bank will inform user about cause of the problem asking for changing limits or securing necessary funds. Then Bank will attempt to reauthorize transaction. If there are still insufficient funds or exceeded limits during that time, will send a denial authorization response
Nodelay Flag
There is an option to skip the 72-hour period during which bank attempts to inform the user about the reason for the lack of authorization for the recurring transaction and tries to obtain authorization. This can be achieved by setting the NODELAY flag to "true" and using it with a Recurring Transaction. NODELAY flag is available in case of Model A and O only. In such a situation, if there are insufficient funds or exceeded limits, the transaction will be marked as unsuccessful immediately.
In a situation where NODELAY flag is used and transaction is immediately marked as unsuccessful, merchant can manually retry transaction at a chosen time. In such a case, it is important to maintain an appropriate interval between attempts. The recommended interval is 24 hours.
INFO
Merchants should contact their Acquirers if they wish to use the NODELAY flag. All Acquirers are required to support this feature.