Payment
PAYONE
EU-Made Report an errorPanel rating · 6 judges · How to read the stars
Category median
Sovereignty: 1 of 4 dimensions proven
0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by PAYONE GmbH · www.payone.com
Compare with Mollie → Compare with Unzer → Report an error on this page Is this your product? →
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
PAYONE, a Frankfurt payment provider supervised by BaFin as an e-money institution and owned by Worldline and the DSV-Gruppe, drew scores from 3 to 7. Checkout and SCA is the strength at 6-7: the Exemption Engine is documented with unusual concreteness — 30 € and 100 € low-value limits, acquirer transaction risk analysis, automatic soft-decline recovery, merchant liability for fraudulent exemptions — alongside hosted checkout, server-to-server integration, webhooks and a test environment with documented test cases. Recurring billing spreads from 4 to 6: SEPA mandate machinery (creation, reuse, revocation endpoint, 36-month lifecycle, eight-week contestation window) is documented in depth, while the judges found no public information on subscription plans, dunning or exporting stored credentials. Payment methods sits at a flat 4 — 'alle gängigen Bezahlverfahren' with only the Klarna family and SEPA Direct Debit named by country. Weakest are pricing transparency at a flat 3, with the Disagio in '0,99 € + Disagio' and 'ab 0,09 € + Disagio' never quantified, and settlement and reconciliation at 3-4, where payout pages carry question headings without values.
Speaks for it
- Checkout and SCA scores 6-7 on a publicly documented Exemption Engine — 30 € and 100 € low-value limits, acquirer transaction risk analysis, automatic soft-decline recovery and stated merchant liability.
- SEPA mandate handling is documented in depth — separate creation, reuse for card-on-file, a dedicated revocation endpoint, automatic revocation after 36 months and an eight-week contestation period for valid mandates.
- The regulated entity is fully identified on the imprint — PAYONE GmbH, admitted and supervised by BaFin as an E-Geld-Institut, with register entry HRB 116860 and ownership by Worldline and the DSV-Gruppe.
- The developer platform offers hosted checkout and server-to-server modes, webhooks and a test environment with documented test cases.
- E-commerce package fees are published — Starter with '49,00 € einmalige Einrichtungsgebühr' and '0,00 € monatliche Grundgebühr', Pro with '99,00 €' setup and 'ab 19,00 € pro Monat'.
Held against it
- Pricing transparency scored a flat 3 — the Disagio in '0,99 € + Disagio' and 'ab 0,09 € + Disagio' is not quantified on the captured pages, and no cross-border, currency-conversion or chargeback fee figures are public.
- Payout information appears only as FAQ topic headings — timing, cycle changes, limits and fees — with no cadence, delay or values stated, and no public information on per-transaction fee itemisation or payout-to-transaction reports.
- Payment method coverage, scored a flat 4, rests on the homepage's 'alle gängigen Bezahlverfahren' — only the Klarna family and SEPA Direct Debit are documented with country and currency lists, and the judges found no public information on Apple Pay, Google Pay, iDEAL or Bancontact.
- The judges found no public information on where transaction and cardholder data are processed or stored, and the published recipient list covers website analytics, marketing and hosting rather than the payment chain.
- Recurring support stops at the mandate layer, with no public information on subscription plans, trials, proration, dunning, smart retries or exporting stored payment credentials to another provider.
Best for
- You run a DACH subscription or recurring business whose core need is SEPA Direct Debit mandate machinery, with creation, reuse and revocation handled through a documented API.
- You must contract with a named, supervised European entity — a BaFin-licensed German company whose group companies are stated to sit within the EU/EEA — to satisfy procurement.
- Your engineering team values a publicly documented integration with a test environment, webhooks and an engineered SCA exemption strategy whose limits and liability are written down.
Avoid if
- You need to model your effective per-transaction cost before signing — the Disagio component of the published transaction fees is not quantified, so an effective fee cannot be computed from public pages.
- You are expanding across multiple European markets and need named local methods or wallets per country — method-level coverage is documented only for the Klarna family and SEPA Direct Debit.
- Your finance team must close the month from the provider's payout data — settlement and reconciliation scored 3-4 and the payout pages carry question headings without values.
- You expect the provider to run subscription lifecycle logic — plans, trials, proration, dunning — rather than building it yourself, since documented recurring support stops at the mandate layer.
The scores
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 homepage sells "alle gängigen Bezahlverfahren" without naming anything, while the developer pages do better: Klarna's methods come with a twelve-country list and seven currencies, and SEPA Direct Debit with its scheme countries and mandate flow. We found no public information on wallets such as Apple Pay or Google Pay, on iDEAL, Bancontact or EPS, or on refund and recurring support stated per method beyond Klarna and SEPA. 1 6 7 8
The E-Commerce Lead
The developer pages name the Klarna family with twelve countries and seven currencies, SEPA Direct Debit with its country list, and girocard terms, while American Express, MasterCard and Visa appear by name only in the exemption documentation. The homepage's "alle gängigen Bezahlverfahren" is exactly the vague count-claim I distrust, and we found no public information on iDEAL, Bancontact, BLIK, TWINT, EPS, Wero or wallet coverage named per market. Two methods documented with country lists is real work, but it is not a matrix I can plan eight markets against. 1 5 6 7
The SaaS Founder
SEPA Direct Debit and Klarna are documented with real per-method detail — country lists and currencies, down to instalment and B2B variants — which is what I plan mandates against in the DACH region. But the headline pitch stops at 'all common payment methods' plus cards and contactless, and I found no public information on Apple Pay, Google Pay, iDEAL, Bancontact or other named local methods. Cards surface only indirectly through the exemption engine's American Express, Mastercard and Visa references. 1 6 7
The Payments Engineer
Cards appear only as a generic claim ("alle gängigen Bezahlverfahren, Kredit-/Debitkarten") while the two documented methods — SEPA Direct Debit and the full Klarna family — are properly detailed per country and currency, including refund behaviour. We found no public information naming Apple Pay, Google Pay, iDEAL, Bancontact or Wero, so a merchant cannot plan per-market coverage beyond those two. 1 6 7
The Compliance Officer
The homepage promises "alle gängigen Bezahlverfahren" without naming them, while the developer documentation names Klarna's variants with twelve countries and seven currencies, and SEPA Direct Debit with its own country list; girocard participation terms exist as a download, which hints at German debit coverage. We found no public information on Apple Pay, Google Pay, iDEAL, Bancontact, BLIK or TWINT with the countries they cover, so a merchant cannot plan per-market coverage from these pages. 1 5 6 7
The Skeptic
SEPA Direct Debit and the Klarna suite are documented method by method with their countries and currencies, and the cards appear by name in the security pages; but the homepage still sells 'alle gängigen Bezahlverfahren' with no list, we found no public information on Apple Pay, Google Pay, iDEAL, Bancontact or other local methods named per country, and the SEPA country list is cut off behind a 'Show all' control. 1 6 7
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 exemption documentation is the best part of this file: low-value thresholds, acquirer transaction risk analysis, soft-decline recovery and who is liable when an exemption turns fraudulent are all written down, with hosted and server-to-server integration modes and a low-PCI claim. We found no public information on network tokens, an account updater, authorisation-rate reporting, or fraud rules and risk scores exposed to the merchant — the fraud modules are only named. 6 7 8
The E-Commerce Lead
The exemption documentation is the strongest thing here: the engine decides per transaction whether to challenge, low-value exemption rules with the 30€ and 100€ figures are written down, acquirer TRA and soft-decline recovery are explained, and the merchant-liability caveat is stated plainly, with Hosted Checkout Page and server-to-server both documented. But we found no public information on a checkout I could run in my own domain, on PCI DSS scope per integration type beyond a "Low PCI requirements" marketing line, on fraud rules or risk scores exposed to me, or on authorisation-rate reporting. That lands between the anchors, above a basic hosted page, short of a fully engineered authorisation story. 6 7 8
The SaaS Founder
The exemption strategy is engineered and public: low-value exemptions with the 30 € and 100 € limits and the five-consecutive rule, acquirer transaction risk analysis, automatic skip or rollout of 3-D Secure per transaction, and automatic Soft Decline recovery when frictionless is refused — with merchant liability for exemptions written plainly. Hosted Checkout Page and server-to-server modes, webhooks and a test environment with documented test cases are there too. I found no public information on an embedded checkout, network tokens or account updater, or authorisation-rate reporting, and PCI scope is only promised as 'Low PCI requirements'. 6 7 8
The Payments Engineer
Hosted checkout and server-to-server modes, webhooks, a test mode with documented test cases, and an exemption engine with real engineering in it: low-value exemptions with the 30€ and 100€ limits, acquirer transaction risk analysis, automatic soft-decline recovery, and liability spelled out. We found no public information on PCI scope per integration type (only a "Low PCI requirements" benefit), merchant-facing risk scores, or network tokens and account updater. 6 7 8
The Compliance Officer
The Exemption Engine is documented in unusual depth — low-value exemptions below 30 €, acquirer transaction risk analysis, automatic soft-decline recovery and merchant liability for fraudulent exemptions are all stated — and hosted checkout plus server-to-server with a test environment, webhooks and documented test cases are available. Card-on-file transactions are explicitly out of the engine's scope, and we found no public information on an embedded checkout at reduced PCI scope, network tokens, an account updater or authorisation-rate reporting. 6 7 8
The Skeptic
The Exemption Engine documentation is unusually concrete: low-value exemptions with the 30 and 100 euro limits, acquirer transaction risk analysis, 3-D Secure rolled in or out per transaction, and automatic soft-decline recovery, with liability written down — the merchant stands the cost of a fraudulent exemption. We found no public information on network tokens, an account updater, authorisation-rate reporting by issuer country, or the PCI DSS scope per integration type. 6 7 8
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
SEPA mandates are handled as a first-class product — creation, reuse, a dedicated revocation endpoint, a 36-month lifecycle and recurring charges for an indefinite number of transactions are all documented, plus an 8-week contestation window on valid mandates. But that is where it ends: we found no public information on subscription plans with scheduled charges, dunning or retries, an account updater, or any process for exporting stored credentials to another provider. 7 8 10 11
The E-Commerce Lead
SEPA mandates are handled as a real product: separate CreateMandate and RevokeMandate endpoints, mandate reuse for card-on-file, recurring mandates valid for an indefinite number of subsequent transactions, a 36-month lifecycle, an 8-week contestation period for valid mandates, plus recovery guidance for failed direct debits. What I cannot see is any subscription logic — plans, scheduled charges, trials, proration, smart retries or dunning — and we found no public information on exporting stored payment credentials to another provider. The rails are there; the billing brain is undocumented. 7 10 11
The SaaS Founder
Mandate management is the strongest piece: a separate mandate-creation route, reuse of an existing mandate reference for card-on-file, a RECURRING mandate valid for an indefinite number of subsequent transactions, a dedicated revoke endpoint, automatic revocation after 36 months, and a contestation period cut to 8 weeks for valid mandates. I found no public information on dunning with smart retries, subscription logic such as trials, proration or plan changes, a card account updater — and, most critically for me, any documented process for exporting payment tokens to another provider. Failed-SEPA guidance exists, but recovery looks left to the merchant. 7 8 10
The Payments Engineer
The SEPA mandate machinery is real — separate mandate creation, reuse of an existing mandate, a dedicated revocation endpoint, automatic revocation after 36 months, and a recurring mandate valid for an indefinite number of subsequent charges. We found no public information on subscription plans with scheduled charges, dunning or smart retries, and card-on-file is mentioned only in passing in the 3-D Secure context. 7 8
The Compliance Officer
SEPA mandate handling is first-class: mandate creation via three API paths, a dedicated revocation endpoint, a 36-month mandate lifecycle, recurring validity for an indefinite number of subsequent transactions, and reuse of existing mandates including card-on-file, with an eight-week contestation period for valid mandates. We found no public information on subscription plan logic such as trials or proration, on dunning and smart retries, or on exporting stored payment credentials to another provider, so recurring support stops at the mandate layer. 7 10 11
The Skeptic
SEPA mandate handling is first-class: dedicated create and revoke endpoints, mandates valid for an indefinite run of subsequent transactions, a reduced eight-week contestation window, and webhook codes for declines. But we found no public information on subscription plans with scheduled charges, proration, smart retries or dunning, a card account updater, or any documented process for exporting stored credentials to another provider. 7 10 11
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
The payouts help pages read as a list of unanswered questions — viewing payouts, timing, changing the cycle, limits and fees — with no payout cadence, delay or figures stated anywhere I could find, and nothing on per-transaction fee itemisation or reports linking a payout to its transactions. The developer API with webhooks, documented status codes and a real test environment is what lifts this above the bare minimum. 7 10 12 13
The E-Commerce Lead
The payout FAQs list the right questions — timing, cycle changes, missing transactions, limits and fees — but the captured pages give no cadence, delay or fee values for any of them, and we found no public information on per-transaction fee breakdowns or reports that tie a payout to its transactions. The API side is more solid, with documented endpoints, webhooks and a test environment with test cases. Finance could integrate; finance could not close a month from this. 7 12 13
The SaaS Founder
The developer side is real — documented endpoints, webhooks and a test environment with test cases — but the finance side is opaque to me: payouts appear as FAQ topics ('When will I receive my payouts?') with no cadence or delay stated on the captured pages, and payout limits or fees are a question without values. Transaction pricing reads 'ab 0,09 € + Disagio' with no visible breakdown of the Disagio, and I found no public information on per-transaction fee itemisation, payout-to-transaction reconciliation reports, accounting exports, API versioning or idempotency. 2 7 12 13
The Payments Engineer
The developer side is buildable — named payment endpoints, webhooks, documented status codes with a finality rule, and a test environment — but payouts are covered only by FAQ topic headings on timing, cycle changes and limits with no values stated. We found no public information on payout frequency or delay, per-transaction fee breakdowns, reconciliation exports that match bank lines, API versioning, idempotency or a public status page with incident history. 6 7 12 13
The Compliance Officer
The developer platform documents an API with webhooks and a test environment, and the help centre addresses payout timing, changing the payout cycle, and payout limits and fees as topics, but the captured pages state no actual payout frequency, delay or fee values. We found no public information on per-transaction fee breakdowns, reports linking payouts to their transactions, or reconciliation exports that match bank lines. 6 7 12 13
The Skeptic
The developer pages show a documented API with webhooks, a test environment and test cases, but the captured payout pages are a list of unanswered questions — 'When will I receive my payouts?', 'Are there limits or fees for withdrawals?' — with no payout schedule or delay stated, no fee itemisation per transaction, and no report linking a payout to its transactions in evidence. 7 12 13
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 imprint names PAYONE GmbH in Frankfurt as a BaFin-supervised e-money institution with a commercial register entry, and the terms page carries the full AGB set including girocard and factoring conditions plus an online cancellation route. What I cannot find is what matters on a bad day: safeguarding of merchant funds, chargeback fee figures and a dispute process, notice periods for termination, and any reserve or rolling-hold conditions with limits. 1 4 5
The E-Commerce Lead
The imprint does the basics properly: PAYONE GmbH in Frankfurt, admitted and supervised by BaFin as an E-Geld-Institut, commercial register HRB 116860, VAT ID, downloadable terms including girocard and factoring conditions, and an online contract termination option. We found no public information on safeguarding of merchant funds, reserve or rolling-hold limits, freeze and termination notice periods, or chargeback fee amounts beyond FAQ topics. The licence is named; the bad-day rules are not on the captured pages. 4 5 10
The SaaS Founder
The regulated entity is fully named: PAYONE GmbH, Frankfurt am Main, licensed and supervised by BaFin as an E-Geld-Institut, registered at Amtsgericht Frankfurt under HRB 116860 — that part is solid. I found no public information on safeguarding of merchant funds, reserve or rolling-hold limits with release timelines, chargeback fees, a notice period for ordinary termination, or the PCI DSS level; chargebacks appear only as FAQ guidance and termination as a self-service link. The bad-day terms are not written down where I can check them. 4 5 10
The Payments Engineer
The legal notice names the entity, supervisor and licence type precisely — PAYONE GmbH, admitted and supervised by BaFin as an e-money institution — with commercial register and VAT details. The terms exist only as downloads whose contents are not captured, and we found no public information on safeguarding of merchant funds, reserve or hold conditions, termination notice periods, or chargeback fees and a dispute process. 4 5
The Compliance Officer
The imprint does what I always ask for: PAYONE GmbH is named as an E-Geld-Institut admitted and supervised by BaFin, with commercial register entry HRB 116860 at Amtsgericht Frankfurt am Main and ownership stated as Worldline and the DSV-Gruppe. We found no public information on safeguarding of merchant funds, reserve or rolling-hold conditions, termination notice periods or chargeback fees — only FAQ topics on handling chargebacks, a downloadable PCI DSS page without a stated level, and an online cancellation link. 1 4 5 10
The Skeptic
The imprint names PAYONE GmbH in Frankfurt with its commercial register entry, VAT ID and a BaFin licence as an e-money institution — an identified, supervised entity. We found no public information on safeguarding of merchant funds, chargeback fees, reserve or freeze terms, or the notice period for termination; the general terms exist only as downloads whose contents the captured pages do not show, and no BaFin register number appears. 4 5 10
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
A German contracting entity with a BaFin e-money licence is on the imprint, and the privacy page states all group companies sit within the EU and EEA, with standard contractual clauses or adequacy decisions covering the third-country recipients — which the page says are website analytics, marketing and hosting only. The silence is on the core question: we found no public information on where payment and cardholder data are processed and stored. 3 4 5
The E-Commerce Lead
The contracting chain is European on the vendor's own pages: a Frankfurt entity supervised by BaFin as an e-money institution, owned by Worldline and the DSV-Gruppe, with all group companies seated within the EU/EWR and standard contractual clauses plus adequacy decisions covering third-country recipients. The decisive gap is that we found no public information on where payment and cardholder data are processed and stored, and the published recipient list covers website hosting, analytics and marketing tools rather than the payment chain. European entity, unproven data residency. 3 4
The SaaS Founder
The contracting and regulated entity is German and the ownership is European — Worldline, seat in Paris, and the DSV group per the imprint — with all group companies stated to sit within the EU/EEA and SCCs plus adequacy decisions covering the disclosed third-country transfers, which are website analytics and hosting rather than payment processing. What I found no statement on is where core transaction and cardholder data are processed and stored, and the published subprocessor list covers the website, not the payment chain. For a subscription business handing over every customer's mandate, that silence matters. 3 4
The Payments Engineer
Contracting entity, licence and ownership are European — PAYONE GmbH in Frankfurt, BaFin-supervised, owned by Worldline of Paris and the German savings bank publishing group — and the privacy policy states all group companies sit within the EU/EEA with named subprocessors. We found no public information on where payment and cardholder data are processed and stored; the captured privacy pages cover website, chatbot and marketing data, not the payments platform. 3 4
The Compliance Officer
The contracting and regulated entity is German with a BaFin e-money licence, the parent Worldline is seated in Paris, and the privacy policy states that all group companies are seated within the EU/EWR, with standard contractual clauses and adequacy decisions cited for third-country recipients. What matters most for my file is missing: we found no public information on where transaction and cardholder data are processed or stored, and the published recipient list covers website analytics and hosting rather than the payment-processing chain, so the payment subprocessors remain unnamed. 3 4 5
The Skeptic
A German contracting entity under BaFin supervision, a French parent in Worldline, and a statement that all group companies sit within the EU and EEA — the chain that is named is European. But there is no statement of where payment and cardholder data are processed or stored, and the published subprocessor list covers website analytics, marketing and video tools rather than the payment platform; the independently sourced attributes likewise leave data residency unknown. 3 4
Pricing transparency
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
Setup and monthly fees are published plainly — "49,00 € einmalige Einrichtungsgebühr" with "0,99 € + Disagio" per transaction at Starter, "99,00 €" once and "19,00 € monatliche Grundgebühr" with "ab 0,09 € + Disagio" at Pro — but the Disagio itself is never quantified, the top package is "individuell" throughout, and the captured pages give no figures for payout limits and fees, chargebacks or currency conversion. I cannot compute an effective fee for any card or country mix from what is public. 2 5 13
The E-Commerce Lead
Starter and Pro publish setup fees of "49,00 €" and "99,00 €", a monthly fee of "19,00 €" for Pro, and transaction fees of "0,99 € + Disagio" and "ab 0,09 € + Disagio" — but the captured pages give no figure for the Disagio itself, which is the rate that decides my margin. Chargeback, payout and withdrawal costs appear only as FAQ topics with no values stated, and the further price lists exist only as downloads whose contents are not captured. For my card and country mix the effective fee is not computable from public pages. 2 5 13
The SaaS Founder
Package prices are public and quoted exactly: Starter with '49,00 € einmalige Einrichtungsgebühr', '0,00 € monatliche Grundgebühr' and '0,99 € + Disagio' per transaction; Pro with '99,00 €' setup, 'ab 19,00 € pro Monat' and 'ab 0,09 € + Disagio'; and downloadable price lists exist for the POS tariffs. But the effective fee is unknowable: the captured pages give no breakdown of the Disagio, and I found no public information on cross-border or currency conversion costs, chargeback, refund or payout fees, contract term, or whether the model is blended or interchange++. The Individual package prices every component as 'individuell'. 2 5 13
The Payments Engineer
Plan fees are published plainly — "49,00 € einmalige Einrichtungsgebühr" with a "0,00 € monatliche Grundgebühr" for Starter, "ab 19,00 € pro Monat" for Pro — but the variable cost reads "0,99 € + Disagio" and "ab 0,09 € + Disagio" with the Disagio itself never quantified, so the effective fee cannot be computed. We found no public information on cross-border or currency conversion markups, or chargeback and payout fees; the payout FAQ raises limits and fees without stating values. 2 5 13
The Compliance Officer
Packages are priced publicly — 49,00 € setup for Starter, 99,00 € setup and 19,00 € monthly for Pro, with transaction fees of 0,99 € + Disagio and ab 0,09 € + Disagio — but the Disagio itself, per-method rates, cross-border and currency conversion markups and chargeback fees are not stated on the captured pages. Downloadable price and service schedules exist for the POS tariffs, though their contents are not shown, so a merchant cannot compute an effective fee from what is visible. 2 5 13
The Skeptic
Two e-commerce packages publish setup and monthly fees — '49,00 € einmalige Einrichtungsgebühr', '19,00 € monatliche Grundgebühr' — with per-transaction fees of '0,99 € + Disagio' and 'ab 0,09 € + Disagio', where the Disagio, the card charge itself, is left unquantified in the captured pages. We found no public information on cross-border rates, currency conversion markups, chargeback fees or whether the model is blended or interchange-plus; the price lists exist only as downloads whose contents are not shown. 2 5 13
European sovereignty — proven facts
1 of 4 dimensions provenBuilt only from facts shown on the vendor's own pages. A dimension we could not prove is left open, not scored as zero.
| Legal entity | Not determined ⚠ unverified | — | uncited Report an error |
|---|---|---|---|
| Ownership | Not determined ⚠ unverified | — | uncited Report an error |
| Data residency | Not determined | — | uncited Report an error |
| Subprocessors | US CLOUD Act reach ⚠ unverified | 0/2 pts | 3 Report an error |
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 22 Sep 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- Weak sourcing — Ownership, Legal entity. Not confirmed on the vendor’s own pages as captured.
- Weak sourcing — Subprocessors. Amazon Web Services is disclosed only for Website-Hosting, the Worldline group companies used for IT support are all seated in the EU/EWR, and the remaining US recipients (Google, LinkedIn, Meta, Microsoft, Vimeo) serve website analytics, marketing and video embedding only.
- 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.
- 12 pricing 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
- 2 hosting 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
- 2 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
- 2 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
- 1 compliance fact could not be confirmed on the vendor’s page as captured and was left out of this page and of the panel’s material. Know more? Tell us
- 1 data fact could not be confirmed on the vendor’s page as captured and was left out of this page and of the panel’s material. Know more? Tell us
- 1 product fact could not be confirmed on the vendor’s page as captured and was left out of this page and of the panel’s material. Know more? Tell us
- 2 sovereignty dimensions could not be confirmed on the vendor’s own pages and are shown as unknown. Know more? Tell us
Sources (13)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor homepage www.payone.com Checked 22 Sep 2026 Details →
- 2 Pricing page www.payone.com Checked 22 Sep 2026 Details →
- 3 Privacy policy www.payone.com Checked 22 Sep 2026 Details →
- 4 Legal notice www.payone.com Checked 22 Sep 2026 Details →
- 5 Terms of service www.payone.com Checked 22 Sep 2026 Details →
- 6 Payment methods & local coverage — found from sitemap developer.payone.com Checked 1 Oct 2026 Details →
- 7 Payment methods & local coverage — found from sitemap developer.payone.com Checked 1 Oct 2026 Details →
- 8 Checkout, SCA & fraud — found from sitemap developer.payone.com Checked 1 Oct 2026 Details →
- 9 Checkout, SCA & fraud — found from sitemap developer.payone.com Checked 1 Oct 2026 Details →
- 10 Subscriptions & recurring payments — found from sitemap www.payone.com Checked 1 Oct 2026 Details →
- 11 Subscriptions & recurring payments — found from sitemap www.payone.com Checked 1 Oct 2026 Details →
- 12 Settlement, reconciliation & API — found from sitemap www.payone.com Checked 1 Oct 2026 Details →
- 13 Settlement, reconciliation & API — found from sitemap www.payone.com Checked 1 Oct 2026 Details →