Last reviewed June 2026, the Przelewy24 (P24) onboarding, module credentials, callback behaviour and PLN-currency handling described here are current for PrestaShop 1.7, 8.x and 9.x. Settlement terms, fees and the exact module label vary by account and version, confirm them in your own P24 panel.
Here is the trap that catches almost every international merchant opening up to Poland: you switch your store to PLN, maybe add a Polish translation, leave your card gateway in place, and wonder why the orders don't follow. The problem isn't your prices or your product range. It's that you're asking a Polish customer to pay with a card, and the card is their least-favourite way to pay. In Poland the default is an online bank transfer or BLIK, and the gateway that aggregates nearly all of them is Przelewy24 (usually shortened to P24). This guide is specifically about getting P24 working correctly on PrestaShop. The account, the module, the callback that everyone gets wrong, and the configuration that decides whether orders actually close.
It is not a guide to which payment processor you should pick in the first place, or to the wider question of why offering local methods matters. Those are their own topics, linked at the end. If you've already decided Poland is a market you want and P24 is how you'll serve it, read on.
Why a card-only checkout quietly fails in Poland

Polish shoppers don't reach for a credit card the way Western European ones do. Card penetration in Polish e-commerce is low; the volume sits with online bank transfers (a "pay-by-bank" redirect that logs the customer straight into mBank, PKO BP, ING, Santander, Alior and the rest) and with BLIK, the six-digit-code mobile standard that most Polish banking apps now ship. Przelewy24 is the aggregator that puts all of those behind one integration: install one module and you accept bank transfers from essentially every Polish bank, BLIK, cards, and wallets like Apple Pay and Google Pay, plus BNPL options such as PayPo.
So what does that mean for your store? A single PrestaShop module covers the methods that the overwhelming majority of Polish buyers actually want to use, instead of forcing them onto a card and watching the order evaporate at the payment step. BLIK in particular is the one to get right; we cover why these local rails unlock the market, and how BLIK, iDEAL and Bancontact behave, in local payment methods that unlock local markets. The principle that more relevant options means more completed orders is laid out in why offering more payment options means more sales, and what European customers expect by region in payment methods for European e-commerce.
Step 1. Get a Przelewy24 merchant account
You can't configure the module without credentials, and credentials come from a merchant account. The path differs depending on where your company is registered.
Polish companies
Register at przelewy24.pl with your company data: NIP (tax ID), REGON, company name and a settlement bank account. You'll be asked to upload supporting documents:
- Company registration extract, KRS for a registered company, or a CEIDG printout for a sole trader
- ID document of the authorised representative
- A working store URL. P24 verifies a live, functioning shop, not a "coming soon" page
- A description of what you sell
Verification typically lands within a few business days once the documents are accepted.
Foreign companies
P24 does onboard non-Polish merchants, but expect a longer review and translated incorporation documents. The detail that matters for your accounting: P24 can settle in EUR, not only PLN, so a German or French entity selling into Poland can collect in złoty at checkout and receive settlement in euro, which keeps your books in one currency. Confirm the exact terms during onboarding rather than assuming, since rates and settlement options are negotiated per account.
Set up the sandbox first
P24 runs a separate sandbox at sandbox.przelewy24.pl with its own credentials, distinct from production. Build and test the whole integration there before a single real złoty moves. Skipping this is how stores end up debugging a broken callback against live orders.
Step 2, Install the P24 module on PrestaShop
Przelewy24 publishes an official PrestaShop module, available from their site and from the PrestaShop Addons marketplace. Always take the build that matches your PrestaShop major version. A module written for 1.7 will not behave correctly on 8.x or 9.x.
Install it the standard way: back office → Modules → Module Manager → Upload a module, then drop in the ZIP. After it installs it appears in your module list as "Przelewy24" (the exact label varies by version). Open its configuration page to enter credentials.
Step 3, Enter your credentials
The configuration screen needs a small set of values that all come from your P24 merchant panel. Get these exactly right. A single stray character here is the source of most "it worked in sandbox but not in production" tickets.
| Field | What it is | Where it comes from |
|---|---|---|
| Merchant ID (ID Sprzedawcy) | Your numeric merchant identifier | P24 panel, account data |
| Shop ID (ID Sklepu) | Per-shop identifier; usually equals the Merchant ID on single-shop accounts | P24 panel |
| CRC key | Signing key used to verify that callbacks genuinely came from P24 | P24 panel → Settings / account data |
| API key | Used for server-to-server calls (registering and verifying transactions) | P24 panel |
| Mode | Sandbox or Production | You set this; it must match the credential set you pasted |
The CRC and API keys differ between sandbox and production. If you set the module to Production but leave the sandbox CRC in place, the gateway will reject your transactions, so swap both keys and the mode together when you go live.
[SCREENSHOT: The Przelewy24 module configuration screen in the PrestaShop back office, showing the Merchant ID, Shop ID, CRC key and API key fields with the Sandbox/Production mode selector]
Step 4. Fix the callback URL (this is the one everyone breaks)
This single setting causes more lost orders than every other P24 issue combined, so it gets its own step. P24 doesn't tell your store about a successful payment through the customer's browser, it confirms the payment with a server-to-server POST to a notification (callback) URL on your shop. The customer's redirect back to your "thank you" page and that background POST are two different events. If the POST can't reach you, P24 takes the money and your store never finds out: the order sits in Awaiting payment forever, no confirmation email goes out, and stock isn't decremented.
The callback URL is a P24 module controller endpoint, roughly of the form:
https://yourstore.com/module/przelewy24/callback
Two things have to be true for it to work:
- It must be reachable from the public internet. Open it in a browser and you should get some response (even an error page), never a timeout. A timeout means P24 can't reach it either.
- Nothing must sit in front of it that a bot can't pass. Maintenance mode, an over-zealous firewall, an .htaccess rule, or a Cloudflare challenge page will all silently swallow the POST. P24's server isn't a human and won't solve a JavaScript challenge, if you run Cloudflare, allowlist the callback path so it bypasses any challenge or "Under Attack" interstitial.
Map P24's payment outcomes onto PrestaShop order statuses while you're here: Payment accepted → "Payment accepted", pending → "Awaiting payment" (or a dedicated pending status), and failed / cancelled → "Payment error" or "Cancelled". The accepted-to-accepted mapping is the one that has to fire automatically off the callback.
Step 5, Choose and order the payment methods
In the module you decide which P24 methods to surface. For a Poland-facing store the order matters as much as the selection:
- BLIK first. It's the method most Polish buyers reach for and the fastest to complete, so it should be the visible default, not buried under card fields.
- Bank transfers for the major banks. This is the backbone of Polish online payment.
- Cards as a fallback for international and card-preferring customers.
- PayPo / BNPL if you sell higher-ticket items where "pay later" measurably helps; skip it on low average order values where it just adds clutter.
BLIK can run two ways. The redirect method sends the customer to P24's hosted page to enter the code. It's the default, needs no extra setup, and keeps the card-data burden off your server. Direct BLIK puts the six-digit code field on your own checkout for a smoother flow, but it pulls you into additional P24 API configuration and extra UX and security handling you'd otherwise avoid. (No card data passes through BLIK, so this isn't about card-style PCI scope, but you're still taking on more integration surface to own.) For the large majority of stores the redirect is the right call; reach for direct BLIK only once you have the volume to justify shaving that one redirect.
Step 6, Handle currency correctly
P24 is a PLN-first gateway. If you run a multi-currency store, P24 must only appear when the customer is actually checking out in PLN. The module is built to enforce this, but verify it yourself: showing the P24 option to a customer browsing in EUR and then charging in PLN produces confused customers and chargebacks. In PrestaShop, restrict the payment module's availability by currency (back office → Payment → Preferences, where you can gate each payment module by currency, country and carrier) so P24 is offered to the PLN audience and nothing else.
[SCREENSHOT: PrestaShop Payment → Preferences screen showing the currency restriction grid, with the Przelewy24 module checked only for the PLN currency row]
Step 7, Test sandbox, then test production for real
In sandbox, P24 supplies test bank credentials. Walk the full path, don't just open the config page:
- Add a product, go to checkout, pick P24
- On the P24 page choose a test bank or BLIK and complete the simulated payment
- Confirm the order flips to "Payment accepted" in the back office, this proves the callback fired
- Confirm the order-confirmation email is sent
Then, after switching both keys and the mode to production, do one real low-value transaction, a temporary 1 PLN product paid with your own BLIK or bank transfer. Verify the money lands in your P24 balance, the order status updates by itself, and the email goes out. Also check whether a refund issued in the P24 panel syncs back to PrestaShop; if it doesn't, update the order manually or issue the refund through the module where it supports it. The classic failure here is going live with the module still in sandbox mode: payments look fine to you, but no real money ever moves. Check the mode after launch, every time.
Troubleshooting the four failures you'll actually hit
| Symptom | Most likely cause | Fix |
|---|---|---|
| Payment succeeds but order stays "Awaiting payment" | Callback POST isn't reaching your store | Check the notification URL is public; clear maintenance mode; allowlist P24 past any firewall or Cloudflare challenge; confirm valid HTTPS |
| "CRC verification failed" | CRC key in the module doesn't match the P24 panel, often a pasted trailing space, or sandbox key left in production | Regenerate/copy the CRC cleanly, match it to the current mode, re-save |
| Transaction rejected on amount | Store sent EUR, P24 expected PLN | Restrict P24 to the PLN currency so it never appears off-currency |
| Everything "works" but no money arrives | Module still in sandbox after go-live | Switch mode to Production and swap in production CRC + API keys |
Small configuration choices that lift completion
Once the plumbing is sound, a few presentation choices decide how many started payments actually finish:
- Lead with BLIK for a Polish audience, first option, not an afterthought.
- Show bank logos on the method selection. A Polish customer recognises their bank's mark instantly, and that recognition is reassurance at the exact moment doubt creeps in.
- Serve the payment page in Polish even if your storefront is English. P24 normally follows the customer's language setting, so make sure your PrestaShop has a Polish language installed and the customer's context resolves to it.
- Offer saved BLIK for returning customers where P24 supports it, to cut the repeat-buyer's friction.
Where P24 fits among the gateways
P24 is the natural default for a Poland-focused PrestaShop store because it aggregates the local rails behind one mature module. It isn't the only option. PayU is its direct competitor with comparable bank coverage, Tpay is a lighter-weight Polish alternative, and broader processors like Stripe and Mollie now support BLIK and Polish bank transfers too, which can make sense if Poland is one market among several rather than your core. So which do you pick? If you want to choose by feature and fee rather than by reputation, we put the gateways side by side in the best PrestaShop payment modules comparison, weigh the two giants in Stripe vs PayPal, and cover the multi-method route for stores spanning several countries in Mollie for PrestaShop and the full Stripe integration guide. If part of your Polish offer is "pay later," the mechanics and conversion trade-offs of BNPL are in buy now, pay later.
The short version
Selling into Poland without a local payment method is selling with the brakes on. Przelewy24 gives a PrestaShop store the bank transfers and BLIK that Polish buyers actually use, through one official module. The setup itself is undramatic, account, credentials, methods, currency, test, with one genuine landmine: the server-to-server callback. Get that URL reachable and unblocked, keep your CRC and mode in sync between sandbox and production, restrict P24 to PLN, and lead with BLIK. Do those, and the orders that a card-only checkout was quietly losing you start closing instead.
Frequently asked questions
A customer paid by BLIK but the order is still "Awaiting payment", why?
The payment cleared at P24 but the server-to-server callback that tells your store didn't reach it. The customer's redirect back to your thank-you page and P24's background POST to your callback URL are two separate events, if a firewall, maintenance mode, an .htaccess rule or a Cloudflare challenge swallows the POST, PrestaShop never learns the payment succeeded. Confirm the payment in your P24 panel, then make the callback URL reachable from the public internet and allowlist it past any Cloudflare challenge. P24's server can't solve a JavaScript challenge the way a human browser does.
Why am I getting "CRC verification failed"?
The CRC key in the module doesn't match the one in your P24 panel for the current mode. The usual cause is a trailing space pasted with the key, or a sandbox CRC left in place after switching the module to Production. Copy the CRC cleanly from the panel, make sure it matches the mode you're in (sandbox and production have different keys), and re-save. Remember the CRC and the API key and the mode all have to move together when you go live.
Can a non-Polish company use Przelewy24?
Yes. P24 onboards foreign merchants, expect a longer review and translated incorporation documents. The useful part for your accounting is that P24 can settle in EUR, not only PLN, so a German or French entity can collect in złoty at checkout (which is what Polish buyers expect) and receive settlement in euro, keeping the books in one currency. Confirm the exact settlement terms during onboarding, since they're negotiated per account.
Do I need P24 if Stripe or Mollie already support BLIK?
Not necessarily. Stripe and Mollie now support BLIK and Polish bank transfers, and if Poland is one market among several you serve, running everything through one of those can be simpler than adding a dedicated gateway. P24 earns its place when Poland is your core market: it aggregates essentially every Polish bank plus BLIK behind one mature, Poland-first module, and PayPo/BNPL options Polish buyers recognise. Choose by where your volume sits, dedicated P24 for a Poland-focused store, a multi-method processor for a pan-European one.
Why does P24 only appear for some customers and not others?
Because it's correctly restricted to PLN. P24 is a PLN-first gateway, so it should only be offered when the customer is actually checking out in zÅ‚oty, a customer browsing in EUR shouldn't see it. You set this in Payment → Preferences, where each payment module is gated by currency, country and carrier. If P24 is missing for a Polish customer, check they've resolved to the PLN currency; if it's wrongly appearing for a EUR customer, tighten that currency restriction.
Comments
Leave a comment
Share a question, an installation detail, or feedback that could help another reader.