Stripe's BLIK Can Now Bill a Subscription Automatically. A 2,000 PLN Cap Decides Which Ones.

BLIK has been Stripe's answer to "how do I take payments in Poland" for a while, but strictly as a one-and-done method: customer gets a six-digit code from their banking app, types it in, approves within 60 seconds, transaction closes. Fine for a single purchase, useless for a subscription that needs to rebill itself every month without the customer doing anything. That changed in the September 30 Endive release. BLIK can now be saved as a reusable payment method and charged off-session — the same shape as a stored card — which means it finally belongs in a conversation about SaaS billing in Poland rather than just checkout.

That cap is the first thing to check before you get excited about adding BLIK to a Polish pricing page, because it decides outright whether this feature is relevant to your billing model at all. Below it, BLIK recurring is a genuinely useful rail. Above it, it's not an option yet, full stop.

How a BLIK subscription mandate actually gets set up

Reusable BLIK works through one of two flows: save the payment method while taking an initial payment, by creating a PaymentIntent with setup_future_usage set to off_session, or save it with no charge at all, via a SetupIntent with usage: off_session. Either way, the customer still goes through the familiar BLIK code step once — but this time they're also shown a BLIK Alias invitation inside their banking app, which is the actual mandate approval screen.

That invitation is where the customer sees what they're agreeing to: your merchant name and website, a masked version of their own email plus up to 35 characters of description text you control, an explicit statement that future payments will be charged automatically with no further authorization needed, the initial charge amount (or 0 PLN if it's a setup-only mandate), and the mandate's expiration date if you set one. You can cap a mandate at up to 10 years out with an expires_at timestamp, or leave it open-ended. Once the customer accepts, every subsequent charge against that mandate skips the code-and-approve step entirely — which is the whole point, and the thing that makes BLIK look like a card for the first time.

Underneath, Stripe runs this through what Poland's BLIK network calls Model O — a mandate type built specifically to support variable amounts and variable schedules, rather than forcing you to fix a price and interval at authorization time the way a lot of bank-debit mandates elsewhere require. That flexibility matters if your pricing has usage components, mid-cycle upgrades, or anything that isn't a flat recurring number — in principle, Model O doesn't care. In practice, the 2,000 PLN ceiling still caps what any single charge against it can be, variable or not.

The eligibility gate: two capabilities, nine banks

Turning this on isn't just a dashboard toggle. Your Stripe account needs both the blik_payments and blik_recurring_payments capabilities active, and the second one depends on the first — you have to request blik_payments, wait for it to activate, then request blik_recurring_payments on top of it. If you run a Connect platform, every connected account that wants recurring BLIK needs the same two-step request, in the same order, before you can attach a mandate to a subscription.

Getting the capability live doesn't mean every customer can use it, though. BLIK recurring payments only work for customers whose bank actually supports the mandate rail, and Stripe's list is short:

If a customer's bank isn't on that list, the mandate setup or the subsequent charge fails with a specific decline code — recurring_not_supported_by_bank — rather than a generic error. That's useful for diagnosis but doesn't give you much to do about it besides asking the customer to try a different linked account or pick another payment method. This is a newer, smaller list than what card or ACH dunning logic assumes exists; don't expect every BLIK-using customer to be eligible just because BLIK itself shows up as a payment option at checkout.

Where the 2,000 PLN cap actually bites

Run a few real billing scenarios against that number and the cap stops being an abstraction:

The usage-based row is the one worth building a specific safeguard around. A flat monthly plan either clears the cap every cycle or it never will, and you find that out once. A usage-based or hybrid invoice can clear it for eleven months and then fail on the twelfth, the month a customer's actual consumption pushes the bill over 2,000 PLN — which means a BLIK mandate that's worked fine for a year can start failing for reasons that have nothing to do with the customer's bank balance or intent to keep paying. We've covered the same shape of problem with usage-based billing churn generally; BLIK just adds a hard currency-denominated ceiling on top of the usual unpredictability.

