# BLIK Recurrent Payments in SimPay

Note
If the text mentions *Subscription*, it refers to **BLIK Recurrent Payments**.

## What are BLIK Recurrent Payments?

BLIK Recurrent Payments allow a merchant or service provider to perform subsequent debits of a user's account based on a previously granted authorization.
Once a recurring payment is created, the user no longer needs to manually enter the BLIK code for each payment — subsequent transactions are initiated by the merchant and executed depending on the selected model: automatically or upon confirmation in the banking application.

## Why use BLIK Recurrent Payments?

- **User convenience** – no need to enter a BLIK code each time.
- **Higher conversion rate** – a simpler payment process increases the chance of completing a transaction.
- **Revenue predictability** – ideal for subscription-based and recurring billing models.
- **Flexibility** – supports both fixed and variable amounts.
- **Security** – transactions are executed according to the official BLIK standard with authorization in the banking app.
- **User control** – each consent is visible in the user's banking app and can be revoked at any time.


## Available Models

BLIK Recurrent Payments provide several operational models — described below for integration documentation purposes.

### Model A — Fixed amount, no additional confirmation required

- Purpose: subscriptions, installments, or services with fixed amounts and frequency.
- How it works: the first transaction requires entering the 6-digit BLIK code and confirming it in the banking app; after the recurring payment is created, subsequent charges are made by the merchant without requiring additional confirmation from the user.
- Features: simplicity, predictability for the user; the recurrence period can be predetermined (in practice, there may be limits — e.g., model A may have a maximum validity period).


**Example use:** a monthly streaming subscription with a fixed payment each month.

### Model M — Variable amount, user confirmation required each time

- Purpose: cases where the amount or timing of payments may vary (e.g., bills, variable charges).
- How it works: the first transaction initializes the consent (BLIK code); subsequent transactions are initiated by the merchant but must be confirmed in the user's banking app.
- Features: greater control for the user over each charge; consent may be limited in time or indefinite (until revoked).


**Example use:** paying variable utility bills or donation systems where the amount may change.

### Model O — Variable amount, no additional confirmation required

- Purpose: cases requiring payments of variable amounts but without the need for user confirmation each time.
- How it works: similar to Model M in terms of variable amount and frequency, but subsequent charges may be made automatically without user interaction (initiated by the merchant and processed without additional confirmation in the banking app).
- Features: combines flexibility regarding amount with the convenience of automatic charging.


**Example use:** services where the amount may vary but the user has authorized automatic debits (e.g., settlement accounts, flexible subscriptions).

## BLIK Requirements

For official BLIK requirements and model details, see the BLIK website.

## Subscription Frequency

Model A requires specifying frequency. Model M allows it optionally.

The frequency defines how often the next Recurring Payment can occur.

The field is divided into two parts:

1. The first part specifies the duration value in units defined by the second part and contains 1–3 characters:
  - The first character: [1-9]
  - The second character: [0-9] (optional)
  - The third character: [0-9] (optional)
2. The second part defines the unit of time in one letter:
  - `D` - daily
  - `W` – weekly
  - `M` - monthly
  - `Y` – yearly


If the recurring payment date falls on a non-existent day in a month (e.g., 31st of September), the payment should be executed on the last day of that month (e.g., 30th September).

For a `M` (monthly) period, we recommend setting the first payment date `options.initiationDate` between the 1st and 28th of the month to avoid scheduling issues.

If the frequency is exceeded, the bank will require the user to confirm the Recurring Payment in the banking app.

## Subscription Registration via Authorization

SimPay allows creating an initial transaction with a value of `0 PLN` to register a subscription.
In this case, the payer will not be charged when approving the Recurring Payment in their banking app.

Simply set the `amount` field to `0` when creating the transaction.

The `amount` field can only be set to `0` during subscription registration in SimPay.
Any further attempt to charge `0 PLN` in a recurring payment will result in an error.

## Creating a Subscription

1. When generating a transaction, you must:
  - set the `directChannel` field to `blik-recurrent`,
  - send the payer’s `antifraud.useragent`,
  - send `customer.email`,
  - send `customer.ip`,
  - send `customer.countryCode` (currently only `PL` is supported),
  - set the transaction currency to PLN (BLIK currently supports only PLN),
  - send `antifraud.systemId` – a unique payer identifier in your system (e.g., account ID). If a user has multiple subscriptions, the `systemId` must remain the same.
2. Next, send the Recurring Payment Creation Request.


Required options by model:

### Model A (AUTO)

- `options.expiresAt` – expiration date (required, up to +10 years from now),
- `options.frequency` – see above (Subscription Frequency),
- `options.amountLimitPerTransaction` – per-transaction charge limit,
- `options.initiationDate` – first recurring payment date (mandatory),
- `options.amountLimitTotal` – total limit for all recurring charges,
- `options.transactionsCountLimit` – optional, currently unused by banks.


### Model O (OPEN)

- `options.initiationDate` – optional; specifies first payment date,
- `options.expiresAt` – optional; expiration date, up to +10 years.


### Model M (MANUAL)

- `options.initiationDate` – optional; specifies first payment date,
- `options.expiresAt` – optional; expiration date, up to +10 years,
- `options.frequency` – optional; subscription frequency.


If the 6-digit BLIK code is incorrect, the response will match that of a BLIK Level 0 error.
See the BLIK Level 0 documentation for reference.

If the code is correct, two parameters will be returned:

- `subscriptionId` – SimPay subscription ID used for future charges,
- `aliasId` – SimPay alias ID (optional).


**Receiving a `subscriptionId` does not mean the subscription is active yet.**
You must wait for the IPN event `subscription:status_changed`.

Other events: `transaction_blik_level0:code_status_changed`, `transaction:status_changed`, and `blik:alias_status_changed`.

If the user has insufficient funds or a BLIK-side error occurs, it will be included in the `transaction_blik_level0:code_status_changed` message.
For more details, see IPN v2.

The event `subscription:status_changed` with status `subscription_active` means the subscription is now active.
You may now charge the user according to the selected model.

## Executing a Recurring Payment (Subsequent Transaction)

1. When generating a transaction:
  - set `directChannel` to `blik-recurrent`,
  - send `customer.email`,
  - send `customer.countryCode` (currently only `PL`),
  - set currency to PLN (BLIK supports only PLN),
  - send `antifraud.systemId` – the same as used during subscription creation.
Do **not** send IP address or UserAgent in subsequent recurring payments.
2. Next, send the Recurring Payment Execution Request.


- If retrying a failed charge, send a proper `attempt` value (0–9, where each next value increases by 1).
- The `alias.noDelay` parameter applies to models A and O.
Setting `noDelay = true` means you expect an immediate authorization response.
Otherwise, authorization may take up to 72 hours.


The response includes `needsUserConfirmation` — indicates whether the transaction requires user confirmation (`true`) or was processed directly (`false`).

Only one IPN event is sent: `transaction:status_changed`.
If status = `transaction_paid`, the payer was successfully charged and funds are transferred to you.

## AntiFraud System

SimPay uses an AntiFraud system for Recurring Payments, based on analysis of the payer’s previous transactions.
Currently, it applies only to model O.
If suspicious activity is detected, the payer receives an email with a confirmation link.
They have 7 days to confirm the transaction.