Payment
Saferpay
Provenance unknown Report an error0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by Saferpay AG (Worldline) · www.saferpay.com
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.
Saferpay at a glance
- Vendor
- Saferpay AG (Worldline)
- 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 Saferpay 2/5, the mean of 6 judges. Saferpay AG (Worldline) is a payment product whose public documentation is strongest at the checkout and thinnest on the money and contract around it. 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
Saferpay AG (Worldline) is a payment product whose public documentation is strongest at the checkout and thinnest on the money and contract around it. Payment methods scored a flat 7, with local methods named per country alongside their routing acquirer, and checkout and SCA scored 7-8 on exemption limits — low value at 30 Euro, re-authentication after five transactions or a cumulative 100 Euro — soft-decline recovery and liability shift per transaction. The bottom of the score table is commercial: settlement and reconciliation 2-4, licence and account terms 1-2, sovereignty 1-2, with no public information on payout terms, the regulated entity and its supervisor, or where payment data is processed. Two splits stand out. Recurring billing runs 4-6 — the merchant-initiated rails are documented in depth, but every schedule, retry and dunning step is the merchant's own cronjob (engineer 6, SaaS founder 4). Settlement runs 2-4 for the same reason: a documented JSON API and test environment against no published payout or fee reporting (finance lead 2). No prices are published; pricing questions are routed to the account manager or sales team.
Speaks for it
- Checkout and SCA scored 7-8, with exemptions, soft-decline recovery and per-transaction liability shift documented to parameter level
- Payment methods scored a flat 7, naming local methods per country alongside the acquirer that routes each one
- Merchant-initiated transactions are documented in depth, including five-year retention of the initial transaction
- The JSON API is documented in detail, with a test environment that can force declines
- The merchant's order reference is routed through to the processor and appears in reconciliation files
Held against it
- Licence and account terms scored 1-2, with no public information on the regulated entity, safeguarding of merchant funds, reserves or termination terms
- Sovereignty scored 1-2, and the record shows no sovereignty attributes
- Settlement and reconciliation scored 2-4, with no public information on payout frequency, settlement currencies or per-transaction fee breakdowns
- Subscription scheduling, retries and dunning are left to the merchant's own systems, on a published 24-hour retry recommendation
- No public prices exist, with the licensing page directing pricing questions to the account manager or sales team
Best for
- You sell into Germany, Switzerland, Liechtenstein or Austria and need local methods such as TWINT, eps, BLIK or Bancontact
- You want granular control of 3D Secure — forced challenges, exemptions with stated limits, and liability shift returned per transaction
- You have engineering capacity to build scheduling, retries and dunning on top of documented merchant-initiated transaction rails
- You want to evaluate against a documented JSON API and a test environment before contracting
Avoid if
- You sell mainly outside Germany, Switzerland, Liechtenstein and Austria — the feature licences apply only to those countries, with others referred to legacy licensing
- You want a provider-run subscription product — every charge is triggered by your own system, and merchant-initiated transactions require the Business licence
- Your finance close depends on published payout schedules and fee reports — the pages route reconciliation questions to the account manager
- Your procurement requires documented data residency and a subprocessor list before signature — the sovereignty record carries no attributes
The scores
| Criterion | Panel median |
|---|---|
| Payment methods & local coverage | 3.5 of 5 |
| Checkout, SCA & fraud | 4 of 5 |
| Subscriptions & recurring payments | 2 of 5 |
| Settlement, reconciliation & API | 2 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
The acquirer and methods table names the locals per market — iDEAL, Bancontact, BLIK, Przelewy24, eps, TWINT, Wero, Klarna and SEPA Direct Debit each with the country it serves, on top of the major cards and wallets. We found no public information on settlement currencies, or on which methods support refunds and recurring charges. Good enough for a DACH-centred book; I could not plan a full EU roll-out against it. 2 5
The E-Commerce Lead
The acquirer pages are a genuine per-market map: TWINT, PostFinance Pay and Reka for Switzerland, EPS for Austria, iDEAL, Bancontact and payconiq for Benelux, BLIK and Przelewy24 for Poland, plus Klarna, Wero, SEPA Direct Debit and both wallets, with the acquirer named so I can see what rides on Worldline's own rails versus a third party. We found no public information on settlement currencies or refund support per method, and for France, Spain and Italy the only named options are cards and American Express, which would cost me conversion in two of my eight markets. 2 5
The SaaS Founder
The acquirer table is a list I can plan a rollout against: TWINT for Switzerland, eps for Austria, iDEAL 2.0 and Bancontact for the Benelux markets, Blik and Przelewy24 for Poland, Wero, Klarna and SEPA direct debit, each with its country coverage and the acquirer doing the routing. I found no public information on settlement currencies or on which methods support refunds and recurring charges per method, and the recurring-payments page flags Apple Pay, Google Pay, TWINT and PayPal as needing attention for that flow. 2 5
The Payments Engineer
The acquirer pages name a broad, per-country list — BLIK for Poland, Przelewy24, eps for Austria, TWINT for Switzerland, Wero, Bancontact for Belgium, iDEAL 2.0, SEPA Direct Debit and the Klarna variants — each with the acquirer that routes it, which is close to what a merchant plans against. We found no public information on settlement currencies or on which methods support refunds versus recurring charges, so it stops short of a complete matrix, and the licensing itself is written only for Germany, Switzerland, Liechtenstein and Austria. 2 5 7
The Compliance Officer
The acquirer pages name broad coverage per country — TWINT, payconiq and PostFinance for Switzerland, iDEAL 2.0, BLIK, Przelewy24, EPS, Wero, Bancontact and Klarna each with the country served and the routing acquirer — and SEPA Direct Debit is on the method list. Settlement currencies and refund or recurring support per method are not documented, and from a control standpoint the many third-party acquirers in the chain (PAYONE, PayPal, PostFinance, Reka and more) are at least named, which matters for outsourcing oversight. 2 5
The Skeptic
The acquirer tables name local methods country by country — TWINT for Switzerland, Bancontact and payconiq for Belgium, BLIK and Przelewy24 for Poland, eps for Austria, iDEAL 2.0, Wero, Klarna and SEPA Direct Debit — alongside the major cards and wallets. For planning purposes it falls short of complete: we found no public information on settlement currencies, or on refund and recurring support documented per method. 2 5
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 authentication pages are documented to parameter level and honestly: low-value and transaction-risk-analysis exemptions with their limits, soft-decline handling with the re-registration path, liability shift returned per transaction, and the challenge flow forceable per integration. The fraud controls I can see are back-office card blocking and an automatic risk-analysis exemption service; we found no public information on risk scores exposed to the merchant, an account updater or network tokens. This is the strongest-documented part of the offering. 3 4
The E-Commerce Lead
The best-documented exemption game I have seen: low-value and transaction-risk-analysis exemptions with reset rules, the risk engine applying the analysis automatically, a switch to force the challenge only when needed, liability shift returned per transaction with the liable entity named, and soft-decline recovery with issuer codes and test cards to rehearse it. Checkout comes as a hosted page, an API-driven flow or a hosted entry form, though we found no public information on the PCI scope of each integration beyond the note that raw card posts require full certification. What keeps it off the top mark: no public information on network tokens, an account updater, or authorisation-rate reporting by method and issuer country. 3 4 7
The SaaS Founder
This is the best-documented part of the product: low-value and transaction-risk-analysis exemptions with their exact caps, a recurring exemption with an honest warning, soft declines with named processor codes and a documented recovery path (re-register the card with forced SCA), and liability shift returned per transaction with a condition flag to demand it before authorising. I found no public information on account updater or network tokens, authorisation-rate reporting, or fraud tooling beyond blocking business-card BIN ranges in the back office. 3 4
The Payments Engineer
This is the strongest part: exemptions are documented and engineered — low value up to 30 Euro with the 5-transaction and 100-Euro cumulative re-authentication rules, transaction risk analysis via Saferpay Fraud Intelligence, and a merchant-initiated exemption the provider itself warns about — plus soft declines returning PAYER_AUTHENTICATION_REQUIRED, test cards to force them, and a documented re-registration path under forced SCA. Liability shift is returned per transaction with the merchant's exposure spelled out when an exemption is granted. We found no public information on authorisation-rate reporting, network tokens or an account updater, and PCI scope is stated only for the direct-post flow, which requires full PCI certification. 3 4
The Compliance Officer
Exemptions are the best-documented part: low-value with its 30 Euro cap, five-transaction and 100 Euro cumulative limits, transaction risk analysis applied automatically by Fraud Intelligence, and the merchant-initiated case, all with liability shift, the liable entity and PSD2 scope explained per flow. Soft declines with issuer reason codes, forced-challenge parameters and test cards to reproduce them are published; I found no public information on risk scores surfaced to the merchant, an account updater or network tokens, authorisation-rate reporting, or the PCI DSS scope of each integration type. 3 4
The Skeptic
This is where the pages are strong: exemptions are written down with their limits (low value at 30 Euros, five transactions or a cumulative 100 Euros, transaction risk analysis via Fraud Intelligence), soft declines are handled by re-registering the card with forced authentication, and liability shift is returned per flow with a flag to refuse transactions that do not carry it. We found no public information on account updater services, fraud risk scores exposed to the merchant, or authorisation-rate reporting, which keeps it below the top. 3 4
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
Merchant-initiated transactions are documented properly — aliases for irregular charges, referenced transactions on a strict schedule, the initial transaction held for five years — but the subscription logic itself is mine to build: scheduling runs on my own cronjob and the failed-payment advice is a retry after 24 hours. We found no public information on SEPA mandate management, dunning, or taking stored credentials to another provider. Pipes, not a product. 5 3
The E-Commerce Lead
Merchant-initiated transactions are documented properly — referenced charges for fixed-schedule subscriptions, stored card data for irregular follow-ups, the authenticated initial transaction kept for five years, and a way to attach authentication to an existing stored card — but every schedule and every retry is mine to build, their own example being a server cron job and a 24-hour retry recommendation. We found no public information on SEPA mandate handling, dunning, card account updates, or exporting stored credentials to another provider. The rails are solid; the subscription product is my job. 3 5
The SaaS Founder
Merchant-initiated transactions are properly engineered — Secure Card Data aliases for irregular charges, referenced transactions as the primary route for subscriptions, the initial SCA'd transaction stored for five years, old aliases automatically updated with SCA data — but Saferpay never charges on its own: every schedule, retry and dunning e-mail is mine to build, and the retry advice is literally a recommendation to run a cronjob. I found no public information on SEPA mandate management, a card account updater, or any process for exporting payment tokens to another provider — for a subscription business that silence is the part that worries me. 5
The Payments Engineer
Merchant-initiated transactions are a documented product: a Secure Card Data alias for irregular charges, referenced transactions kept for five years as the primary subscription path, aliases that get SCA data attached retroactively, and a clear statement that Saferpay only charges when the merchant's system requests it. However the retry guidance is a merchant-side cronjob after 24 hours, and we found no public information on subscription plan logic, dunning, SEPA mandate handling, an account updater, or exporting stored credentials to another provider. Recurring also sits behind the Business licence rather than the base product. 3 5 8
The Compliance Officer
Merchant-initiated transactions are documented in real depth — aliases with SCA data attached, issuer-reference transfer for network recurring transactions, a five-year retention of the initial transaction, and a 24-hour retry recommendation — and the referenced-transaction path is named as the primary subscription method. Scheduling is nonetheless left to the merchant's own cron, and I found no public information on SEPA mandate handling with pre-notification, dunning, a card account updater, or any process for exporting stored payment tokens to another provider. 5 3
The Skeptic
Merchant-initiated transactions are documented in real depth — referenced transactions for subscriptions, aliases for irregular charges, a five-year retention of the initial transaction, authentication data carried across — but every schedule and retry is the merchant's own cronjob, not the provider's logic. We found no public information on SEPA mandate management, subscription features such as trials or proration, dunning, or a documented process for exporting stored payment tokens to another provider, and that portability gap is what settles the score. 5 3
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
This is what I close the month on and it is the thinnest part: the reconciliation page confirms my order reference is carried into the processor's reconciliation files and that third parties like PayPal report separately, and every other question is referred to my account manager. We found no public information on payout schedule or currencies, per-transaction fee breakdowns, webhooks, or reports tying payouts to bank lines. An API and a batch close exist; a cash forecast does not. 6 7 8
The E-Commerce Lead
What is published helps a little: my order reference flows through to the processor and into reconciliation files, batch close exists, and there is a documented JSON API with a test environment — though they are upfront that third-party methods like PayPal reconcile on that processor's data. We found no public information on payout frequency or delay, settlement currencies, per-transaction fee breakdowns or webhooks, and reconciliation questions are directed back to my account manager. I could not close a month from the public pages. 6 7 8
The SaaS Founder
Reconciliation is built on the merchant-defined order reference, which Saferpay routes through to the processor so it lands in the reconciliation files, with the honest note that third-party processors like PayPal send their own data; the JSON API itself is documented in detail, with a test environment and licence-gated feature tags. I found no public information on payout frequency or delay, per-transaction fee breakdowns, webhooks, idempotency, or a status page. 6 7 8
The Payments Engineer
The reconciliation documentation is essentially one design decision — a merchant-defined order reference routed through to the processor's files — with PayPal and other third-party processors sending their own data that finance has to stitch together, and remaining questions routed to an account manager. The JSON API itself is deeply documented with a spec version, and the test environment can force declines, which is more than thin; but we found no public information on payout cadence or currencies, per-transaction fee breakdown, webhooks, rate limits or a status page. 6 7 8
The Compliance Officer
Reconciliation rests on a merchant-defined order reference that is routed to the processor so it appears in reconciliation files, with the caveat that for third-party processors such as PayPal the data comes from that processor; batch close, a test environment and licence-gated API access are published. I found no public information on payout frequency, settlement currencies, per-transaction fee itemisation, webhooks, rate limits or a status page — and reconciliation questions are routed to the account manager rather than to published documentation. 6 7 8
The Skeptic
The API is genuine — specification, error behaviours, a test environment, capture and inquiry calls — and the merchant's own order reference is routed through to the processor's reconciliation files. But the money side is dark: we found no public information on payout frequency or delay, per-transaction fee breakdowns, webhooks, or reports that tie a payout to its transactions. 6 7 8
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 licence pages give me product tiers and feature availability — useful for budgeting, but this question is about who holds my money and what the contract permits on a bad day. We found no public information on the regulated entity and its supervisor, reserve or rolling-hold conditions, freeze and termination terms, or chargeback fees and the dispute process. A rolling reserve discovered on a Tuesday is exactly what this silence buys. 7 8
The E-Commerce Lead
The licensing pages are feature tiers and a sales conversation, not contract terms: we found no public information on the regulated entity, its supervisor or register number, safeguarding of merchant funds, chargeback fees, dispute handling, or termination notice. Reserves, holds and any appeal route are likewise absent from what was captured. Before I route money through a provider in eight countries, I need the bad-day terms in writing. 7 8
The SaaS Founder
The captured pages are thorough on product licensing — eCommerce versus Business, four tiers, feature matrices, permission-denied errors when you call beyond your licence — but that is feature gating, not custody of my money. I found no public information on the regulated entity and its supervisor, safeguarding of merchant funds, reserve or hold conditions, chargeback fees, or termination notice and appeal routes. 7 8
The Payments Engineer
The captured pages document feature licensing — Go, Easy, Flex, all-in-one and the Business extension, with a PERMISSION_DENIED error for the wrong tier — but that is software packaging, not the risk terms this criterion asks about. We found no public information on the regulated entity, supervisor or register number, safeguarding of merchant funds, reserves, freezes, chargeback fees, or a notice period for termination. 7 8
The Compliance Officer
The licensing pages describe commercial licence tiers applicable to Germany, Switzerland, Liechtenstein and Austria, but nowhere is a regulated entity named with its supervisor and register number, and there is no statement on safeguarding of merchant funds. I found no public information on reserve or rolling-hold conditions, termination notice periods, chargeback fees, or a dispute and appeal route. 7 8
The Skeptic
The captured licensing pages describe product tiers for Germany, Switzerland, Liechtenstein and Austria, not who holds the merchant's money: we found no regulated entity with a supervisor or register number, no safeguarding statement, no chargeback fee or dispute process, and no reserve, freeze or termination terms. A missing licence number is an answer. 7 8
European sovereignty
panel opinion
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 sovereignty record is empty: we found no public information on the contracting entity's regulatory status, where payment and cardholder data are processed, or any subprocessor list. The only European signals are circumstantial — licences sold in Germany, Switzerland, Liechtenstein and Austria, and rails like SEPA Direct Debit, Wero and TWINT in the method table. I treat data location as unevidenced until it is published. 2 7
The E-Commerce Lead
Nothing is on record for where payment and cardholder data are processed or stored, and no subprocessor list or data-processing agreement appears in the captured pages — that silence is the finding. The licensing pages only tell me the served markets are Germany, Switzerland, Liechtenstein and Austria. For a merchant selling across the EU, we found no public information answering the ownership, licence or data-location questions. 7
The SaaS Founder
The only geographic signals are the licence country list (Germany, Switzerland, Liechtenstein, Austria) and per-country acquirer routing across Europe. I found no public information on the contracting entity's domicile, on where payment and cardholder data are processed or stored, or on any subprocessor list, so nothing on these pages evidences EU-based processing. 2 7
The Payments Engineer
The independently sourced sovereignty record shows no attributes, and we found no public information on where payment or cardholder data is processed, on the contracting entity's licence, or on subprocessors and their locations. The only territorial statement captured is that feature licensing applies to Germany, Switzerland, Liechtenstein and Austria. 7
The Compliance Officer
Nothing is on record: I found no public information on where transaction and cardholder data are processed or stored, no subprocessor list with locations, and no data processing agreement showing where the provider acts as controller rather than processor. Given how many third-party acquirers and processors the method pages route through, this silence leaves the outsourcing risk wholly unassessable; the captured pages show only a Worldline group tagline. 2 7
The Skeptic
The captured pages give nothing on this: we found no public information on where payment and cardholder data are processed or stored, no subprocessor list, and no EU-licensed contracting entity with a stated safeguard. The documentation is built around Switzerland and its neighbours, with nothing that lets an EU merchant place their data. 2 7
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
There are no public prices anywhere in the captured material; the licensing page itself says pricing questions go to "your account manager or our sales team", and upselling is likewise a sales conversation. I cannot compute an effective fee for our mix of cards and countries from anything published. Every rate here is a negotiation, and that is a zero from me. 7
The E-Commerce Lead
No public prices at all: the licensing page's answer to pricing questions is "please contact your account manager or our sales team", and even adding features is flagged as an upselling conversation with sales. With licence tiers named but unpriced, I cannot estimate an effective rate for any card, country or method mix without a negotiation. 7 8
The SaaS Founder
Pricing is explicitly a sales conversation: the licensing page says to contact the account manager or sales team with any questions about licensing and pricing, and upselling options are quoted the same way. With no published rate for any method, I cannot compute an effective fee for my card and country mix at all. 7
The Payments Engineer
The captured licensing page routes every money question to sales — "if you have any questions about Saferpay licensing and/or pricing, please contact your account manager or our sales team" — and the upselling note likewise says to ask your contact. No rate of any kind appears publicly, so an effective fee for a given card and country mix cannot even be started from these pages. 7
The Compliance Officer
Pricing is explicitly not publicly listed — the pages direct all licensing and pricing questions to the account manager or sales team, and an upselling option is available by asking the sales contact. A merchant cannot compute any effective fee from the public pages; only the licence tier structure and its feature sets are visible. 7
The Skeptic
No public prices exist — the licensing page itself directs pricing questions to the account manager or sales team, and upselling is likewise a sales conversation. A merchant cannot even begin to compute an effective fee from public pages, and the headline-versus-effective gap is unknowable rather than merely unexplained. 7
Questions about Saferpay
Is Saferpay European?
Not determined: the vendor’s pages as captured do not say where Saferpay is based.
Where does Saferpay store data?
Not stated on the vendor’s pages as of 13 Oct 2026.
Does Saferpay have a free plan?
Not stated on the vendor’s pages as of 13 Oct 2026.
What are the best alternatives to Saferpay?
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: Saferpay 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 found no public information on pricing on the pages we read (docs.saferpay.com/home/integration-guide/payment-methods, docs.saferpay.com/home/master/payment-methods-and-acquirers, docs.saferpay.com/home/integration-guide/general-information/psd2, docs.saferpay.com/home/integration-guide/general-information/3d-secure, docs.saferpay.com/home/integration-guide/licences-and-interfaces/transaction-interface/recurring-payments, docs.saferpay.com/home/master/reconciliation and 2 more). If the vendor publishes it somewhere else, send us the page. Know more? Tell us
- We found no public information on compliance on the pages we read (docs.saferpay.com/home/integration-guide/payment-methods, docs.saferpay.com/home/master/payment-methods-and-acquirers, docs.saferpay.com/home/integration-guide/general-information/psd2, docs.saferpay.com/home/integration-guide/general-information/3d-secure, docs.saferpay.com/home/integration-guide/licences-and-interfaces/transaction-interface/recurring-payments, docs.saferpay.com/home/master/reconciliation and 2 more). If the vendor publishes it somewhere else, send us the page. Know more? Tell us
- 19 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
Sources (8)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Payment methods & local coverage — found from sitemap docs.saferpay.com Checked 13 Oct 2026 Details →
- 2 Payment methods & local coverage — found from sitemap docs.saferpay.com Checked 13 Oct 2026 Details →
- 3 Checkout, SCA & fraud — found from sitemap docs.saferpay.com Checked 13 Oct 2026 Details →
- 4 Checkout, SCA & fraud — found from sitemap docs.saferpay.com Checked 13 Oct 2026 Details →
- 5 Subscriptions & recurring payments — found from sitemap docs.saferpay.com Checked 13 Oct 2026 Details →
- 6 Settlement, reconciliation & API — found from sitemap docs.saferpay.com Checked 13 Oct 2026 Details →
- 7 Licence, risk & account terms — found from sitemap docs.saferpay.com Checked 13 Oct 2026 Details →
- 8 Licence, risk & account terms — found from sitemap docs.saferpay.com Checked 13 Oct 2026 Details →