Payment
Unzer
EU origin, foreign-owned 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 Unzer Group GmbH · www.unzer.com
Compare with PAYONE → 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
Unzer, a Berlin-based payment provider, is strongest on licence and account terms, where the legal notice names Unzer E-Com GmbH as a BaFin-supervised payment institution under register number 122914 and lists Unzer S.A. with the CSSF under Z00000009, with complaint routes to both supervisors. Scores there spread 4-6, the bench's widest: one judge credited the licence numbers at 6, one dropped to 4 over the bad-day terms — no public information appears on safeguarding of merchant funds, reserves, termination notice or chargeback fees — with the rest at 5. Payment methods and recurring billing land at 0 with no spread: no method, country or currency is named, and nothing addresses stored cards or dunning. Checkout and SCA sits at 2 on PSD2 and PCI DSS claims with no documented flow, and settlement and reconciliation scores 1-2 on named developer documentation and a platform status page alone. Sovereignty scores 3: German and Luxembourg regulated entities contract, but data residency and subprocessors are unknown, and the vendor's own website runs on Netlify of San Francisco. Pricing publishes no figures; rates come via contact form.
Speaks for it
- Legal notice names Unzer E-Com GmbH as a BaFin-supervised payment institution under register number 122914 and lists Unzer S.A. with the CSSF under Z00000009.
- Complaint routes to BaFin and CSSF are published, alongside a Danish FSA registration under number 22006.
- Developer documentation, a help centre and a platform status page are named among support resources.
- PSD2 strong customer authentication and PCI DSS compliance are claimed on the pricing page.
- Shopify integration is offered.
Held against it
- We found no public information naming any payment method, country or currency, though the pricing page invites flexible method selection.
- We found no public information on stored cards, SEPA mandates, subscription logic or dunning for repeat charges.
- We found no public information on payout schedule, settlement currencies or per-transaction fee breakdowns.
- We found no public information on safeguarding of merchant funds, reserves, termination notice or chargeback fees.
- We found no public information on where payment and cardholder data are processed or on payment subprocessors, while the vendor's own website is hosted by Netlify in San Francisco, runs US analytics tools, and carries a privacy notice that the USA is not a safe third country under EU data protection law.
Best for
- You need a provider whose regulated entities and supervisor complaint routes are published up front, such as BaFin register number 122914 and CSSF number Z00000009.
- You prefer consultation-led setup, with personal consulting, fast onboarding and integration without programming skills listed as always included.
- You run your shop on Shopify and can buy through an individual quote.
Avoid if
- You sell subscriptions, since recurring billing scored 0 with nothing published on stored cards, SEPA mandate handling or dunning.
- You must verify payment-method coverage per market before committing, as no method, country or currency is named publicly.
- Your finance team plans on published payout schedules, settlement currencies and fee breakdowns, and we found no public information on any of these.
- You require documented payment-data residency and a subprocessor list before signing, given the San Francisco website hosting and US analytics tools shown on the captured pages.
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
We found no public information naming any payment method, let alone which countries and currencies each one covers — the pricing page says only that a POS merchant can 'flexibel' choose which payment methods to offer. A merchant could plan acceptance in no market from these pages. 2 1
The E-Commerce Lead
The pricing page tells merchants they can choose flexibly which payment methods to offer, but no method is ever named — we found no public information on cards, wallets, SEPA Direct Debit or a single local method, let alone which country each one serves. For someone who needs iDEAL named for the Dutch market and Bancontact for Belgium before planning a rollout, this gives me nothing to plan conversion against. 2
The SaaS Founder
The pricing page tells merchants they can "choose flexibly which payment methods" to offer, but no method is named on the captured pages — we found no public information on which methods, countries or currencies a European customer could actually pay with, including whether SEPA Direct Debit is supported at all. 2
The Payments Engineer
The captured pages name no payment method at all — no card scheme, no SEPA Direct Debit, no local method — only a POS offer where the merchant picks 'flexibly' which methods to accept. With no list of methods and nothing on the countries or currencies each covers, I cannot judge per-market coverage; the licence in the legal notice tells me nothing about what a customer in any given country can actually pay with. 2 4
The Compliance Officer
The captured pages name no payment method at all: the pricing page says merchants can "wähle flexibel, welche Zahlungsmethoden Du anbieten möchtest" without naming a single one, and we found no public information on which cards, wallets, SEPA Direct Debit or local methods are covered in which countries. Judged as not evidenced. 2
The Skeptic
The pricing page invites the merchant to "choose flexibly which payment methods" they want to offer, yet it names not a single method, country or currency — we found no public information on the method list at all. A buyer cannot plan which markets they can serve from anything captured here. 2
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 pricing page carries PSD2 strong customer authentication and PCI DSS compliance claims and an FAQ question on fraud protection in online trade, but we found no public information on hosted or embedded checkout options, 3-D Secure handling, SCA exemptions or how the fraud screening actually works. That is a compliance badge, not a documented authorisation path. 2
The E-Commerce Lead
PSD2 strong customer authentication and PCI DSS appear as compliance bullets on the pricing page, and an FAQ asks whether Unzer protects against fraud in online trade, which is more than silence on SCA. But we found no public information on hosted versus embedded checkout, 3-D Secure handling, exemption strategy or authorisation rates, so I cannot judge what my checkout conversion would look like. 2
The SaaS Founder
The pricing page carries PSD2 strong-customer-authentication and PCI DSS badges and raises fraud protection as an FAQ question, which is more than silence. But we found no public information on hosted or embedded checkout options, SCA exemption handling, or what happens when a legitimate payment declines — the thing that decides my conversion. 2
The Payments Engineer
The pricing page claims 'PSD2 - Starke Kundenauthentifizierung' and 'PCI DSS - Datensicherheit' and raises fraud protection as an FAQ question, which is more than silence on SCA and fraud. But the captured pages describe no checkout types, no 3-D Secure flow, no exemption handling and no PCI scope per integration type, so there is nothing here I could integrate or test against. 2
The Compliance Officer
PSD2 strong customer authentication and PCI DSS appear as a single line on the pricing page, and fraud protection in online trade is raised as an FAQ question, but we found no public information on checkout integration types, 3-D Secure handling, SCA exemptions or declined-payment flows. A mention of the regulatory layer without any engineered detail is worth little more than nothing here. 2
The Skeptic
PSD2 strong customer authentication and PCI DSS appear as two words on the included-features list and fraud protection gets a FAQ question with no detail; we found no public information on checkout flows, SCA exemptions or declined-payment handling. That is a checkbox, not an engineered authorisation path a merchant can verify. 2
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
We found no public information on stored cards, SEPA Direct Debit mandates, subscription logic, dunning or whether payment tokens can ever be exported to another provider. Nothing on the homepage or pricing page addresses charging the same customer twice. 1 2
The E-Commerce Lead
The included-services list covers personal consulting, onboarding and integration without programming skills, and we found no public information on card-on-file tokens, SEPA mandate handling, subscription logic or dunning anywhere in the captured pages. For a business with repeat charges, every recurring-payment question stays unanswered here. 1 2
The SaaS Founder
For a subscription business this is the make-or-break surface and the captured pages say nothing about it: we found no public information on stored cards, SEPA mandate handling, subscription logic, dunning, or whether payment tokens can ever be exported to another provider. A provider that keeps the tokens keeps my customer base hostage, and there is nothing published here to say otherwise. 1 2
The Payments Engineer
We found no public information on stored payment methods, merchant-initiated transactions, SEPA mandate handling, subscription logic, retries, dunning or token export on any captured page. Nothing here evidences that the same customer can be charged twice without re-entering payment details. 1 2
The Compliance Officer
We found no public information on stored payment methods, merchant-initiated transactions, SEPA mandate handling, subscription plans or dunning anywhere on the captured pages; even the included-services list on the pricing page is silent on repeat charges. Every element of this capability is unevidenced. 2
The Skeptic
We found no public information on stored payment methods, card-on-file charges, SEPA mandates, subscription logic or dunning on the captured pages. For a merchant selling subscriptions there is nothing here to evaluate. 2
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 schedule, settlement currencies and any per-transaction fee breakdown are absent from the public pages, so there is nothing to reconcile against a bank statement. The only finance-relevant signal is that a developer documentation set and a platform status page are named among support resources. 2
The E-Commerce Lead
The pages point to developer documentation and a platform status page, so an API presumably exists, but we found no public information on payout cadence, settlement currencies, per-transaction fee breakdowns, webhooks or reports tying payouts to transactions. My finance team cannot design a reconciliation process from what is captured. 2
The SaaS Founder
Footer links to developer documentation, a help centre and a platform status page suggest an API exists, which is more than nothing. But we found no public information on payout schedule or currencies, per-transaction fee breakdowns, or reports that tie a payout to its transactions — my finance team could not close a month on this. 2
The Payments Engineer
A developer documentation section, a help centre and a platform status page are named among the support resources, and I want to credit a named status page. But the captured pages give no payout schedule, no per-transaction fee breakdown, no reconciliation reporting, and nothing on API versioning, idempotency keys, webhooks or a test mode — link names are not something finance can close a month on. 2 4
The Compliance Officer
Developer documentation and a platform status page are named as resources, which is the only signal an API exists, but we found no public information on payout schedules or currencies, per-transaction fee breakdowns, or reports linking payouts to their transactions. A finance team cannot plan on any of this. 2
The Skeptic
Links to developer documentation and a platform status page are listed, which is more than nothing, but we found no public information on payout cadence, settlement currencies, per-transaction fee breakdowns or reconciliation exports. The finance side a treasury team needs is invisible to a buyer. 2
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 legal notice is unusually complete on entities: Unzer E-Com GmbH as a BaFin-supervised payment institution under register number 122914, a Luxembourg payment institution CSSF-listed as Z00000009, a Danish registration with FSA number 22006, and published complaint addresses for BaFin and CSSF. But we found no public information on safeguarding of merchant funds, reserve or rolling-hold limits, chargeback fees or termination notice periods — the bad-day terms are exactly what is missing. 4
The E-Commerce Lead
The legal notice is unusually concrete on the regulated chain: Unzer E-Com GmbH is named as a payment institution supervised by BaFin under register number 122914, a Luxembourg entity is listed with the CSSF under number Z00000009, and complaint routes to both supervisors are published. The bad-day terms are missing though — we found no public information on safeguarding of merchant funds, reserve or hold conditions, termination notice, or chargeback fees and dispute timelines. 2 4
The SaaS Founder
The legal notice is unusually complete on who holds the money: Unzer E-Com GmbH named as a BaFin-supervised payment institution under register number 122914, Unzer S.A. on the CSSF list under Z00000009, plus complaint routes to both supervisors. The bad day is open — we found no public information on safeguarding of merchant funds, reserve or freeze conditions, chargeback fees or termination notice periods. 2 4
The Payments Engineer
The legal notice is unusually complete on the regulated side: Unzer E-Com GmbH is named as a BaFin-supervised payment institution with register number 122914, Unzer S.A. is listed with the Luxembourg supervisor under Z00000009, a Danish registration with FSA number 22006 is published, and complaint routes to BaFin and CSSF are given. We found no public information on the merchant-funds side — safeguarding of funds, reserves, freezes, termination notice, chargeback fees or a dispute process — so the bad-day terms stay unwritten in what I can see. 4 2
The Compliance Officer
The legal notice names Unzer E-Com GmbH as a payment institution under ZAG supervised by BaFin with register number 122914, and Unzer S.A. as CSSF-registered in Luxembourg under number Z00000009, with registry entries for each group company and complaint addresses for both supervisors — exactly the identification I insist on. The bad-day side is absent: we found no public information on reserves, fund freezes, termination notice, safeguarding of merchant funds or chargeback fees on the captured pages. 4
The Skeptic
The imprint is unusually forthright: Unzer E-Com GmbH is named as a BaFin-supervised payment institution with register number 122914, the Luxembourg entity carries CSSF number Z00000009, and complaint routes to BaFin and CSSF are published. But the bad-day terms are what I read for, and we found no public information on reserves, fund freezes, termination notice or chargeback fees — the licence numbers earn the points, the silence on the rest caps them. 4 2
European sovereignty
panel opinion
Show reasoningHide reasoning
How this is scored
Who the contracting and regulated entity is, and where transaction and cardholder data are processed and stored. Independently sourced by the sovereignty pipeline. The card schemes are US-based for every provider, so the scheme layer is not held against any one vendor; the part the vendor controls is.
0 — Non-EU contracting entity, no statement on where payment data is processed, and subprocessors unnamed.
3 — An EU licensed entity contracts, but payment and customer data is processed outside the EU by default without an explained safeguard, or the subprocessor list is absent.
5 — EU contracting and regulated entity, EU processing stated for core payment data, but the group parent or significant parts of the chain (fraud scoring, support, analytics) are non-EU without a stated safeguard.
8 — EU entity and EU licence, payment and cardholder data processed and stored in the EU on named infrastructure, subprocessor list published with locations, and a DPA covering the processing the provider does as processor versus as controller.
10 — Sovereign end to end and evidenced: European ownership, EU entity and licence, every processing location and subprocessor European, European rails (SEPA, Wero or national schemes) offered alongside cards, and certifications published.
The Finance Lead
The group and its regulated entities are German, Luxembourg, Austrian and Danish, yet the privacy policy shows the website hosted by Netlify in San Francisco with Google, Facebook, LinkedIn and Microsoft analytics attached and a warning that the US is not a safe third country. There is no statement of where payment and cardholder data are processed and no subprocessor list for the payment chain. 3 4
The E-Commerce Lead
German and Luxembourg entities with EU licences do the contracting, which is the part I can verify, but we found no public information on where transaction and cardholder data are processed or on any subprocessor list for the payment chain. The only concrete hosting fact on the captured pages concerns the vendor's own website, hosted by Netlify in San Francisco and running US analytics tools including Google and Facebook — and the provenance record flags majority ownership by a US private equity firm. 3 4
The SaaS Founder
German and Luxembourg licensed entities contract with the merchant, which is the right starting point. But we found no public information on where payment and cardholder data are processed or which subprocessors are involved, and the vendor's own website runs on Netlify in San Francisco — with a notice that the USA is not a safe third country under EU data protection law. 3 4
The Payments Engineer
Contracting and regulated entities are European — Berlin, Heidelberg, Luxembourg, Vienna — and the EU online dispute platform is referenced. But we found no public information on where payment and cardholder data is processed or stored, or on a payment subprocessor list, while the captured privacy policy puts the website itself on a San Francisco host under a notice that the USA is not a safe third country, with US analytics tools running in the tag manager. 3 4
The Compliance Officer
The contracting and regulated entities are German and Luxembourgish with EU supervisors, but we found no public information on where transaction and cardholder data are processed or stored, and no subprocessor list for the payment chain; the privacy policy names only the website's own host, Netlify Inc. of San Francisco, alongside Google, Facebook and Microsoft analytics tools, with a notice that the USA is not a safe third country. The group is also recorded as majority-owned by US private equity firm KKR, so I see no statement of European control anywhere in the payment chain. 3 4
The Skeptic
The contracting and licensed entities are German and Luxembourgian, yet the vendor's own site runs on Netlify of San Francisco with Google, Facebook, LinkedIn and Microsoft trackers, and the privacy notice itself concedes the USA is not a safe third country. We found no public information on where payment and cardholder data are processed, on the group's ownership, or on which subprocessors the payment chain uses. 3 4
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 pricing page publishes no figures at all: an 'All-in-One' price and a custom offer both route to an individual quote via contact form, so every rate is a sales conversation. A finance lead cannot compute an effective fee for any card, country or method mix from public pages. 2
The E-Commerce Lead
The pricing page offers an all-in-one price or a customised quote but shows no numbers at all — every rate runs through a contact form and personal consultation. I cannot compute an effective fee for my card, country and method mix from public pages, so the pricing model is a sales conversation by design. 2
The SaaS Founder
There are no prices on the pricing page: it pitches an "All-in-One" price and a custom offer with services "always included", and every actual rate comes through a contact form. For my card and country mix the effective fee is a sales conversation, so I cannot budget a single renewal against it. 2
The Payments Engineer
The pricing page carries no figures at all — an 'All-in-One' package and an individual quote via contact form — so there is not even a headline rate, let alone cross-border, currency conversion or chargeback costs. Every rate is a sales conversation, which makes the effective fee for any merchant mix unknowable from public pages. 2
The Compliance Officer
There are no public prices at all: the pricing page offers an "unkomplizierten All-in-One-Preis" or an individually tailored quote via contact form and lists what is always included, but no rate, fee or contract term appears on the captured pages. A merchant cannot compute any effective fee from what is published. 2
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 | Incorporated in DE ⚠ unverified | 3/3 pts | 4 Report an error |
|---|---|---|---|
| Ownership | Not determined | — | uncited Report an error |
| Data residency | Not determined | — | uncited Report an error |
| Subprocessors | Not determined | — | uncited 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 — Legal entity. The imprint is a joint web presence of group entities also registered in Austria, Luxembourg and Denmark, but the declared website operator (Betreiber) is the German Unzer Group GmbH.
- 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.
- 33 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
- 9 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
- 4 integrations facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 3 legal facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 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
- 6 of the readings below were written against an earlier fact sheet — a fact has been corrected, added or pulled since. Until the panel next runs on this product you are reading the older judgement. Know more? Tell us
Sources (15)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor homepage www.unzer.com Checked 22 Sep 2026 Details →
- 2 Pricing page www.unzer.com Checked 22 Sep 2026 Details →
- 3 Privacy policy www.unzer.com Checked 22 Sep 2026 Details →
- 4 Legal notice www.unzer.com Checked 22 Sep 2026 Details →
- 5 Security / trust page www.unzer.com Checked 30 Sep 2026 Details →
- 6 Payment methods & local coverage — found from sitemap help.unzer.com Checked 1 Oct 2026 Details →
- 7 Payment methods & local coverage — found from sitemap help.unzer.com Checked 1 Oct 2026 Details →
- 8 Checkout, SCA & fraud — found from sitemap www.unzer.com Checked 1 Oct 2026 Details →
- 9 Checkout, SCA & fraud — found from sitemap www.unzer.com Checked 1 Oct 2026 Details →
- 10 Subscriptions & recurring payments — found from sitemap www.unzer.com Checked 1 Oct 2026 Details →
- 11 Subscriptions & recurring payments — found from sitemap www.unzer.com Checked 1 Oct 2026 Details →
- 12 Settlement, reconciliation & API — found from sitemap help.unzer.com Checked 1 Oct 2026 Details →
- 13 Settlement, reconciliation & API — found from sitemap help.unzer.com Checked 1 Oct 2026 Details →
- 14 Licence, risk & account terms — found from sitemap www.unzer.com Checked 1 Oct 2026 Details →
- 15 Licence, risk & account terms — found from sitemap www.unzer.com Checked 1 Oct 2026 Details →