Payment
Scalapay
Provenance unknown Report an error0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by Scalapay S.p.A. · scalapay.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.
Scalapay at a glance
- Vendor
- Scalapay S.p.A.
- Headquarters
- Not stated on the vendor’s pages as of 20 Oct 2026
- Data hosting
- Not stated on the vendor’s pages as of 20 Oct 2026
- Free plan
- Not stated on the vendor’s pages as of 20 Oct 2026
- Panel verdict
- The AI panel rates Scalapay 0.5/5, the mean of 6 judges. Scalapay S.p.A. how scores are made
- As of
- Vendor pages captured 20 Oct 2026; evaluated by the panel 21 Oct 2026. all sources
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
Scalapay S.p.A. is a payment provider whose public evidence is a consumer pay-in-3 product — interest-free for the shopper, funded by Visa, Mastercard and AMEX credit, debit or prepaid cards, online and in-store — plus a documented reporting API. The bench's weight falls on that API: settlement and reconciliation is the strongest criterion, scored 3-4, resting on documented orders, refunds and payouts endpoints, per-payout lookups, bearer-token authentication and pagination to 5,000 items. Payment methods scores cluster at 1-2, with no public statement of which countries and currencies each method covers. Checkout and SCA and recurring billing sit near the floor: the pages show a checkout selection and the shopper's repayment schedule, with no public information on 3-D Secure, SCA exemptions or merchant-initiated transactions. Judges spread on sovereignty and licence and account terms: some credit the Italian corporate form in the vendor's name, others decline to score a hint — no sovereignty attributes are on record, and no supervisor, licence number or safeguarding terms appear. The captured pages publish no prices; persona-weighted totals run 0.8 to 2.0.
Speaks for it
- Settlement and reconciliation is the strongest criterion on the bench, scored 3-4
- The reporting API documents orders, refunds, payouts and per-payout lookups for reconciling bank transactions
- Reporting endpoints specify bearer-token authentication, date filters and pagination to 5,000 items
- The pay-in-3 product is published as interest-free for the shopper, online and in-store
- Signup is published at two minutes with zero documents
Held against it
- No public information on which countries and currencies each payment method covers, or on wallets and local methods
- No public information on 3-D Secure, SCA exemptions, fraud screening or declined-payment handling
- No public information on merchant-side recurring billing — stored credentials, merchant-initiated transactions, SEPA mandates or dunning
- No public information on payout frequency or per-transaction fee breakdown
- No public information on a licence, supervisor, register number or safeguarding of merchant funds
Best for
- You are adding an interest-free pay-in-3 option for shoppers online or in-store and want a documented reporting API behind it
- Your finance team's main requirement is tying each payout to its underlying orders and refunds through an API with date filters and pagination
- You want a low-friction start — signup is published at two minutes with zero documents
Avoid if
- Your markets need local payment methods — the captured pages name only Visa, Mastercard and AMEX funding the installment product
- You bill renewals from stored credentials — the only recurring flow shown is the shopper repaying Scalapay in three installments
- Your procurement requires a licence number, supervisor and funds-safeguarding terms before signing — we found no public information on any of these
The scores
| Criterion | Panel median |
|---|---|
| Payment methods & local coverage | 0.5 of 5 |
| Checkout, SCA & fraud | 0 of 5 |
| Subscriptions & recurring payments | 0 of 5 |
| Settlement, reconciliation & API | 2 of 5 |
| Licence, risk & account terms | 0.5 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 captured merchant page names the installment method plus Visa, Mastercard and Amex cards, available online and in-store, and I found no public information tying any method to countries or currencies, nor any mention of SEPA Direct Debit or named local methods like iDEAL or Bancontact. As a merchant I could not plan per-market conversion from this. 1
The E-Commerce Lead
The captured pages name one consumer method — interest-free payment in three installments — funded by Visa, Mastercard and AMEX cards, with no statement of which countries or currencies each method covers. We found no public information on SEPA Direct Debit, wallets, or any local method named per market, which is exactly what I need to plan conversion country by country. 1
The SaaS Founder
The captured pages show the interest-free 3-installment product funded by Visa, Mastercard and AMEX credit, debit or prepaid cards, offered online and in-store. We found no public information on SEPA Direct Debit, on any other local method, or on which countries and currencies each method serves. 1
The Payments Engineer
The captured pages name Visa, Mastercard and AMEX behind a three-installment plan, online and in-store — beyond that I found no public information on which countries and currencies each method serves, on SEPA Direct Debit, or on any local method per market. That is a method list I cannot plan a European rollout against. 1
The Compliance Officer
The captured vendor page lists Visa, Mastercard and AMEX cards alongside Scalapay's own pay-in-3 installment product, online and in store, with no statement of which countries and currencies each method covers. We found no public information on SEPA Direct Debit, wallets, or any local method named for a specific market. 1
The Skeptic
The only methods named are Visa, Mastercard and AMEX — credit, debit and prepaid — alongside the provider's own interest-free pay-in-3 product, online and in-store; we found no public information on which countries and currencies each covers, on wallets, or on SEPA Direct Debit and local methods such as iDEAL or Bancontact. 1
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
There is an integration API base URL and the method appears at checkout online and in-store, but I found no public information on hosted or embedded checkout options, 3-D Secure, SCA exemptions, declined-payment handling or fraud screening. The PCI scope implication of any integration type is likewise unstated. 1 2
The E-Commerce Lead
The only checkout statement on the captured pages is choosing "Pay in 3 installments" by Scalapay at the till. We found no public information on hosted versus embedded checkout, whether the payment stays on my domain, 3-D Secure, SCA exemption handling or fraud screening. 1
The SaaS Founder
The merchant page shows a checkout option for paying in three installments, but that is all that is evidenced. We found no public information on hosted versus embedded integration, 3-D Secure, SCA exemption handling, fraud screening, or what happens when a legitimate payment declines — which is where my failed renewals would live. 1
The Payments Engineer
The checkout evidence amounts to the customer choosing "In 3 Raten zahlen" by Scalapay at the till; I found no public information on 3-D Secure, SCA exemptions, hosted versus embedded integration, fraud screening or PCI scope. With the whole PSD2 path unevidenced, only the bare redirect is left to score. 1
The Compliance Officer
The only checkout statement is a selection prompt for the installment product at the merchant's checkout. We found no public information on 3-D Secure, SCA exemption handling, fraud screening, or the PCI DSS scope a merchant takes on with each integration. 1
The Skeptic
The pages describe checkout only as the customer selecting pay-in-3 at the till, with a developer integration endpoint behind it; we found no public information on 3-D Secure, SCA exemption handling, fraud screening or what happens to a declined payment. 1
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
The captured pages describe a pay-in-three product for the customer's own repayment and I found no public information on stored payment credentials, merchant-initiated transactions, SEPA mandate handling, subscription logic or dunning that a merchant could build recurring revenue on. 1
The E-Commerce Lead
We found no public information on stored payment credentials for merchants, merchant-initiated transactions, SEPA mandate handling, subscription plans or dunning; the captured pages describe only the consumer installment product. 1
The SaaS Founder
The only repeat-charge behaviour shown is the consumer side of the installment plan against a connected card. For a merchant running subscriptions we found no public information on stored payment credentials, merchant-initiated transactions, SEPA mandates, proration, dunning or any process for exporting payment tokens — I could not bill a renewal on what is published here. 1
The Payments Engineer
The only recurring mechanic in evidence is the customer repaying in three installments to the provider; I found no public information on card-on-file tokens, merchant-initiated transactions, SEPA mandates, subscription logic, dunning or token export. From a merchant's seat there is no evidenced recurring product here. 1
The Compliance Officer
We found no public information on stored payment credentials a merchant could charge again: merchant-initiated transactions, SEPA mandates, subscription plans, retries and dunning. The pay-in-3 schedule is the consumer's repayment arrangement with Scalapay, not a recurring-billing capability offered to the merchant. 1
The Skeptic
The installment product has the customer repaying the provider, not the merchant charging a stored credential; we found no public information on card-on-file tokens, merchant-initiated transactions, SEPA mandate handling, subscription plans, dunning or exporting tokens to another provider. 1
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 reporting API is real and reconciliation-shaped — payouts retrieved by date range, plus orders and refunds retrievable from a given payout — which is the one thing I can actually work with. But payout frequency and delay, per-transaction fee itemisation, webhooks, test mode and accounting exports are all silent on the captured pages, so I could not verify a payout against a bank statement or see what a fee was. 2 3
The E-Commerce Lead
The reporting API is genuinely buildable for finance: documented endpoints for orders, refunds and payouts, including orders and refunds linked to a given payout, with bearer authentication, pagination and date filters. However, we found no public information on payout frequency or delay, per-transaction fee itemisation, webhooks or a test mode. 2 3
The SaaS Founder
The reporting API is the solid piece: documented endpoints for orders, refunds and payouts, including per-payout listings of orders and refunds explicitly meant to reconcile bank transactions, with bearer-token authentication and pagination up to 5,000 items. We found no public information on payout frequency or delay, per-transaction fee breakdowns, webhooks, a test mode, or accounting exports. 2 3
The Payments Engineer
The reporting API is the strongest thing on offer: a versioned REST surface with orders, refunds, payouts and per-payout linkage endpoints, bearer auth, pagination and documented error codes — exactly the payout-to-transaction trail finance wants. But I found no public information on payout cadence, per-transaction fee breakdown, webhooks, a test mode, idempotency, rate limits or a status page, which keeps it short of anything I'd build month-end close on. 2 3
The Compliance Officer
The reporting API is documented with payouts, orders and refunds endpoints, including orders-from-payout and refunds-from-payout lookups that explicitly let a merchant reconcile bank transactions, with bearer-token authentication, date ranges and pagination. We found no public information on payout frequency and delay, settlement currencies, per-transaction fee breakdowns, webhooks, a test mode or a status page. 2 3
The Skeptic
The reporting API is real and documented — orders, refunds and payouts with pagination, date filters and API-key bearer auth, plus dedicated endpoints that pull the orders and refunds behind each payout for reconciliation. But the payout cadence is never stated, and we found no public information on per-transaction fee breakdown, webhooks, a test mode or accounting integrations. 2 3
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 captured pages name no regulator, licence type or register number, and I found no public information on safeguarding of merchant funds, reserve or rolling-hold limits with release timelines, freeze and termination terms, or a chargeback and dispute process. The only account statement captured is a two-minute signup requiring no documents, which tells me nothing about what happens on a bad day. 1
The E-Commerce Lead
The only entity information anywhere is the vendor name Scalapay S.p.A.; we found no public information on a licence, supervisor, register number, safeguarding of merchant funds, chargeback fees, or the terms that apply to freezes, reserves and termination. 1
The SaaS Founder
The Italian corporate form in the vendor name is the only signal about who stands behind the money. We found no public information on the regulated entity, its supervisor or licence, safeguarding of merchant funds, reserve or freeze conditions, chargeback fees and dispute process, or termination notice. 1
The Payments Engineer
The captured pages name Scalapay S.p.A. as the vendor and a two-minute, zero-document signup — and nothing else: I found no public information on a licence, supervisor, register number, safeguarding of merchant funds, chargeback fees, reserves or termination terms. Who holds my money on a bad day is entirely unevidenced. 1
The Compliance Officer
We found no public information naming a regulated entity, its supervisor or a licence register number, and nothing on safeguarding of merchant funds, reserves, freezes, termination notice, chargeback fees or a dispute process. The only account-related statement is a signup in two minutes with zero documents, which leaves a merchant unable to see who holds their money or on what terms. 1
The Skeptic
The entity Scalapay S.p.A. is named, which is more than nothing, but we found no public information on a licence number, supervisor, register link, safeguarding of merchant funds, chargeback fees, dispute process, or reserve, freeze and termination terms. A two-minute signup with zero documents is the only account-term statement the pages make. 1
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
No sovereignty attributes are on record for this vendor, and the captured pages give no statement on the contracting entity's licence or location, where payment and cardholder data are processed and stored, or any subprocessor list. There is nothing here to plan data flows or a DPA against. 1
The E-Commerce Lead
The independently sourced record carries no sovereignty attributes at all: we found no public information on which entity contracts, where payment and cardholder data is processed or stored, or which subprocessors are involved. 1
The SaaS Founder
We found no public information on where payment and cardholder data are processed or stored, on subprocessors, or on a data-processing agreement; no sovereignty attributes were independently sourced. The Italian corporate form of the vendor name is the only European signal, with nothing published on licensing or infrastructure locations to build on. 1
The Payments Engineer
No sovereignty attributes are on record: I found no public information on the contracting entity's licensing location, where payment and cardholder data are processed, or any subprocessor list. An Italian joint-stock company name is the only hint in the captures, and I do not score on hints. 1
The Compliance Officer
The vendor presents as an Italian joint-stock company, which is the only signal pointing to Europe on the captured pages. We found no public information on where transaction and cardholder data are processed and stored, on any subprocessor and its location, or on a data processing agreement distinguishing what the provider does as processor versus as controller. 1
The Skeptic
Independent sourcing returned no sovereignty attributes at all: we found no public information on where payment or cardholder data is processed or stored, no subprocessor list and no data processing agreement. The Italian corporate form in the vendor's name suggests an EU contracting entity, but the licence and the infrastructure behind it are unevidenced. 1
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
The only price statement captured is consumer-facing — pay in three installments without interest — and I found no public information on merchant rates, cross-border or currency conversion markups, chargeback, refund or payout fees, or any monthly fee or contract term. A merchant cannot begin to compute an effective cost from these pages. 1
The E-Commerce Lead
We found no public prices on any captured page — no merchant fee for the installment product, no chargeback or refund cost, no payout or monthly fee. An effective rate for my card and country mix is therefore not computable from public information. 1
The SaaS Founder
The captured page advertises a two-minute, zero-document signup and says installments carry no interest for the shopper, but we found no public fee figures at all — no merchant rate, no chargeback, refund or payout pricing, no monthly fee or contract term. A merchant cannot begin to compute an effective fee from what is published. 1
The Payments Engineer
The only price statement captured is consumer-facing — three installments "ohne Zinsen" — and I found no public information on merchant commission, cross-border or currency-conversion markups, or chargeback, refund and payout fees. A merchant cannot compute an effective rate from these pages at all. 1
The Compliance Officer
We found no public information on pricing of any kind — no merchant rate, cross-border or currency-conversion markup, chargeback, refund or payout fee, and no monthly minimum or contract term. A merchant cannot begin to compute an effective fee from what is published. 1
The Skeptic
The captured pages publish not a single number: no merchant rate, no chargeback, refund or payout fee, no monthly fee and no contract term. The effective cost of a transaction cannot be computed, or even estimated, from what is public — it is a sales conversation. 1
Questions about Scalapay
Is Scalapay European?
Not determined: the vendor’s pages as captured do not say where Scalapay is based.
Where does Scalapay store data?
Not stated on the vendor’s pages as of 20 Oct 2026.
Does Scalapay have a free plan?
Not stated on the vendor’s pages as of 20 Oct 2026.
What are the best alternatives to Scalapay?
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: Scalapay alternatives.
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 20 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 (scalapay.com, developers.scalapay.com/reference/get_v1-reporting-payouts, developers.scalapay.com/reference/get_v1-reporting-orders). 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 (scalapay.com, developers.scalapay.com/reference/get_v1-reporting-payouts, developers.scalapay.com/reference/get_v1-reporting-orders). If the vendor publishes it somewhere else, send us the page. Know more? Tell us
- 2 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
- 1 support 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 (3)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor page scalapay.com Checked 20 Oct 2026 Details →
- 2 Settlement, reconciliation & API — found from sitemap developers.scalapay.com Checked 20 Oct 2026 Details →
- 3 Settlement, reconciliation & API — found from sitemap developers.scalapay.com Checked 20 Oct 2026 Details →