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.
• Maximum amount of single Recurring Transaction in Model O is 2000 PLN.
• Liability for potential frauds is moved form Bank to Acquirer and effectively merchant.

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.

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:

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 ride sharing

In this example: 

• Expiration Date: specified (limited to duration of the contract) 
• Frequency: variable, upon each service use
• Amount: variable, as per usage and price list
• 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 Acquirer 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.

• Merchant's Internet address (goods/@line-4) in case of WEB_PURCHASE Transaction.
• Merchant's short name (merchData/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.

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.