Accepting payments in Poland and Central Europe. 6 chapters and a final quiz.

Chapter 1. Building the payment mix country by country.

A merchant’s payment mix is the set of payment methods it offers and the order in which they appear at checkout. It is decided market by market, because the methods people actually use differ from country to country. Poland, Czechia, Hungary, and Romania each have a dominant method of their own. A provider’s catalog lists the methods it can process. It does not tell you which ones local buyers use every day. Build the mix from the payment habits observed in the target country.

In all four countries, local payments run on account-to-account transfers rather than on cards. BLIK in Poland, qvik in Hungary, QR Platba in Czechia, and RoPay in Romania all use that rail. This has three consequences for the merchant. Funds arrive instantly, with no clearing cycle to finance. There is no 3-D Secure and no card scheme dispute process. Refunds run on a separate flow from collection and must be integrated explicitly.

Checkout order decides which payment method the buyer sees first, so it shapes how choices split. In Poland, placing BLIK below cards hides the country’s leading payment method, which the NBP credits with half of all e-commerce transactions by number. In Czechia and Hungary, by contrast, cards remain the natural entry point online, while the transfer layer is gaining ground mainly at the point of sale and on invoices.

• Decide country by country, never by region. A single “Central Europe” setting produces four mediocre checkouts instead of one good one.
• Check the settlement currency before the display currency. Collecting in PLN and getting paid out in EUR adds a conversion nobody budgeted for.
• Get the local method written into the contract, not just cards: a card acquiring contract gives you no rights to BLIK, qvik, or RoPay.
• Measure before you decide. Conversion rate by payment method and by country is the only data point that settles the ordering debate.
• Plan for refunds from the testing phase. On a transfer rail, refunds do not follow from collection and must be tested separately.

Chapter 2. Wiring up BLIK end to end.

BLIK is Poland’s mobile payment system. It triggers an account-to-account transfer from the payer’s banking app. It is operated by Polski Standard Płatności, a company owned by a consortium of Polish banks, and has been running since 2015. The user opens their own bank’s app and generates a code that always has 6 digits and is valid for 2 minutes (BLIK, FAQ, accessed August 2026). They enter it on the payment page, then confirm in the app. No card number is requested, and no PAN changes hands.

The 2-minute window constrains the entire integration. It keeps running while the buyer switches screens, reads the notification, and confirms in the banking app. Any time spent on a slow intermediate page comes out of that same window. A form without a countdown leaves the buyer unaware of how much time remains. If the checkout offers no button to generate a new code, a buyer whose code has expired cannot resume the payment, and the order is abandoned. Track the code expiry rate as a conversion metric in its own right.

• Recurring payments: after a first confirmed payment, an alias linked to the merchant allows the next charge without a code. BLIK’s FAQ explicitly cites subscriptions and electricity or phone bills.
• Czek BLIK: a 9-digit code, separate from the 6-digit code, used for payments and ATM cash withdrawals (BLIK, FAQ, 2026).
• ATM withdrawals and deposits, contactless payments in store: these use cases require their own acquirer setup. No existing card contract covers them.
• Transfers to a mobile number: outside the merchant’s scope, but this is the adoption driver that feeds everything else.
• Regional expansion: Polski Standard Płatności now controls the Slovak company BLIK SK, a.s. (formerly Viamo), whose gateway offers BLIK alongside cards, Apple Pay, Google Pay, and Sporopay.

1. Correct code, immediate confirmation            -> order created on webhook, not on redirect
2. Correct code, confirmed after 110 s             -> success; the countdown must not have cut the session
3. Correct code, no confirmation                   -> clean expiry + “generate a new code” button
4. Code declined in the banking app                -> cart intact on return, another method offered
5. Same code submitted twice                       -> one order only; idempotency on the merchant reference
6. Webhook replayed twice                          -> one order only; idempotency on the outcome ID
7. FULL refund                                     -> executed and reconciled
8. PARTIAL refund                                  -> executed; correct remaining balance in the back office
9. Recurring alias revoked by the user             -> explicit failure + customer follow-up, no blind retry
10. Amount in groszy                               -> PLN 49.90 sent as 4990, never as 49.9

Chapter 3. Setting up Polish acquiring: pay-by-link and zloty rails.

Pay-by-link is a payment flow in which the buyer pays by a transfer authorized in their own bank’s interface. It is the second pillar of payment acceptance in Poland. The buyer first picks their bank from a list shown at checkout. They are then redirected to that bank’s interface, which displays a prefilled transfer order with the payee, amount, and reference. The buyer authorizes it with their usual credentials, and the merchant receives a transfer instead of an authorization.

The risk model follows directly. An authorized transfer is pushed and irrevocable, which rules out a preauthorization awaiting capture, a scheme dispute window, and a late chargeback. The outcome is known as soon as the payment is authorized, with no later capture and no dispute period to monitor. The channel is used heavily for high-value orders, where card limits start to bite.

Poland’s market for payment providers is crowded and local. Przelewy24, operated by PayPro S.A., is a standard entry point: it combines pay-by-link, BLIK, and cards under one contract and operates as a payment institution supervised by the KNF. PayU, Tpay, and Autopay compete on the same ground. What sets them apart is the list of banks actually covered for pay-by-link, cooperative banks included, because if a bank is missing from that list, its customers cannot use the flow.

