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, Repeat Transactions initialized by the merchant are authorized by the Bank automatically:

  • without confirmation by the User in the banking app (except for the first payment with the BLIK code that initiates BLIK Recurring Payment),
  • for a fixed amount,
  • at a fixed frequency,
  • until the set expiration date


IMPORTANT

A Recurring Transaction must align with the Recurring Payment. If there is an attempt to execute a Recurring Transaction for a different amount or frequency, Bank won't authorize such transaction automatically, therefore user will need to authorize the transaction in banking app.

Required information displayed on the Merchant's checkout while initiating the Recurring Payment in the A 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.

  • X.XX PLN (the amount in the A Model is fixed)


  • Amount in X.XX PLN format



YES

Frequency

Frequency of Recurring Transactions occurrence within the specified time unit.

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


Specified time unit for the occurrence of each Recurring Transaction with the information of payment authorization (in Model A → user will be charged automatically, without any confirmation).

YES

Valid to 

The expiration date of the Recurring Payment.

The day, month, and year are displayed in the specified format.

  • Date in DD.MM.RRRR format

YES

Next Payment

The precise date of the upcoming Recurring Transaction.

The day, month, and year are displayed in the selected format.

  • Date in DD.MM.RRRR format

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 A Model

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

Example of Recurring Payment initiation process in A  Model 

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 A Model 

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

Invitation data

Every invitation in A 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 model A, the expiration date must be specified and may be up to 10 years.

Alias Label

aliasLabel

Alias label (aliasLabel), alphanumeric string up to 35 characters which contains title of the BLIK Recurring Payment. This value along with merchant name/url should allow user to recognize particular Recurring Payment in Recurring Payment list in a banking app


How to correctly define Alias Label in the A 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.


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 A when sending an invitation to create a Recurring Payment, merchant obligatory specifies the frequency at which he will execute Recurring Transaction within given Recurring Payment as well as the date of first Recurring Transaction.


IMPORTANT

Automatic authorization (without user confirmation in the banking app) is possible only for one recurring transaction within a specified frequency. If a second recurring transaction attempt occurs within the given frequency, user confirmation will be required.

When setting the frequency of Recurring Transaction execution, merchant shall 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


II. The day on which the first Recurring Transaction will be executed /initDate/:

Merchant must point the exact date of next Recurring Transaction while creating Recurring Payment


IMPORTANT INFO


  • In case the designated day for processing a Recurring Transaction falls on a day that does not exist in a given month (e.g., the 31st of April), the transaction will be automatically authorized on the last day of that month (e.g. the 30th of April).
  • For  M (month) unit of frequency, we recommend setting the date of the first payment (@initDate) between the 1st and the 28th of the month. This is to avoid executing the Recurring Transaction in the next payment period, which would consequently require the next recurring transaction to be confirmed by the User in the Authentication Module (AM).



Examples of Frequency for A Model: 


  • For a frequency of 1M and an initDate of 15.01.2024, One Recurring Transaction will be automatically authorized in model A within the periods 15.01.2024-14.02.2024 (one month), 15.02.2024-14.03.2024 (one month), 15.03.2024-14.04.2024 (one month), and so on.
  • For a frequency of 1W or 7D and an initDate of 17.01.2024, One Recurring Transaction will be automatically authorized in model A within the periods 17.01.2024-23.01.2024 (one week = 7 days from Wednesday to Tuesday), 24.01.2024-30.01.2024 (one week = 7 days from Wednesday to Tuesday), and so on.
  • For a frequency of 30D and an initDate of 15.01.2024, One Recurring Transaction will be automatically authorized in model A within the periods 15.01.2024-13.02.2024 (30 days), 14.02.2024-15.03.2024 (30 days), 16.03.2024-14.04.2024 (30 days), and so on.



Info

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