Model O
How it works
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, Recurring Transactions initialized by the merchant are authorized by the Bank automatically:
without confirmation by the User in the banking app,
for a variable amount,
at a variable frequency,
until the set expiration date or indefinitely.
In O model there could be a steady frequency and amount similar to the A Model. However, when a user wishes for instance to change their subscription plan, there is no requirement to enter a BLIK code or create a new recurring payment.
IMPORTANT
Merchants intending to use Model O must be configured in the BLIK System. Configuration is performed on the basis of a parameterization form filled out
by the Acquirer serving the given Merchant. BLIK Certification is required. Refer to Certification document for more information.
Required information displayed on the Merchant's side while initiating the Recurring Payment in the O 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 |
Value shown in Banking App |
Mandatory |
|
Name |
Name of the product, along with 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 Label here. |
|
|
Amount |
The amount charged within the specified period. In instances of variable amount, clear information regarding variability. |
|
Absent from the banking app interface in the O Model. |
|
|
Frequency |
Frequency of Recurring Transactions occurrence within the specified quantity of the designated unit of measurement. In instances of variable frequency, clear information regarding variability. |
Steady Frequency: Available units of measurement:
Available quantity: 0-999 Correct examples:
Variable Frequency Examples:
|
Absent from the banking app interface in the O Model. |
|
|
Valid to |
Expiration date for recurring payment. In instances without specified expiration date, this information is not mandatory. |
The day, month, and year presented in the selected format. |
or
|
|
|
Next Payment |
The precise date of the upcoming recurring transaction. In instances without specified date of next payment, this information is not mandatory. |
The day, month, and year presented in the selected format. |
If Provided - date in DD.MM.RRRR format |
|
|
Now you will pay |
The exact amount that the user will be charged upon creating the recurring payment. If the fee is solely for verification purposes, details regarding its returnability. |
The currency value with precision to two decimal places.
0,00 0,01 returnable 29,99 |
or
|
|
The information from the table above can be arranged in any layout and order that is appropriate for the design system's requirements
Example of Recurring Payment process in O Model
Green screens - store
Purple screens- user's banking app
In the O model, transaction frequency and amount can be altered after the recurring payment is established without requiring additional user confirmation, for instance, transitioning from a standard to a premium pricing plan.
Below is an example of correct user path in O model with steady frequency and steady amount
Example market areas are Streaming Service or Content Providers with multiple pricing plans.
In this variant:
Expiration Date: indefinite
Frequency: steady, once in a month
Amount: steady 50,00 PLN
The user is charged for the first period upon Recurring Payment creation
In the banking app, the part of aliasLabel (with unique data about the user - email address: exampleuser@mail.com) is masked
Below is an example of correct user path in O model with steady frequency and variable transaction amount.
Example market areas include utility providers such as electricity, water, and gas, where the amount to be paid is contingent upon usage.
In this example:
Expiration Date: indefinite
Frequency: steady, once in a month
Amount: Variable, as per usage and agreement terms
User is not charged upon Recurring Payment creation
Below is an example of correct user path in O model with variable frequency and variable transaction amount.
Example market areas include mobility providers like electric scooters rental or ridesharing
In this example:
Expiration Date: specified (limited to duration of the contract)
Frequency: variable, upon each service use
Amount: variable, as per usage and pricelist
User is charged returnable 0,01 PLN for verification purposes upon Recurring Payment creation
Amount charged upon Recurring Payment creation
Green screens - store
Purple screens- user's banking app
The amount of the Transaction to which the invitation is attached may be zero or higher than zero. If it is higher than zero, it may, for example, correspond to the fee for the first subscription period; it may be the amount of the current invoice or PLN 1 to be returned to the User later.
Example of the process with charging user for the initial period upon creating a recurring payment.
Example of the process with charging user with returnable fee in verification purposes.
Example of the process without charging user upon creating a recurring payment.
Information shown in Mobile Banking Apps - Model O
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”
Date of next (upcoming) payment (/andAliasList/alias/autopayment@initDate) - in instances with steady frequency
The information that merchants need to provide to Aquirer to set up Recurring Payments in the O Model
Alias PAYID value (aliasValue) - alphanumeric string up to 64 characters, unique for given Recurring Payment
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 O 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 O 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" |
||
Merchant's Internet address (goods/@line-4) in case of WEB_PURCHASE Transaction.
Merchat's short name (MerchantmerchData/name/@short) in case of POS_PURCHASE
Alias expiration date - the expiration date can be set as "until further notice" or specified for a maximum of 10 years.
Info
Refer to Aquirer's API to see how correctly provide information above.
Init Date
In O model Merchant can optionally provide a date of first Recurring Transaction. It will result in displaying this information in a user's banking app in a Recurring Payment confirmation screen.
IMPORTANT
If initDate is provided, it must be strictly adhered to. Merchant must not execute Recurring Transaction earlier than this date