# 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 is a mechanism that allows a store or service provider to charge the user's account as part of a previously accepted consent. After creating a recurrent payment, the user does not have to manually enter a BLIK code for each subsequent payment — subsequent transactions are initiated by the merchant and processed depending on the chosen model: automatically or after confirmation in the banking app. ## Why Use BLIK Recurrent Payments? - **User convenience** – no need to enter a BLIK code each time. - **Higher conversion** – an easier payment process increases the chance of completing a transaction. - **Revenue predictability** – an ideal solution for subscription and recurring service models. - **Flexibility** – the ability to use both fixed and variable amount models. - **Security** – payments are processed based on the official BLIK standard and authorization in the banking app. - **User control** – every consent is visible in the banking app and can be revoked at any time. ## Available Models BLIK Recurrent Payments offer several operating models — described below in terms applicable for integration documentation. ### Model A — fixed amount, collection without additional confirmation - Purpose: subscriptions / installments / services with a fixed amount and fixed frequency. - How it works: the first transaction requires entering a 6-digit BLIK code and confirmation in the banking app; after creating the recurrent payment, subsequent collections are executed by the merchant without additional confirmation by the user. - Features: simplicity, predictability for the user; the recurrence validity period can be predetermined (in practice, there are time limitations for recurrence – e.g., Model A may be limited by a maximum validity period). **Example use case:** monthly streaming subscription with an identical fee every month. ### Model M — variable amount, each time confirmed by the user - Purpose: cases where the amount or timing of subsequent charges may vary (bills, variable-amount charges). - How it works: the first transaction initiates consent (BLIK code); subsequent transactions are initiated by the merchant, but each one requires the user to confirm it in the banking app. - Features: greater user control over individual collections; consent can be time-limited or indefinite (until revoked). **Example use case:** paying bills of variable amounts or a donation system where the amount may change. ### Model O — variable amount, collection without additional confirmation - Purpose: cases requiring payment execution with a variable amount, but without the need for each-time confirmation by the user. - How it works: similar to Model M in terms of variable amount and frequency, with the difference that subsequent charges can be collected without user interaction (the merchant initiates the collection and the transaction is executed without additional confirmation in the banking app). - Features: combines flexibility regarding the amount with the convenience of automatic collection. **Example use case:** services where the amount may vary, but the user has consented to automatic charges (e.g., billing accounts, some subscription models with flexible billing). ## BLIK Requirements To see the requirements and models, we encourage you to visit the BLIK page. ## Subscription Frequency Model A requires specifying the frequency. Model M allows sending it, but it is not required. The frequency determines how often the next Recurrent Payment can be made. The frequency field value is divided into 2 blocks: 1. The first block determines the period length in units defined by the second field and contains 1 to 3 characters, where: - First character in range: [1-9] - Second character in range: [0-9] (optional, may or may not appear) - Third character in range: [0-9] (optional, may or may not appear) 1. The second block defines in one character the unit of the payment period: - `D` - daily, - `W` – weekly, - `M` - monthly, - `Y` – yearly. When the Recurrent Payment execution day falls on a day that does not exist in a given month (e.g., the 31st day of September), the Recurrent Payment should be sent on the last day of that month (e.g., September 30). For the `M` (month) payment period, we recommend setting the first payment date `options.initiationDate` to fall between the 1st and 28th day of the month, to avoid executing the Recurrent Payment in the next payment period (the Recurrent Payment may be incorrectly forwarded for confirmation by the payer in the mobile banking app). If the frequency is exceeded, the bank requires the user to confirm the Recurrent Payment in the mobile banking app. ## Subscription Registration via Authorization SimPay allows creating the first transaction that creates a subscription for `0 PLN`. In this case, the payer will not be charged when accepting the Recurrent Payment in the mobile banking app. Simply set the `amount` field to `0` when generating the transaction. The `amount` field can be set to `0` only during subscription registration in SimPay. Subsequent attempts to charge the Recurrent Payment with 0 PLN 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 the payer's customer.email, - send the payer's customer.ip, - send the payer's customer.countryCode (currently only PL is supported), - set the transaction currency to PLN (BLIK currently supports only PLN), - you must send `antifraud.systemId` - this is the payer's identifier in your system (e.g., account ID) - the system ID must be unique for a single user. If the user has multiple subscriptions, the systemId must always be the same. 1. The second step will be to send a request to create a Recurrent Payment. Required options by model: ### Model A (AUTO): - `options.expiresAt` - subscription expiration date. Required field, maximum value is +10 years from now, - `options.frequency` - see above (Subscription Frequency), - `options.amountLimitPerTransaction` - Amount charge limit per single Recurrent Payment (one transaction), - `options.initiationDate` - date of the first Recurrent Payment (this field must be strictly followed) - the date when the first account charge will be executed, - `options.amountLimitTotal` - Amount charge limit for the entire Subscription period, - `options.transactionsCountLimit` - Optional field. Currently not used by banks. ### Model O (OPEN): - `options.initiationDate` - Optional field. When sent, it is the date of the first Recurrent Payment (this field must be strictly followed) - the date when the first account charge will be executed, - `options.expiresAt` - Optional field. Subscription expiration date. Maximum value is +10 years from now, ### Model M (MANUAL): - `options.initiationDate` - Optional field. When sent, it is the date of the first Recurrent Payment (this field must be strictly followed) - the date when the first account charge will be executed, - `options.expiresAt` - Optional field. Subscription expiration date. Maximum value is +10 years from now, - `options.frequency` - Optional field. Subscription frequency, If the 6-digit BLIK code is incorrect, a response analogous to BLIK Level 0 will be returned. Please refer to the BLIK Level 0 documentation to understand how it works. When the BLIK code is valid, 2 parameters will be returned: - subscriptionId - SimPay subscription ID, through this ID it will be possible to make subsequent charges, - aliasId - SimPay alias ID, saving it is not mandatory. **Returning the subscriptionId does not mean the subscription is already active.** You must wait for the IPN event `subscription:status_changed`. The events `transaction_blik_level0:code_status_changed`, `transaction:status_changed` and `blik:alias_status_changed` will also be sent. If the user does not have sufficient funds in their account, or another undesirable error occurs on the BLIK/payer side, this will be included in the `transaction_blik_level0:code_status_changed` message. For more details, see the IPN v2 tab. When SimPay sends the `subscription:status_changed` event with the subscription status `subscription_active`, it means the subscription has been activated. From now on, it is possible to charge the payer according to the given Model. ## Making a Recurrent Payment (Next transaction in an active subscription) 1. When generating a transaction, you must: - set the `directChannel` field to `blik-recurrent`, - send the payer's customer.email, - send the payer's customer.countryCode (currently only PL is supported), - set the transaction currency to PLN (BLIK currently supports only PLN), - you must send `antifraud.systemId` - this is the payer's identifier in your system (e.g., account ID) - the system ID must be unique for a single user. If the user has multiple subscriptions, the systemId must always be the same. For each subsequent transaction for a given Recurrent Payment, you do not send the IP address or UserAgent to SimPay. 1. The second step will be to send a request to execute a Recurrent Payment. - If you are calling another charge attempt for the same transaction, send the correct value of the `attempt` field - Values from 0-9, where 0 is the first attempt, and each subsequent value must be greater by 1 than the previous one. - The `alias.noDelay` parameter applies to transactions in Model A and O. The noDelay = true parameter means you expect an immediate response regarding authorization. If not sent, Recurrent Transaction authorization may take up to 72 hours. In the response, the `needsUserConfirmation` field will be sent. This field indicates whether the transaction was immediately forwarded to BLIK, or first awaits transaction confirmation by the payer. In such a case, an email will be sent to the payer's email address. Value `true` means it is awaiting transaction confirmation by the payer, Value `false` means the Recurrent Payment was sent directly to BLIK. When making a Recurrent Payment, only 1 IPN event is sent: - `transaction:status_changed` If the transaction status === `transaction_paid`, the payer was correctly charged, and the funds are transferred to you. ## AntiFraud System (fraud prevention) SimPay has an AntiFraud system for Recurrent Payments. It is based on the analysis of previous transactions made by the payer. The system is currently implemented only for Model O. If the system detects an irregularity, the payer receives an email with a link to confirm the payment. The payer has 7 days to confirm the transaction.