• Demand the named list of banks covered for pay-by-link, and compare it with how your target customers are actually spread across banks.
• Test the reconciliation reference: if one bank truncates the payment description, cash application breaks for a whole group of payers.
• Check the payout window the provider promises, separately from the rail’s own timing: the two add up.
• Document the Paybynet case, a KIR service built into the ePUAP public services platform, if your business involves administrative fees.
• Note that Autopay plays two roles (infrastructure operator through BlueCash and merchant provider), a setup to spell out in any RFP.

Chapter 4. QR codes are not an implementation choice: qvik, QR Platba, and RoPay.

A payment initiation layer is a national scheme that triggers a transfer from the payer’s banking app. Hungary, Czechia, and Romania each run one: qvik, QR Platba, and RoPay, respectively. The QR code shown to the customer does not belong to the merchant. Its format is set nationally, and banking apps recognize only that format. A QR code generated by the merchant, or borrowed from a wallet used in another market, therefore cannot be read. The customer opens the app, scans, and never gets a payment screen.

QR Platba encodes an IBAN, an amount, a message, and a variable symbol, the reconciliation key specific to Czechia. The variable symbol is the field Czech accounting has long used to match incoming payments. The merchant’s system must generate it, keep it unique per order, and print it identically on the invoice. A missing variable symbol produces an anonymous transfer; a reused one matches two orders to the same line.

• qvik-QR: a dynamic code shown at the register or at online checkout, regenerated for each amount.
• qvik-NFC: the phone is tapped on a compatible terminal, with no scanning.
• qvik-LINK: a payment link sent by text message or email, useful for remote sales and customer service.
• qvik-kérelem: the fizetési kérelem, a request to pay that Hungarian providers have been required to accept since April 1, 2024; this is the flow for invoicing and collections.
• The usual integration point in Hungary: SimplePay Zrt., formerly OTP Mobil Kft. and renamed in July 2025, which offers cards, terminals, tokenization, and qvik under a single contract.

In Romania, RoPay is a versioned scheme whose technical rules change through successive releases. The register of institutions that have joined the leu-denominated RoPay scheme is dated December 17, 2025, and version RoPay_V02R02 takes effect on April 30, 2026. A merchant’s connection is therefore not a one-time project: it follows a release calendar, as with a card scheme. The clause to secure from the provider is the upgrade lead time after a new version is published.

Chapter 5. Cash on delivery: costing it, containing it, reducing it.

Cash on delivery, ramburs in Romanian, means the customer pays the courier in cash for an order placed online. Romanian shoppers still expect it, and it is found elsewhere in the region too. Technically, though, no payment takes place when the order is placed. For the merchant, the transaction is trade credit extended to a stranger, combined with a collection mandate given to the carrier: the merchant fronts the goods and the shipping, then waits for the carrier to remit the cash. The topic therefore moves out of the payments team and into logistics and customer credit.

PARAMETERS TO MEASURE IN YOUR OWN DATA
  P   = average order value of the cash-on-delivery population
  M   = gross margin per unit
  r   = refusal rate at delivery
  Ta  = outbound shipping cost
  Tr  = return shipping cost
  Cp  = picking and packing cost
  f   = carrier collection fee (% of amount collected)
  d   = remittance delay, in days
  i   = daily cost of financing working capital

COST PER ACCEPTED ORDER
  refusal_loss     = r x (Ta + Tr + Cp + restocking cost)
  commission       = (1 - r) x f x P
  carrying_cost    = (1 - r) x P x i x d
  total_cost       = refusal_loss + commission + carrying_cost

DECISION
  If total_cost > M, cash-on-delivery orders destroy margin.
  The most sensitive lever is r, not f: one point of refusal costs
  a full round trip, not a percentage of the order value.

Chapter 6. KSeF, e-Factura, NAV: invoices become data flows, and four currencies stay local.

Under mandatory e-invoicing, invoices are reported, transmitted, or issued through a government system. Three of the four countries covered here have such a regime, each with its own logic. Hungary has invoices reported to the tax authority after issue, while Romania requires transmission within a set deadline. Poland is moving to a system in which invoices are issued by the government platform itself. Because the three regimes use different formats and timelines, no single connector covers all three countries.

The collection currency is the currency in which the merchant actually receives funds. Poland collects in zloty, Czechia in Czech koruna, Hungary in forint, and Romania in leu, and none of these four currencies is the euro. Slovakia adopted the euro in 2009, and Bulgaria on January 1, 2026, at the irrevocable rate of €1 = BGN 1.95583. A regional rollout therefore spans two distinct monetary regimes, with two sets of rails.

• One collection account per currency, at minimum: converting a PLN collection into a EUR account adds a conversion that the displayed price never shows.
• Align the display, settlement, and payout currencies. Three currencies in one chain mean two conversions and two FX margins.
• Display prices in local currency, rounded to local practice: a price converted on the fly signals a foreign seller and hurts conversion.
• Check the provider’s stance on dynamic currency conversion at the point of sale, and the rate applied to the cardholder.
• Document account descriptions: the reconciliation reference travels differently on national rails and on SEPA rails.