Payment
Przelewy24
Provenance unknown Report an error0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by PayPro S.A. · www.przelewy24.pl
Report an error on this page Is this your product? →
Link to this page
Add ?theme=dark to the image address for dark backgrounds.
The badge shows the category and the month of the latest evaluation, and EU-Made where
that is the product’s provenance. It never shows a score.
Przelewy24 at a glance
- Vendor
- PayPro S.A.
- Headquarters
- Not stated on the vendor’s pages as of 13 Oct 2026
- Data hosting
- Not stated on the vendor’s pages as of 13 Oct 2026
- Free plan
- Not stated on the vendor’s pages as of 13 Oct 2026
- Panel verdict
- The AI panel rates Przelewy24 1.5/5, the mean of 6 judges. Przelewy24, a payment service from PayPro S.A., scores best on checkout and strong customer authentication, 3-4: 3-D Secure 2.x meeting PSD2 requirements is stated, with four integration options and a demo store. how scores are made
- As of
- Vendor pages captured 13 Oct 2026; evaluated by the panel 15 Oct 2026. all sources
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
Przelewy24, a payment service from PayPro S.A., scores best on checkout and strong customer authentication, 3-4: 3-D Secure 2.x meeting PSD2 requirements is stated, with four integration options and a demo store. Settlement and reconciliation and licence and account terms each span 2-4: reports ship in CSV, HTML and XML by email or FTP, with payout and refund reports over REST and SOAP, but the judges found no published payout frequency, supervisor or register number, against a stated 15-working-day complaint deadline. Payment methods run 1-2 and recurring billing 2-3: five card acquirers are named with traffic routed between them, but no public list of local methods with countries and currencies was found, and recurring evidence ends at an integration option aimed at subscription merchants. The genuine split is sovereignty, 0 to 3: the written findings list the same absences — no sovereignty attributes on record, no published data-location statement, no subprocessor list — and weigh them differently. Pricing is payer-side only: refunds at 2 PLN by transfer, 2.9% of a debit-card prepayment, 30 PLN to a foreign account.
Speaks for it
- Checkout states 3-D Secure 2.x meeting the PSD2 requirements for strong customer authentication, with four integration options and a demo store for testing payments
- Reporting is documented: transactions, returns, payments and invoices in CSV, HTML and XML by email or FTP, plus transaction, payout and refund reports over REST and SOAP
- Five card acquirers are named — Fiserv, Worldline Financial Services, Elavon, Eservice and NETS DENMARK AS — with traffic routed between them
- The regulations publish a complaint deadline of 15 working days, extendable to 35 with additional information, and refund unused prepayments after 30 days minus the refund cost
- Onboarding is online, with contract acceptance at sign-up, data confirmed by a verification transfer, and sales possible the same day per the vendor's page
Held against it
- No public list of local payment methods with their countries and currencies was found, and no public information on SEPA Direct Debit or wallets
- Recurring billing is evidenced only as an integration option aimed at subscription merchants, with no public information on mandate handling, retries, dunning or exporting stored credentials
- Payout timing is stated only as 'regular and timely payments to the Merchant's account', with no published frequency or delay
- No public information was found on the supervisor, register number or licence type behind PayPro, or on safeguarding of merchant funds, reserves or termination notice
- No sovereignty attributes are on record, and no published statement was found on where transaction and cardholder data are processed, or on subprocessors
Best for
- You want a card checkout with 3-D Secure 2.x meeting PSD2 strong customer authentication that you can test in the demo store before signing up
- Your finance team builds its own reconciliation and values report delivery by email or FTP in CSV, HTML or XML, with payout and refund reports over REST and SOAP
- You want online registration with contract acceptance at sign-up and a published complaint deadline of 15 working days in the terms
Avoid if
- You plan entry into several markets and need each local method's countries and currencies documented before committing
- You must show where payment and cardholder data are processed, or list subprocessors, for a buyer or auditor
- Your subscription model depends on documented mandate handling, retries, dunning or the ability to export stored credentials
- Your month-end close requires a stated payout frequency or delay, not 'regular and timely' payments
The scores
| Criterion | Panel median |
|---|---|
| Payment methods & local coverage | 1 of 5 |
| Checkout, SCA & fraud | 1.5 of 5 |
| Subscriptions & recurring payments | 1 of 5 |
| Settlement, reconciliation & API | 1.5 of 5 |
| Licence, risk & account terms | 1 of 5 |
| European sovereignty | 0.5 of 5 |
Payment methods & local coverage
Show reasoningHide reasoning
How this is scored
Which methods a European customer can actually pay with — cards and wallets, SEPA Direct Debit, and the local methods that decide conversion per country — judged on the named list per market rather than on a method count.
0 — Cards only, or a method list with no statement of which countries and currencies each one covers.
3 — Major cards and wallets plus one or two European methods, with local coverage stated vaguely ("many local methods") and no SEPA Direct Debit.
5 — Cards, Apple Pay and Google Pay, SEPA Direct Debit, and the main local methods for DACH and Benelux (iDEAL or Wero, Bancontact, Klarna or invoice) listed by name with the countries they serve.
8 — Broad EU coverage named per country — including methods such as BLIK, TWINT, Przelewy24, EPS and Wero — multi-currency acceptance with settlement currencies stated, and which methods support refunds and recurring charges documented per method.
10 — Coverage is documented as a matrix a merchant can plan against: every method with its countries, currencies, refund, partial-capture and recurring support, and the provider's own acquiring versus third-party routing stated per method.
The Finance Lead
Card acceptance is real and well-backed — five named acquirers with traffic routed between them — and the terms distinguish transfer-based methods from card payments, but I found no public information naming which local methods a customer in any given country gets, or which currencies each covers. For treasury planning that means I cannot see what I would be settling, or in what. 3 6
The E-Commerce Lead
Card acceptance is evidenced with five named acquirers and traffic routing between them, and the terms reference transfer-based methods beyond cards, but the captured payment-methods pages never name the local methods, and we found no public information on SEPA Direct Debit or which countries and currencies each method serves. For my eight markets there is no per-country list to plan conversion against, only acquirers and integration styles. 2 3 6
The SaaS Founder
The card payments page names five acquirers with 3-D Secure 2.x, but the captured pages tell me nothing about which local methods a customer in each of my markets can actually pay with. I found no public information on SEPA Direct Debit, per-method country or currency coverage, or which methods support refunds and recurring charges, so I cannot plan a European rollout against what is shown. 3
The Payments Engineer
Five named card acquirers with traffic routing between them is resilience engineering, not method coverage — the captured pages name no local method with its countries or currencies, and I found no public information on SEPA Direct Debit, iDEAL, BLIK or any per-method list beyond cards. A merchant cannot plan market entry on this. 3 6
The Compliance Officer
The captured pages name five card acquirers with 3-D Secure processing, and the regulations describe transfer-based mechanisms such as one-time payment initiation, prepayment and the split-payment mechanism, but we found no public list of which countries and currencies each method serves, no wallets named and no SEPA Direct Debit. 3 6
The Skeptic
Card acceptance is the one method documented in any depth, with five named acquirers and traffic routed between them, and the regulations describe a transfer-based initiation service plus a split-payment mechanism that only works for transfer-based methods. Beyond that we found no public list of local methods with the countries and currencies each covers, and no public information on SEPA Direct Debit or wallets — the captured payment-methods page yielded no method names at all. 2 3 6
Checkout, SCA & fraud
Show reasoningHide reasoning
How this is scored
The path from basket to authorised payment under PSD2: hosted and embedded checkout options, 3-D Secure and SCA exemption handling, fraud screening, and what the provider documents about keeping legitimate payments from failing.
0 — A single redirect page with no statement on 3-D Secure, SCA or fraud screening.
3 — Hosted checkout with 3-D Secure 2 mentioned, fraud screening as an unexplained add-on, and no word on exemptions or declined-payment handling.
5 — Hosted and embedded checkout options, 3-D Secure 2 with SCA handled by the provider, configurable fraud rules, and the resulting PCI DSS scope for each integration type stated.
8 — SCA exemptions (low value, transaction risk analysis, merchant-initiated) applied and documented, fraud tooling with rules and risk scores exposed to the merchant, network tokens or account updater, and liability shift explained per flow.
10 — Authorisation is engineered and shown: exemption strategy documented, soft-decline retry handled, authorisation-rate reporting by method and issuer country, and a checkout the merchant can run in their own domain while staying at the lowest PCI scope.
The Finance Lead
The card page states 3-D Secure 2.x meeting the PSD2 strong customer authentication requirements, with hosted integration options (White Label, AJAX, the LVL0 form) and a demo store to test the payment path; a payment status 'Under verification' for security reasons is the only fraud-screening signal I can find. I found no public information on SCA exemptions, declined-payment handling or PCI scope per integration. 3 1 6
The E-Commerce Lead
3-D Secure 2.x meeting PSD2 strong customer authentication is stated, four integration options including a White Label form are offered, and a demo store lets me test the flow — but we found no public information on SCA exemptions, fraud rules or PCI scope per integration, so I cannot see how they keep legitimate payments from being challenged. The terms show a security verification step on received payments without explaining how it is configured. 1 3 6
The SaaS Founder
3-D Secure 2.x meeting the PSD2 strong customer authentication requirements is stated, with white-label and form integration options and a demo store to test payments, and a payment status of "Under verification" hints at security checks. We found no public information on SCA exemptions, declined-payment handling, configurable fraud rules, or the PCI DSS scope of each integration type. 3 1 6
The Payments Engineer
3-D Secure 2.x meeting PSD2 strong customer authentication is stated plainly, checkout comes in hosted-form, AJAX and white-label variants, and a demo store lets you test before signing — more than a bare redirect. I found no public information on SCA exemptions, configurable fraud rules, PCI scope per integration, or declined-payment handling. 1 3
The Compliance Officer
3-D Secure 2.x meeting PSD2 strong customer authentication is stated, four integration forms are offered (white label, AJAX, LVL0 form, recurring) and a demo store lets a merchant test payments, but we found no public information on SCA exemption handling, configurable fraud rules, PCI DSS scope per integration or declined-payment handling beyond an internal "Under verification" status. 3 1 6
The Skeptic
3-D Secure 2.x meeting PSD2 strong customer authentication is stated plainly, with four integration options and a demo store to try them. We found no public information on SCA exemptions, declined-payment handling, fraud rules or PCI scope for any integration; the only security signal is a payment status of 'additional verification for security reasons' with nothing behind it. 1 3 6
Subscriptions & recurring payments
Show reasoningHide reasoning
How this is scored
Charging the same customer again: card-on-file and merchant-initiated transactions, SEPA mandates, subscription logic and dunning — and whether the stored payment credentials can leave with the merchant.
0 — No stored payment methods; every charge needs the customer to pay again.
3 — Card-on-file tokens for repeat charges, but no SEPA mandate handling, no subscription logic, and failed-payment handling left entirely to the merchant.
5 — Stored cards and SEPA Direct Debit mandates, merchant-initiated transactions documented, and basic subscription plans with scheduled charges and failed-payment notifications.
8 — Subscription billing with trials, proration and plan changes, smart retries and dunning, card account updater, mandate management with pre-notification, and a documented process for exporting payment tokens to another provider.
10 — Recurring revenue is a first-class product: usage-based and invoice-based billing, dunning with measurable recovery, token migration in and out documented with a stated timeline and format, and recurring support stated for every local method that allows it.
The Finance Lead
A recurring product is offered among the integration options and marketed to subscription businesses with 'regular and timely payments to the Merchant's account'. I found no public information on mandate or card-on-file management, on retries and dunning, or on exporting stored credentials to another provider — the details that decide whether a subscription book can ever be moved. 3 4
The E-Commerce Lead
A recurring payment integration is offered and pitched at subscription merchants such as VOD platforms, utilities and gyms, with regular and timely payments to my account — but we found no public information on stored-credential tokens, SEPA mandate handling, retries or dunning, or any process for taking payment tokens to another provider. As a subscription seller I am being asked to buy on segment pitch alone. 3 4
The SaaS Founder
A recurring payments product is marketed straight at subscription businesses like mine — VOD, gyms, insurers — promising "regular and timely payments to the Merchant's account", but that promise is where the evidence ends. We found no public information on SEPA mandate handling, smart retries or dunning, trials or proration or plan changes, or any process for exporting payment tokens, and in my business an unanswered failed renewal is churn nobody chose. 4 3
The Payments Engineer
A recurring-payment integration option and a page aimed at subscription merchants exist, but the only concrete claim is "regular and timely payments to the Merchant's account", which is about payouts rather than billing logic. I found no public information on mandate handling, plans, proration, retries, dunning, or any path to export stored credentials. 3 4
The Compliance Officer
A recurring-payments product is marketed to subscription businesses such as VOD platforms, utilities and gyms, and recurring payment is offered as an integration option, but we found no public information on stored payment credentials, SEPA mandate handling, subscription logic such as retries or dunning, or any process for exporting tokens to another provider. 4 3
The Skeptic
A recurring-payment integration option exists and subscription-model merchants are named as the audience, with 'regular and timely payments to the Merchant's account' as the entire published benefit. We found no public information on stored credentials, merchant-initiated transactions, mandate handling, retries or dunning, or any route to export payment tokens — a brochure rather than a product description. 3 4
Settlement, reconciliation & API
Show reasoningHide reasoning
How this is scored
Getting the money and knowing what it was: payout cadence and currencies, fee itemisation per transaction, reports that match a bank statement, and an API and webhooks a team can build finance processes on.
0 — Payouts on an unstated schedule, one net amount per payout, and no API or report beyond an on-screen list.
3 — A stated payout schedule and CSV exports, but fees netted invisibly into payouts and an API with thin documentation.
5 — Payout frequency and delay stated, per-transaction fee breakdown in reports, a documented REST API with webhooks and a test mode, and exports that link each payout to its transactions.
8 — Configurable payout schedules and settlement currencies, reconciliation reports that match bank lines, accounting integrations or exports named, a versioned API with idempotency and published rate limits, and a public status page with incident history.
10 — Finance can close the month from the provider's data: interchange and scheme fees itemised per transaction, automated reconciliation to the ledger, a deprecation policy for the API, and full historical data exportable after the contract ends.
The Finance Lead
Reports on transactions, returns, payments and invoices ship in CSV, HTML and XML by email or FTP, and payout and refund reports are reachable over REST and SOAP — a workable data surface. But I found no public information on payout frequency or delay, per-transaction fee breakdown, webhooks or a test mode, and 'regular and timely payments to the Merchant's account' is not a cadence I can schedule a month-end close around. 5 4
The E-Commerce Lead
Transaction, payout, refund, return and invoice reports are documented through a REST and a SOAP API plus CSV, HTML and XML panel exports delivered by email or FTP, which is a workable reporting surface for my finance team. However, the only payout timing statement found is regular and timely payments to the Merchant's account, and we found no public information on payout frequency and settlement currencies, per-transaction fee breakdowns, webhooks or an API test mode. 4 5
The SaaS Founder
Reports on transactions, returns, payments, payouts and refunds come in CSV, HTML and XML, delivered by email or FTP, plus REST and SOAP reporting interfaces — a workable starting point for a finance team. We found no public information on payout frequency or settlement currencies, per-transaction fee breakdowns, webhooks, or an API test mode, and "regular and timely" payouts is a marketing sentence, not a schedule. 5 4
The Payments Engineer
Transaction, return, payment and invoice reports ship as CSV, HTML or XML through the panel, email, FTP, a REST API and SOAP — more delivery channels than most — but payout cadence is only the words "regular and timely", with no frequency or delay stated. I found no public information on per-transaction fee breakdown, webhooks, API versioning, idempotency, rate limits or a status page. 4 5
The Compliance Officer
Reports on transactions, returns, payments, payouts and invoices ship in CSV, HTML and XML, reachable through both REST and SOAP interfaces with email or FTP delivery, but the payout cadence is described only as "regular and timely payments to the Merchant's account", and we found no per-transaction fee itemisation, no webhooks and no reconciliation to bank lines. 5 4
The Skeptic
Reporting is genuinely documented: transactions, returns, payments and invoices in CSV, HTML and XML by email or FTP, plus REST and SOAP endpoints for transaction reports by date, payouts and refunds. But we found no public information on payout frequency or delay, no per-transaction fee breakdown, and no webhooks or API test mode — the demo store tests payments, not finance integrations. 1 5
Licence, risk & account terms
Show reasoningHide reasoning
How this is scored
Who holds the merchant's money under which licence, and what the contract lets the provider do on a bad day: freezes, reserves, termination, chargebacks. Scored on what the terms and the imprint state, not on reputation.
0 — No regulated entity named; terms allow freezing funds and terminating the account at any time with no notice, reason or timeline.
3 — A licence mentioned without the entity, supervisor or register number, and terms that permit reserves and holds with no stated limits.
5 — The regulated entity named with its supervisor and licence type, safeguarding of merchant funds stated, chargeback fees and dispute process published, and a notice period for ordinary termination.
8 — Entity, supervisor, register number and passporting stated per country; reserve and rolling-hold conditions defined with limits and release timelines; freeze and termination terms with reasons and a route to appeal; PCI DSS level and attestation published.
10 — The bad day is written down: every regulated entity in the chain named with register links, reserve calculation disclosed, funds release timelines after termination committed, a documented complaint route to the supervisor, and exit terms that include handing back payment tokens and transaction history.
The Finance Lead
The published terms commit to complaint handling within 15 working days (35 when more information is needed), set prepayment refunds at 30 days, and the contract is accepted online at sign-up. I found no public information on the licence, supervisor or register number behind PayPro, on safeguarding of merchant funds, or on reserve, freeze and termination terms — the clauses I read first on a bad day. 6 1
The E-Commerce Lead
The terms name PayPro, commit to processing complaints within a maximum of 15 working days, or 35 when additional information is required, and publish refund costs — but we found no public information on the licence type, supervisor or register number, safeguarding of merchant funds, reserves, or the notice period for termination. I know who I am complaining to and how long it takes, not who holds my money or under which licence. 6
The SaaS Founder
The regulations name PayPro as providing the ITP payment service, commit to processing complaints within a maximum of 15 working days (up to 35 with additional information), and publish refund costs to the zloty. We found no public information on the supervisor or licence register details, safeguarding of merchant funds, reserve or rolling-hold conditions, or notice periods for termination, so the bad-day terms remain unread. 6
The Payments Engineer
The regulations name PayPro, commit to a complaint SLA of at most 15 working days (35 when more information is needed), and publish refund costs — more contract text than many providers show. I found no public information on licence type, supervisor, register number, safeguarding of merchant funds, reserve or hold conditions, chargeback process or termination notice. 6
The Compliance Officer
PayPro S.A. is named and the regulations define a licensed payment initiation service with a published complaint deadline of 15 working days (up to 35) and detailed refund costs, but we found no public information on the supervisor, register number, safeguarding of merchant funds, chargeback fees and dispute process, or notice periods for termination and reserves. 6
The Skeptic
We found no regulated entity, supervisor or register number anywhere, and for a payments provider that absence is itself an answer. The regulations do commit to answering complaints within fifteen working days (thirty-five if more information is needed) and to refunding unused prepayments after thirty days minus the refund cost, but we found no public information on reserves, fund freezes, termination notice, safeguarding or chargeback fees. 6
European sovereignty
panel opinion
panel disagrees
Show reasoningHide reasoning
How this is scored
Who the contracting and regulated entity is, and where transaction and cardholder data are processed and stored. Independently sourced by the sovereignty pipeline. The card schemes are US-based for every provider, so the scheme layer is not held against any one vendor; the part the vendor controls is.
0 — Non-EU contracting entity, no statement on where payment data is processed, and subprocessors unnamed.
3 — An EU licensed entity contracts, but payment and customer data is processed outside the EU by default without an explained safeguard, or the subprocessor list is absent.
5 — EU contracting and regulated entity, EU processing stated for core payment data, but the group parent or significant parts of the chain (fraud scoring, support, analytics) are non-EU without a stated safeguard.
8 — EU entity and EU licence, payment and cardholder data processed and stored in the EU on named infrastructure, subprocessor list published with locations, and a DPA covering the processing the provider does as processor versus as controller.
10 — Sovereign end to end and evidenced: European ownership, EU entity and licence, every processing location and subprocessor European, European rails (SEPA, Wero or national schemes) offered alongside cards, and certifications published.
The Finance Lead
The independently collected attributes came back empty: I found no public information on where transaction and cardholder data is processed or stored, on subprocessors and their locations, or on a data processing agreement. The Polish-language terms with PLN fees and the named European acquirers hint at a European chain, but data residency itself is unevidenced. 6 3
The E-Commerce Lead
No sovereignty attributes are on record, and we found no public information on where the contracting entity is established, where payment and cardholder data are processed and stored, or which subprocessors are involved; the acquirers named are third-party routing rather than the vendor's own processing locations. Nothing here lets me answer a data-residency question from a buyer. 3 6
The SaaS Founder
The independently sourced sovereignty record carries no attributes at all, and the captured pages give no statement on where transaction and cardholder data is processed or stored, nor any subprocessor list. With nothing published to verify European processing, ownership or certifications, I can only score what the absence of evidence is worth. 1 6
The Payments Engineer
No sovereignty attributes are on record: the captured terms and pages carry no statement of where payment or cardholder data is processed, no subprocessor list, and no licence or passporting detail. I found no public information on any link in the chain the vendor controls. 6
The Compliance Officer
We found no public information on where transaction and cardholder data are processed, the subprocessor list, or a data processing agreement distinguishing when the provider acts as processor versus controller — an outsourcing exposure sharpened by the stated routing of card traffic between acquirers including Fiserv, Worldline Financial Services, Elavon, Eservice and NETS DENMARK AS. 3
The Skeptic
No independently sourced sovereignty attributes are on record, and the captured pages state neither the contracting entity's location nor where payment and cardholder data are processed. The only third parties named are five card acquirers; we found no published subprocessor list or data-location statement to score against. 3 6
Pricing transparency
not rated — the vendor publishes no price
Show reasoningHide reasoning
How this is scored
Whether a merchant can compute the effective fee for their own mix of cards, countries and methods — including cross-border and currency conversion markups, chargebacks, refunds, payouts and monthly fees — from public pages alone.
0 — No public prices at all; every rate is a sales conversation.
3 — A headline percentage exists, but it is unclear which cards and countries it covers, and cross-border, currency conversion or chargeback fees are unstated — the effective fee is unknowable.
5 — Rates published per main method with domestic and international cards distinguished, but at least one commonly incurred cost (currency conversion markup, chargeback fee, payout or monthly fee) is missing or "on request".
8 — Every method priced publicly, cross-border and currency conversion markups stated, chargeback, refund and payout fees listed, minimum monthly fees and contract term given, and whether the model is blended or interchange++ said plainly.
10 — Complete fee computability: the effective rate derivable for a given volume, card mix and country mix — interchange++ with the markup published or a blended rate with every exception listed — plus volume tiers, reserves and every ancillary fee on a public page.
The Finance Lead
Refund costs are published exactly — 2 PLN for a transfer refund, 2.9% of the prepayment for a debit-card refund, 30 PLN to a foreign account, plus the Polish Post charge for postal orders — which is the itemised style I want more of. But I found no public information on the transaction rate itself, per-method pricing, cross-border or currency conversion markups, or chargeback fees, so the effective cost of a sale is not computable from public pages. 6
The E-Commerce Lead
The only public prices I found are refund costs — 2 PLN for a transfer refund, 2.9% of the prepayment value for debit-card refunds, and 30 PLN for a refund to a foreign account — while we found no public information on acceptance rates per method, cross-border or currency conversion markups, chargeback, payout or monthly fees. I cannot compute an effective fee for my card and country mix from these pages. 6
The SaaS Founder
Refund costs are published exactly — "2 PLN (two zlotys)" by transfer, 2.9% of the value of the prepayment for debit-card refunds, "30 PLN (thirty zlotys)" to a foreign account — and the payer-side ITP service is free unless the merchant charges for a method. But we found no public information on acceptance rates for any method, cross-border or currency conversion markups, chargeback fees, or monthly fees, so the effective fee for my own card and country mix is unknowable. 6
The Payments Engineer
The only figures the captured pages publish are payer-side refund costs in the regulations — 2 PLN by transfer, 2.9% of the prepayment for a debit card, 30 PLN to a foreign account — plus the initiation service being free to the payer. I found no public information on merchant processing rates per method, cross-border or currency-conversion markups, chargeback fees, payout fees or monthly fees, so the effective fee cannot be computed. 6
The Compliance Officer
Refund costs are published to the zloty — 2 PLN by transfer, 2.9% for debit-card prepayments, 30 PLN to a foreign account, plus the Polish Post charge for postal orders — and payment initiation is stated as free to the payer, but we found no public merchant rates per method, no monthly or payout fees, no chargeback fee and no statement of whether pricing is blended or interchange-plus. 6
The Skeptic
The only public prices are what a payer pays to get their own money back: a refund costs 2 PLN by transfer, 2.9% of the value of the prepayment when paid by debit card, and 30 PLN to a foreign account, plus Polish Post charges for postal orders. We found no public information on merchant rates, cross-border or currency-conversion markups, chargeback fees, payout fees, monthly minimums or contract term, so the effective fee cannot be computed from these pages. 6
Questions about Przelewy24
Is Przelewy24 European?
Not determined: the vendor’s pages as captured do not say where Przelewy24 is based.
Where does Przelewy24 store data?
Not stated on the vendor’s pages as of 13 Oct 2026.
Does Przelewy24 have a free plan?
Not stated on the vendor’s pages as of 13 Oct 2026.
What are the best alternatives to Przelewy24?
As of 21 Oct 2026, the panel rates Adyen (3/5), Mollie (3/5) and Checkout.com (3/5) highest among the other 30 Payment products evaluated. Ratings that look equal are rounded to half stars; the order uses the unrounded rating, then the name. The highest-rated European alternative is Adyen (EU-Made). Ratings are the AI panel’s opinion, formed from public evidence: how scores are made. The full list, with European products first: Przelewy24 alternatives.
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 13 Oct 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- AI can misread a source. Extraction and judgement are automated; a citation guarantees traceability, not infallibility. If something here is wrong, say so — no account needed, every report is decided within 5 business days, and accepted corrections are published.
What we left out
A claim that does not survive our checks costs us the claim, not the page. This is what was taken off this one.
- We could not confirm any pricing information on the vendor’s own pages as captured, so this page shows none rather than a statement we cannot stand behind. Know more? Tell us
- 35 product facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 3 legal facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 3 support facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 6 of the readings below were written against an earlier fact sheet — a fact has been corrected, added or pulled since. Until the panel next runs on this product you are reading the older judgement. Know more? Tell us
Sources (6)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor page www.przelewy24.pl Checked 13 Oct 2026 Details →
- 2 Payment methods & local coverage — found from sitemap www.przelewy24.pl Checked 13 Oct 2026 Details →
- 3 Payment methods & local coverage — found from sitemap www.przelewy24.pl Checked 13 Oct 2026 Details →
- 4 Subscriptions & recurring payments — found from sitemap www.przelewy24.pl Checked 13 Oct 2026 Details →
- 5 Settlement, reconciliation & API — found from sitemap www.przelewy24.pl Checked 13 Oct 2026 Details →
- 6 Licence, risk & account terms — found from sitemap www.przelewy24.pl Checked 13 Oct 2026 Details →