Model M
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 u ser'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 side while initiating the Recurring Payment in the M Model
Even if 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. |
|
Read More about Alias Value here. |
|
|
Amount |
The amount charged within the specified period. In instances of variable amounts, clear information regarding variability. |
|
Absent from the banking app interface in the M Model. |
|
|
Frequency |
Frequency of Recurring Transactions occurrence within the specified time unit. In instances of variable frequency, clear information regarding variability. |
Steady Frequency: Available units of measurement:
Available quantity: 0-999 Correct examples:
Variable Frequency Exmaples:
|
If provided - d ate in DD.MM.RRRR format |
|
|
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. |
|
|
|
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 returnability. |
The currency value with precision to two decimal places.
0,00 0,01 returnable 29,99 |
or
|
|
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:
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:
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.
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 |
||
|
us**er@em***com |
- |
"rental.pl us**er@em***com" |
|
|
agreement642/56 |
- |
" utilitybill.pl agreement642/56" |
|
|
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 Aquirer'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 mesurements:
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 occuring once in a month
With a frequency of 45D user will see information that payment will be occuring once 45 days
Info
Refer to Acquirer's API to see how to correctly provide the information above.