If your Polish customer base skews toward annual contracts or has any usage component that can spike past roughly 2,000 PLN, the practical answer right now is to keep a card or bank-based fallback on file and treat BLIK as the default for whoever's charge size reliably stays under the cap, not as a universal replacement for however you already bill in Poland.

What a BLIK recurring decline actually tells you

The same release that added recurring support also made BLIK's decline codes more specific, replacing a generic failure with a code that says which of several distinct problems actually happened:

Note what's missing from that list: there's no code specifically for "exceeded the 2,000 PLN cap." Stripe's own guidance treats the cap as something you enforce before you ever attempt the charge, not something the decline taxonomy reports back to you after the fact. That puts the responsibility on your billing logic to check invoice amounts against the cap ahead of time, rather than relying on the same reactive decline-and-retry pattern that works for a card. It's a different posture from the cross-method decline vocabulary Stripe unified across payment methods earlier this year — BLIK's cap is a pre-flight constraint, not a post-attempt failure.

recurring_not_supported_by_bank deserves its own bucket in your dunning reporting rather than getting folded into a generic failed-payment count, for the same reason we've flagged with UPI Autopay mandate revocations in India: it isn't a retryable decline, and treating it like one just burns a retry attempt against a bank that was never going to clear the charge.

How small a slice of BLIK this still is

Worth sizing the opportunity honestly. BLIK's own Q1 2026 results show just how new recurring billing is relative to everything else the network processes:

BLIK processed 378.8 million e-commerce transactions in Q1 2026 alone, and clears more than two-thirds of all Polish online checkouts by most market estimates. Of that e-commerce volume, 1.5 million transactions — worth PLN 70 million — were recurring. That's not a rounding error by accident; it's a reflection of how new the mandate rail is. If you're weighing whether to build BLIK recurring support now, you're building ahead of adoption, not catching up to it — which cuts both ways. Early support is a real differentiator if you sell into Poland, but don't expect a large existing base of BLIK-mandate subscribers to migrate onto it on day one.

Custom checkout disclosures aren't optional

If you're using Stripe's hosted Checkout, it collects the BLIK code and the mandate authorization for you, but you're still responsible for the billing and mandate disclosures shown alongside it. Build your own payment form instead, and Stripe's documentation is explicit that you must display four things before collecting the BLIK code: the billing terms and a clear statement that the customer is authorizing recurring off-session payments, the initial charge amount (zero if it's setup-only), the charge cycle and cadence including the first charge date, and the list of banks that actually support recurring BLIK so the customer can check their own bank is on it before they try.

Skip any of those on a custom form and you're not just risking a compliance gap — you're also setting up the exact kind of "I didn't agree to this" dispute that Stripe's own dispute-evidence research shows is hardest to win without clear proof of what the customer actually consented to.

Where this leaves a Poland billing strategy

BLIK recurring is a genuine upgrade for subscription billing in Poland, but it's an upgrade with edges: a short list of eligible banks, a currency lock to PLN, and a per-charge cap that rules it out for annual contracts and anything usage-based that can spike unpredictably. For low-ACV, flat-rate monthly SaaS pricing, it's close to a drop-in replacement for whatever workaround you were running before — a saved card, a redirect-based rebill, or simply not serving BLIK-preferring customers on a subscription at all. For anything priced above a few hundred PLN a month, keep a backup payment method on file and route recurring_not_supported_by_bank and cap-related pre-checks into their own dunning path rather than your generic failed-payment queue. If you're trying to model how much involuntary churn a payment-method gap like this is actually costing you before you invest engineering time in a Polish billing integration, our churn calculator is a fast way to size it. And whatever the payment rail, a subscriber who hits a real cap or bank-eligibility wall deserves a recovery path that doesn't dead-end at a decline screen — which is exactly the gap a cancellation and retention flow like CancelFlow is built to catch before it becomes a silent loss.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.