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.

• Recurring Transaction is a single Transaction initiated by the Merchant based on a Recurring Payment made by the User. 

Recurring Transaction is initialized by merchant independently from Recurring Payment. It's a separate event. User is charged upon Recurring Transaction and won't be charged automatically basing solely on Recurring Payment creation. Although it is possible to charge user for a first time during Recurring Payment set-up.

Recurring Payments are available in three implementation models:

• 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.

Usage: 

Merchants who have a product for which they charge only a fixed fee at a specific frequency and do not anticipate changing its terms during the validity of the BLIK Recurring Payment

• • Streaming services
  • Games
  • SaaS
  • Product subscriptions (cosmetics, fresh vegetables, animal food)

• • Other subscription businesses with flat fee

• Model M

In this model after creating Recurring Payment User's confirmation is required every time to complete every Recurring 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.

Usage:

Merchants who offer a product for which they charge different fees and/or fees at different frequencies.

• • 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.

• Model O

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). Recurring Transactions may have variable amounts and different frequency. The validity of a Recurring Payment may be specifically dated or marked as indefinite/until cancellation.

Usage: 

• • Merchants who offer a product for which they charge a fee of different amounts and/or with different frequencies and want user to not have to provide additional confirmation in the app
    • Examples: Mobility apps: electric scooters/taxi
•  

  • Merchants who offer a product for which they charge a fixed fee at a specified frequency and allow for plan changes or additional purchases during the recurring payment period.

    • Examples: Content providers with different available plans or the ability to purchase additional content/services

      
      

Frequency 

Frequency settings vary depending on the model used. This results in differences in information provided by merchant during Recurring Payment set-up. 

*Once specified, it must be adhered to until the end of the Recurring Payment's validity. 

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.

refuseNoPayID 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 refuseNoPayID 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 possibility that due to insufficient 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.