How it works

The user initiates the Recurring Payment in the merchant's service by selecting the "BLIK Recurring Payment" method and entering the BLIK code.

In this model, after creating a Recurring Payment, Repeat Transactions initialized by the merchant require the user's confirmation every time to complete every Repeat Transaction. Transactions may have:

  • variable amounts,
  • variable frequency,
  • can occur until the set expiration date or Indefinitely


BLIK Certification is required for each implementation model. Refer to the Certification document for more information.

Required information displayed on the Merchant's checkout while initiating the Recurring Payment in the M Model

Even though the user receives the mandatory information about the payment method in the banking app (on the payment authorization screen), part of it should be displayed on the merchant's side before the payment.

These fields are:

Field Name

Field description in Merchant System

Available Values

The value displayed in the Banking App

Mandatory

Name

Name of the product, along with the name of the Recurring Payment.



  • Agreement number
  • User ID
  • Plan Name
  • Name of the product or service
  • Merchant Name/URL + Alias Label value

Read More about Alias Value here.

YES

Amount

The amount charged within the specified period.

In instances of variable amounts, clear information regarding variability.

  • X.XX PLN (if the amount is steady)
  • As per agreement 
  • As per price list 
  • X.XX - X.XX (if there is a steady price range)


Absent from the banking app interface in the M Model.



YES

Frequency

Frequency of Recurring Transactions occurrence within the specified time unit.

In instances of variable frequency, clear information regarding variability.

Steady Frequency: 
Specified time unit for occurrence of each Recurring Transaction

Available units of measurement: 

  • day
  • week
  • month
  • quarter
  • year

Available quantity: 0-999

Correct examples: 

  • Every three weeks
  • Every month 
  • Every 6 months
  • Every 2 weeks
  • Once a year
  • Once a month


Variable Frequency Examples:

  • Upon each service use
  • Every 250gb
  • Variable


If provided - date in DD.MM.RRRR format

YES

Valid to 

The expiration date of the Recurring Payment.

In instances without specified expiration date merchant shall provide clear information about indefinite expiration date.

The day, month, and year are displayed in the specified format or information about indefinite duration.

  • Date in DD.MM.RRRR format

  • or "Valid until further notice" - in instances without a specified expiration date

YES

Now you will pay

The user will be charged the exact amount while initiating the Recurring Payment.

If the fee is solely for verification purposes, the merchant should display the details of its return.

The currency value with precision to two decimal places.


Example: 

0,00

0,01 returnable

29,99


  • Value in X.XX PLN format 

or

  • No amount displayed in the case of 0.00 PLN transactions

YES

Example of Recurring Payment process in M Model

Green screens - store
Purple screens- user's banking app

Example of Recurring Payment initiation process in M Model 

In this variant: 

  • Expiration Date: 31.08.2026
  • Frequency: fixed, once in a month
  • Amount: variable, as per usage and agreement terms
  • The user is charged for the first period upon Recurring Payment creation 




Example of Recurring Payment initiation process in M Model 

In this variant: 

  • Expiration Date: indefinite
  • Frequency: variable, as per usage
  • Amount: variable, as per usage and agreement terms
  • The user is charged for the first period upon Recurring Payment creation 

First Recurring Transaction amount while Recurring Payment initiation

Transaction amount can be 0,00 PLN or higher, it depends on the use case. A certain amount above 0,00 PLN may be the fee for the first month of the subscription, the payment for an invoice, or a 1,00 PLN fee (that will be returned to the user).

Example of the process of charging the user for the initial period while initiating a Recurring Payment



Example of the process of charging the user with a returnable fee for verification purposes while initiating a Recurring Payment


