Payment
SlimPay
Provenance unknown Report an errorPanel rating · 6 judges · How to read the stars
Category median
Sovereignty: 2 of 4 dimensions proven
0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by SlimPay SAS · slimpay.com
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
SlimPay, a French payment institution supervised by the ACPR and registered in the Paris Trade and Companies Register under 518 991 336, is scored by the bench as what the captured pages show: a recurring SEPA collection specialist, part of the Trustly group. Recurring billing is its strongest area at 6–7, crediting electronically signed mandates with bulk import, revocation, IBAN change with history, and export carrying the mandate reference and IBAN. Settlement and reconciliation follows at 5–6 — reconciliation-ready CSV statements, itemised fee lines, a stated 24-hour average payout — with licence and account terms at 4–5 and sovereignty at 5–6. Weakest are payment methods and checkout and SCA at 3–4: the rails on offer are SEPA Direct Debit, SEPA Credit Transfers and open banking in euros only, and the only fraud documentation is transaction monitoring owed under French law. No rate is published, though pricing transparency, scored 1–2, is not counted in the persona-weighted totals, which run 4.3–5.3. Scores land within one point on every criterion, so no sharp split emerged.
Speaks for it
- Recurring billing scored 6–7, the highest band on this bench, on a mandate lifecycle of electronic signature, bulk import, revocation, IBAN change with history, and export carrying the mandate reference and IBAN.
- Reporting is built for reconciliation, with a CSV detailed account statement listing every operation, fee lines coded for direct debits, rejects, returns, refunds and fund transfers, and a documented balance, available-funds and reserve calculation.
- Four checkout integration modes are documented — pop-in, iframe, redirect and an API mode where the merchant builds the interface — with mandate signing combinable with an initial direct debit or payment plan, on a checkout stated as mobile-optimised.
- The regulated entity is fully identified — a licensed French payment institution supervised by the ACPR since 2012, RCS Paris 518 991 336 — with the €300 minimum balance written down as fixed plus variable reserve and no fixed reserve on B2B direct debit.
- Servers are stated to sit entirely within the European Union on AWS, with transfers outside the EU/EEA covered by adequacy decisions or standard contractual clauses, earning sovereignty 5–6.
Held against it
- The documented acceptance is one rail family — SEPA Direct Debit, SEPA Credit Transfers and open banking, euros only — with no public information on cards, wallets or local methods such as iDEAL or Bancontact, and the captured pages give different figures for the covered country count, 36 versus 34.
- We found no public information on webhooks, a test mode, API versioning, idempotency or a public status page, and report automation is configured by support on request.
- Fraud documentation extends only to transaction monitoring required by French law, with no public information on SCA exemption handling, 3-D Secure or merchant-configurable fraud rules.
- We found no public information on safeguarding of merchant funds, termination notice, freeze grounds, a dispute route or the parent Trustly's jurisdiction, and the captured processor list does not show per-processor locations.
- No rate of any kind is published — only the fee categories charged on a monthly invoice and the €300 minimum balance — so an effective fee is a sales conversation.
Best for
- You collect recurring payments in euros across the euro zone by SEPA direct debit and want mandate portability — bulk import of existing mandates and an export carrying the mandate reference and IBAN.
- Your finance team needs reconciliation-grade statements, with every operation listed in CSV, fee lines by named code, and a documented balance, available-funds and reserve calculation.
- You want a French regulated provider — an ACPR-authorised payment institution acting as both processor and acquirer — for account-to-account collection in the euro zone.
- You build your own checkout and want an API mode where you construct the interface around mandate signature and payment orders.
Avoid if
- Your conversion depends on cards, wallets or local methods such as iDEAL or Bancontact, or on settling in currencies other than euros.
- Your data-protection review cannot accommodate a US-headquartered host with CLOUD Act exposure, or the privacy policy's permission for transfers and processing outside the EU/EEA via SlimPay processors and Trustly Group affiliates.
- You need to compute an effective fee from public rates before a sales conversation — only the fee categories, the monthly-invoice mechanics and the €300 minimum balance are published.
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
What they carry is stated precisely — SEPA Direct Debit (Core and B2B), SEPA Credit Transfer and open banking across the entire euro zone, in EUR only — but that is a single rail: we found no public information on cards, wallets, or country-specific local methods such as iDEAL or Bancontact. Coverage of the methods that are offered is clear and per-country naming of the direct debit in France, Spain, Belgium and Germany helps, yet one settlement currency narrows it. 1 3
The E-Commerce Lead
SEPA Direct Debit is named per market under its local names — Prélèvement bancaire in France, Domiciliacion bancaria in Spain, Domiciliation bancaire in Belgium, Elektronisches Lastschriftverfahren in Germany — with coverage stated as the euro zone and euros only, plus open banking via SlimCollect. For a shop selling across Europe, though, we found no public information on cards, wallets, iDEAL, Bancontact, BLIK, TWINT, Przelewy24, EPS, Wero or Klarna, so the methods that decide conversion in most of my markets are unevidenced. 1 3
The SaaS Founder
SEPA Direct Debit is the whole catalogue — Core and B2B, euro-zone coverage of 36 countries named, euros only — and the country and scheme coverage that exists is stated plainly rather than vaguely. But we found no public information on cards, wallets, or country-specific local methods such as iDEAL or Bancontact, and settlement is single-currency. 1 3 4
The Payments Engineer
Coverage is SEPA rails only and single-currency: SEPA Direct Debit Core and B2B, SEPA Credit Transfer and open banking across the euro zone, all in euros, and the captured pages give different figures for the covered country count (36 versus 34). Refund and recurring rules for direct debit are documented per scheme, but we found no public information on cards, wallets, or country-specific local methods such as iDEAL or Bancontact. 1 3 5
The Compliance Officer
Acceptance is documented precisely for account-to-account rails: SEPA Direct Debit Core and B2B with per-market scheme rules and local names, SEPA Credit Transfers and open banking across the euro zone, everything in euros only. We found no public information on card or wallet acceptance, or on country-specific methods such as iDEAL, Bancontact or BLIK. Per-market documentation exists for that single rail rather than a matrix of methods. 1 3 4
The Skeptic
The named list is SEPA Direct Debit, SEPA Credit Transfer and open banking, in euros only, across the euro zone — I found no public information on cards, wallets, or country-specific local methods such as iDEAL, Bancontact or BLIK, so any customer who pays by card is out of scope. Coverage is stated precisely (euro zone, thirty-four-country SEPA, EUR only), which I credit, but the breadth is one scheme family deep and single-currency. 1 3 4
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
Four integration modes are documented — pop-in, iframe, redirect and a full API where the merchant builds the interface — and the checkout is optimised for mobile, which beats a single redirect page. But fraud screening appears only as legally mandated transaction monitoring, and we found no public information on exemption handling, PCI scope, or declined-payment handling beyond a listed automatic-retry feature. 6 2 1
The E-Commerce Lead
Four integration modes including an iframe that embeds the signing flow into my page and an API mode where I build my own interface are exactly what I want for conversion, and it is stated to be mobile-optimised. But we found no public information on 3-D Secure, SCA exemptions, PCI DSS scope or merchant-configurable fraud rules; the only fraud reference is legally required transaction monitoring, so I cannot see how legitimate payments are kept from failing. 1 2 5 6
The SaaS Founder
Four integration modes — pop-in, iFrame, redirect and an API mode where I build my own UI — plus a checkout that combines mandate signature with a contract signature is genuinely flexible for onboarding. But the only fraud documentation is legally mandated transaction monitoring, and we found no public information on 3-D Secure, SCA exemptions, PCI scope or anything about keeping legitimate payments from failing. 6 5 2 1
The Payments Engineer
Four checkout integration modes are documented, including an API mode where the merchant builds their own interface around mandate signature and payment orders, plus mobile-optimised mandate and document e-signature scenarios. We found no public information on SCA exemption handling, declined-payment handling, or merchant-configurable fraud screening — the only fraud statement is atypical-transaction monitoring as a legal obligation. 2 5 6
The Compliance Officer
Four integration modes are documented — pop-in, iframe, redirect and an API mode where the merchant builds the interface — with mandate signing combinable with an initial payment or payment plan, plus mobile optimisation and an automatic retry feature. We found no public information on SCA exemption handling, merchant-configurable fraud rules, or the compliance scope attaching to each integration mode; the only monitoring described is the transaction monitoring imposed by French law. 1 2 5 6
The Skeptic
Four documented checkout modes — pop-in, iframe, redirect with white-label option, and full API control — plus mandate-with-document signing scenarios and a verified IBAN collected from the bank is more than a bare redirect page. But I found no public information on 3-D Secure, SCA exemption handling, merchant-configurable fraud rules or PCI DSS scope, and the only fraud statement in the captures is transaction monitoring owed under French anti-money-laundering law — a duty SlimPay owes its supervisor, not conversion protection for the merchant. 2 5 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
Recurring SEPA collection is the heart of the product: mandate signature by link or delegation, import of existing mandates with compliance validation, revocation, IBAN changes with history, export files carrying the mandate reference and IBAN, and payment plans with an initial direct debit, plus automatic retry. We found no public information on trials, proration, dunning workflows, or a stated format and timeline for moving mandates to another provider. 8 5 1
The E-Commerce Lead
This is the vendor's heart: recurring SEPA debits on electronically signed mandates, payment plans coupled to mandate signature, automatic retry, bulk import of existing mandates, and a mandate export file carrying the mandate reference and IBAN — effectively credentials that can arrive and leave. What I could not find is any card-on-file capability, dunning with recovery measurement, trials or proration, or pre-notification handling. 1 5 8
The SaaS Founder
Mandate lifecycle is first-class: electronic signature, bulk import of existing mandates, revocation, IBAN edits with history, and a downloadable export carrying the mandate reference, IBAN and status — for SEPA that is the portability that keeps my customer base mine. But retries are a single feature line called Automatic Retry with no dunning programme or recovery numbers, and we found no public information on trials, proration or plan changes. 1 8 5 3
The Payments Engineer
Recurring direct debit is the core product: electronically signed SEPA mandates, one-off or recurring debits, payment plans, automatic retry, and mandate management deep enough to include bulk import, revocation, IBAN change with history, and an export file carrying the mandate reference and IBAN. We found no public information on subscription logic such as trials, proration or dunning with measurable recovery, or on a documented process and timeline for moving mandates to another provider beyond that export file. 1 5 8
The Compliance Officer
This is the heart of the product: electronically signed SEPA mandates created by link, delegation or operator, import of existing mandates including bulk import, export carrying the mandate reference and IBAN, revocation, IBAN changes with history, plus payment plans, scheduled recurring debits and automatic retry. We found no public information on dunning depth or recovery measurement, trials and proration on plan changes, mandate pre-notification, or card-on-file handling, account updater services and card token portability. 1 5 7 8
The Skeptic
Mandates are the core product and it shows: electronic signature combined with contract signing, one-off and recurring direct debits, payment plans, import of existing mandates with compliance validation, bulk import, export carrying the mandate reference and IBAN, revocation and IBAN change with history, plus a named automatic retry. I found no public information on pre-notification, dunning detail, or subscription logic such as trials and proration, and no card-on-file capability is evidenced — coherent for an account-to-account specialist, but plan management beyond a passing mention of payment plans is not shown. 1 5 8
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
Payout time is stated as a 24-hour average, and the reporting is genuinely built for reconciliation: a CSV equivalent of a detailed account statement listing every operation with fee lines itemised by type (direct debits, rejections, returns, refunds, fund transfers) and a published balance, available-funds and reserve calculation. We found no public information on webhooks, a test mode, configurable payout schedules, or a public status page. 1 9 10 7
The E-Commerce Lead
Payout time is stated as a 24h average, the CSV account statement lists every operation with fee line items — direct debits, rejections, returns, refunds and fund transfers each carrying their own fee code — and reporting can be automated to a schedule. Missing for a finance team building processes: we found no public information on webhooks, a test mode, a versioned API, or a public status page, and settlement is euros only. 1 8 9 10
The SaaS Founder
Reporting is the strong suit: a CSV account-statement equivalent with per-transaction columns, fee lines split by nature (direct debit, reject, return, refund, fund transfer), R-transaction files, and a balance summary spelling out available funds as balance minus reserve minus pendings — on a 24-hour average payout with a documented Dev Center API. But we found no public information on webhooks, a test mode, payout configurability or a status page, which a finance team needs before building on it. 9 10 1 8
The Payments Engineer
A 24-hour average payout time is stated, and reporting is real: CSV statements equivalent to a detailed account statement, mandate reports, R-transaction files, per-transaction columns including an initial-transaction reference, and fee lines broken out by type on the payment account. We found no public information on webhooks, a test mode, API versioning or idempotency, rate limits, configurable payout schedules, or a status page with incident history — the Dev Center is referenced but none of that appears in the captured pages. 1 9 10
The Compliance Officer
Payout is stated as a 24-hour average and reporting is genuinely reconciliation-ready: a detailed CSV account statement listing every direct debit, transfer and fee line — with fee codes for direct debits, rejects, returns, refunds and fund transfers — and a balance, available-funds and reserve arithmetic a finance team can follow. We found no public information on webhooks, a test mode, API versioning, idempotency or a status page, and report automation is configured by support on request rather than self-served. 1 8 9 10
The Skeptic
Payout is stated as a 24-hour average, fees are itemised by named code — direct debits, rejects, returns, refunds, fund transfers — and appear as separate lines in a CSV account statement the provider itself describes as built for reconciliation, with balance, available funds and reserve laid out and report automation available on request. I found no public information on webhooks, a test mode, API versioning or a status page, and settlement is euro-only on a fixed 24-hour average rather than configurable schedules. 1 9 10
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 regulated entity is named with its supervisor (the ACPR), its licence type as a payment institution, and its Paris company register number, and the reserve is written into the product documentation — a €300 minimum of fixed plus variable coverage, with no fixed reserve for SEPA B2B, which is exactly the kind of number I want in writing. We found no public information on safeguarding of merchant funds, termination notice periods, freeze terms, or a chargeback dispute route. 1 2 3 9
The E-Commerce Lead
SlimPay SAS is named with its Paris registration number and registered office, its payment-institution licence and ACPR supervision are stated along with its acquirer role, and the reserve is written down concretely — a €300 minimum balance made of a fixed and variable part, with no fixed reserve for B2B direct debits. We found no public information on safeguarding of merchant funds, chargeback fee amounts, a dispute process, termination notice periods or freeze terms. 1 2 3 10
The SaaS Founder
SlimPay SAS is named with its Paris registry number, ACPR supervision and authorised payment institution status, and the reserve is actually defined — a €300 minimum balance of fixed plus variable reserve, with no fixed reserve on B2B direct debit. But we found no public information on safeguarding of merchant funds, a dispute process, chargeback fee amounts or a termination notice period. 2 9 3 10
The Payments Engineer
The regulated entity is fully named — a French company with a Paris trade register number, authorised as a payment institution and supervised by the ACPR — and reserves are described concretely with a €300 minimum-balance coverage of fixed plus variable parts, with no fixed reserve for B2B direct debit. We found no public information on termination notice, freeze conditions, a dispute process, safeguarding of merchant funds, or a complaint route to the supervisor. 1 2 10
The Compliance Officer
The regulated entity is properly identified: SlimPay, a French limited company at 12 rue Godot de Mauroy 75009 Paris, registered in the Paris trade and companies register under 518 991 336, authorised and supervised by the ACPR as a payment institution acting as processor and acquirer, with reserve mechanics written down as a €300 minimum balance of fixed and variable parts. We found no public information on safeguarding of the merchant funds held on the SlimPay payment account, termination notice or freeze grounds and a route to appeal, passporting per country, or a published attestation level. 1 2 9 10
The Skeptic
The regulated entity is named and real — SlimPay, a French payment institution authorised and supervised by ACPR, registered in Paris under number 518 991 336, acting as both processor and acquirer since 2012 — and the reserve is actually defined: a €300 minimum balance of fixed plus variable coverage held against rejected payments, with no fixed reserve for B2B direct debit. What I did not find is the bad-day paperwork: no safeguarding statement, no ACPR register number, and no published freeze, termination, notice-period or dispute terms at all. 1 2 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
An EU contracting and regulated entity, with servers stated as located entirely within the EU on AWS and transfers outside the EEA covered by adequacy decisions or standard contractual clauses. The parent is Trustly and group affiliates may process data outside the EU; we found no public information on the parent's jurisdiction, and the captured processor list is truncated so processor locations are not shown. 2 1
The E-Commerce Lead
The contracting entity is French and ACPR-licensed, servers are stated to be located entirely within the European Union on named AWS infrastructure, and any transfer outside the EU/EEA is covered by standard contractual clauses or an adequacy decision. But the data processor list is referenced rather than shown with locations, the host is a US-headquartered provider, and we found no public information on a data processing agreement separating processor and controller roles. 1 2
The SaaS Founder
A French entity under ACPR, servers stated as located entirely in the EU on Amazon Web Services, a published data-processor list and SCC-or-adequacy coverage for any transfer make the core European. But the same policy permits transfers to Trustly Group affiliates and processors outside the EU, a US-headquartered host brings CLOUD Act exposure, and the processor list locations are not enumerated in what we captured. 2 1
The Payments Engineer
A French entity under ACPR supervision, servers stated to sit entirely in the EU on named infrastructure (Amazon Web Services), GDPR and French data-protection-law commitments, transfers outside the EU/EEA only under adequacy decisions or standard contractual clauses, and a published data-processor list with processor contracts in place. The parent is named as Trustly but its jurisdiction is not stated in the captured pages, the processor-list excerpt is truncated so per-processor locations are not shown, and the US-headquartered host carries CLOUD Act exposure, which keeps this short of the top of the scale. 1 2 3
The Compliance Officer
The contracting and regulated entity is French, servers are stated to sit entirely within the EU on Amazon Web Services, and transfers outside the EU/EEA are covered by adequacy decisions or standard contractual clauses. SlimPay declares itself Data Controller for this processing and names BNP Paribas as a separate controller, yet we found no public information on the identities and locations of the processors behind the published list link, on where the parent Trustly sits, or on an agreement separating processor from controller roles — and a US-headquartered host leaves CLOUD Act exposure despite EU servers. 1 2
The Skeptic
An EU entity under an ACPR licence contracts, servers are stated to be located entirely within the European Union on named infrastructure (Amazon Web Services), and any transfer outside the EU/EEA is covered by adequacy decisions or standard contractual clauses. But the privacy policy itself permits processing in non-EU countries via SlimPay processors and Trustly Group affiliates, the host is US-headquartered with the CLOUD Act exposure that carries, and the data processor list is referenced but no named processors or locations are evidenced — the parent group's ownership is not documented here either. 1 2
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
We found no published rate, percentage or fee amount of any kind — the only public pricing disclosure is that fees are applied to the payment account and set out on a monthly invoice, with the fee categories named for direct debits, rejections, returns, refunds and fund transfers. A merchant cannot compute an effective fee from public pages; every rate is a sales conversation. 9 10
The E-Commerce Lead
No rate of any kind is public: the pages show only that fees are applied to the payment account and arrive on a monthly email invoice, with fee categories coded for direct debits, rejections, returns, refunds and fund transfers, and a €300 minimum balance stated. A merchant cannot compute an effective cost for their own mix from these pages; every actual price is a sales conversation. 9 10
The SaaS Founder
No rate of any kind is public — only the fee categories (per direct debit, reject, return, refund and fund transfer), the mechanics of a monthly invoice, and a published €300 minimum balance. I cannot compute an effective fee for any volume mix from these pages. 9 10
The Payments Engineer
The only public pricing facts are mechanical: fees are taken on the SlimPay payment account, invoiced monthly by email, and exist in named categories for debits, rejects, returns, refunds and fund transfers, alongside a stated €300 minimum balance. We found no public information on any rate or fee amount, monthly fee or contract term, so an effective fee for a merchant's volume is not computable from the captured pages. 9 10
The Compliance Officer
We found no public rates on the captured pages — no percentage, per-transaction amount, monthly fee or payout fee figure. The only published cost structure is the fee taxonomy charged to the SlimPay payment account (direct debits, rejects, returns, refunds, fund transfers) on a monthly invoice, plus the €300 minimum balance, so an effective fee for a given mix cannot be computed from public information. 9 10
The Skeptic
Not one rate appears anywhere I can see: I found no public information on the direct debit fee, the reject fee, the return fee, the refund fee or the fund transfer fee — only their existence as five named fee codes charged to the payment account on a monthly email invoice. The sole figure published is a €300 minimum balance coverage; for a mid-market and enterprise sales motion the effective cost of a merchant's own mix is a sales conversation, not a computable number. 9 10
European sovereignty — proven facts
2 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 | — | uncited Report an error |
|---|---|---|---|
| Ownership | Not determined | — | uncited Report an error |
| Data residency | EU only ⚠ unverified | 3/3 pts | 2 Report an error |
| Subprocessors | US CLOUD Act reach ⚠ unverified | 0/2 pts | 2 Report an error |
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 29 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 — Data residency. The same section permits personal data to be transferred to and processed in countries outside the EU/EEA via SlimPay data processors and Trustly Group affiliates, so EU location is the stated default but not exclusive.
- Weak sourcing — Subprocessors. AWS is a US-headquartered provider, so CLOUD Act exposure exists even though the stated servers are EU-located, and the excerpt truncates section 5.3 (SlimPay Data Processors), so further processors may exist but are not named.
- 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.
- 4 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
- 2 compliance 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 legal 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 subprocessors 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
Sources (10)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor page slimpay.com Checked 29 Sep 2026 Details →
- 2 Privacy policy — found from the homepage www.slimpay.com Checked 30 Sep 2026 Details →
- 3 Payment methods & local coverage — found from sitemap support.slimpay.com Checked 1 Oct 2026 Details →
- 4 Payment methods & local coverage — found from sitemap support.slimpay.com Checked 1 Oct 2026 Details →
- 5 Checkout, SCA & fraud — found from sitemap support.slimpay.com Checked 1 Oct 2026 Details →
- 6 Checkout, SCA & fraud — found from sitemap support.slimpay.com Checked 1 Oct 2026 Details →
- 7 Subscriptions & recurring payments — found from sitemap support.slimpay.com Checked 1 Oct 2026 Details →
- 8 Subscriptions & recurring payments — found from sitemap support.slimpay.com Checked 1 Oct 2026 Details →
- 9 Settlement, reconciliation & API — found from sitemap support.slimpay.com Checked 1 Oct 2026 Details →
- 10 Settlement, reconciliation & API — found from sitemap support.slimpay.com Checked 1 Oct 2026 Details →