Example of the process without charging the user while initiating a Recurring Payment (amount 0,00 PLN may be displayed in the banking app but it's not a requirement in this case)

The information displayed in Mobile Banking Apps in M Model 

Examples of payment authorization screens in the banking app in different possible configurations (with a description of all mandatory data)


In mobile Banking app on the screen with the proposal to create a BLIK Recurring Payment in Model M, the following data is presented:

values in brackets represents field names in BLIK API


  • Information about Transaction and Recurring Payment activation or if the transaction is for the amount of 0 PLN only information about Recurring Payment activation
  • Amount of the current Transaction (/transaction/finData/@amt)
  • Alias label (/andAliasList/alias/@aliasLabel)
  • Depending on the type of Transaction carrying the invitation - the fourth line of the description (/transaction/goods/@line-4) for WEB transactions or the short name of the Merchant (/transaction/merchData/name/@short) for POS transactions
  • Alias expiration date (/andAliasList/alias/autopayment@expirationDate)
  • Information about the method of Authorization - “will require confirmation”
  • Frequency (/andAliasList/alias/autopayment@frequency) 


Invitation data

Every invitation in M Model must contain:

PAYID Alias Value

alias Value

Alphanumeric string up to 64 characters, unique for given Recurring Payment

Merchant's WEB Address

goods/@line-4

When the invitation is sent with the WEB_PURCHASE transaction - it contains the merchant's web address.

Merchant's Name

merchData/name/@short

When the invitation is sent with the POS_PURCHASE transaction type - it contains the merchant's name.

Alias Expiration Date

In M model, the expiration date can be set as "until further notice" or specified for a maximum of 10 years

Alias Label

aliasLabel

alphanumeric string up to 35 characters which contains title of the BLIK Recurring Payment. This value will be visible for the user in mobile banking app along all other BLIK Recurring Payments.

How to correctly define Alias Label in the M model: 


Alias label should be a value that along with merchant name enables user to identify the given BLIK Recurring Payment on the BLIK Recurring Payment list available in the user's mobile banking app.

To provide clear information, alias label must contain:


  1. Recurring Payment Identifier: This allows the identification of the specific BLIK Recurring Payment within the given merchant. This secures cases where one person has multiple accounts in the one merchant's system. For example, the user's login or email.
  2. Additional Identifier: This is necessary only in cases where one user can have multiple BLIK Recurring Payments set-up e. g. for 2 different products or services. For example, the product name or ID.


The additional identifier value must be fixed. It should be considered that in the M Model, users may have possibility to upgrade or degrade their plans. If that's the case, values that can vary over time (such as "standard plan", "gold", etc.) shouldn't be used as an additional identifier


When using personal user information such as email or phone numbers, these values must be masked.


Examples: 


MERCHANT NAME/ URL

ALIAS LABEL

FINAL VALUE VISIBLE IN BANKING APP

RECURRING PAYMENT IDENTIFIER

ADDITIONAL IDENTIFIER

rental.pl

us**er@em***com

-

"rental.pl us**er@em***com"

utilitybill.pl

agreement642/56

-

"utilitybill.pl agreement642/56"

gamepass.pl

us**er@em***com

game XY

"gamepass.pl us**er@em***com game XY"

game AB

"gamepass.pl us**er@em***com game AB"

Info

Refer to Acquirer's API to see how to correctly provide the information above.

Frequency

In model M when sending an invitation to create a Recurring Payment, merchant optionally  specifies the frequency at which he will execute Recurring Transaction within given Recurring Payment.

In model M, if provided, the frequency will be displayed on the Recurring Payment creation screen in User's banking app. The provided field is for informational purposes only and does not serve as a criterion for automatic authorization. In model M user confirms each Recurring Transaction. 


IMPORTANT

If Frequency is provided in the M Model, it must be strictly adhered to. The merchant must not execute Recurring Transactions with a different frequency. In the M Model, frequency should be provided only if there is a strong reason for showing information about frequency to the user in the banking app. 


When setting the frequency of Recurring Transaction execution, merchant can specify:


I. How often does recurring transaction happen within the given quantity of designated unit of measurement:


  • Available units of measurements: 
    • day
    • week
    • month
    • year
  • Available quantity: 0-999


Correct examples:

    • Every three weeks
    • Every month
    • Every 6 months
    • Every 2 weeks
    • Once a year
    • Once a month
    • Every 999 weeks


Examples of Frequency displayed in banking apps in M Model:

  • With a frequency of 1M, user will see information that payment will be occurring once in a month
  • With a frequency of 45D user will see information that payment will be occurring once 45 days



Info

Refer to Acquirer's API to see how to correctly provide the information above.