Payments built for the way
wie Ihr Unternehmen tatsächlich funktioniert.

Card acceptance covers most cases — not all. Where card ownership is low, or regulation or customer behaviour favours carrier-based billing, card-only checkout leaves a conversion gap that checkout optimisation can’t close.

DaoPay’s carrier-based methods:

• Voice Payment (IVR)
• Premium SMS billing (PSMS)
• Direct Carrier Billing (DCB)

Most relevant for telecom operators, digital media platforms and regulated digital channels — where the carrier relationship is already a trusted payment route.

EU-first, with selected international reach. Not every method is available in every configuration — availability is confirmed during the fit assessment, not assumed from a method name.

Relevant when — your business serves markets where carrier-based billing is established, or card-only checkout leaves part of your addressable audience outside the payment flow.

Recurring collections via SEPA Direct Debit are structurally more demanding than card transactions. A mandate must be created with the right pre-notification timing, maintained through amendments and cancellations, and reconciled against returns — and when return codes aren’t handled consistently, the burden lands on the finance team.

Mandate lifecycle — in the merchant portal

• eMandate creation
• eMandate amendment
• eMandate cancellation

Handling

Pre-notification

follows scheme timing.

Return codes

handling built into the agreement, not a merchant-side task.

The collection flow stays structured from the first mandate to the last return.

Use it standalone, or as part of a recurring setup that combines direct debit with other approved recurring methods.

How DaoPay approaches this — mandate administration run independently of the payment provider creates reconciliation gaps and audit exposure. DaoPay makes the mandate lifecycle part of the operating agreement, not a merchant-managed side process.

Not every customer wants to use a card. Some prefer prepaid instruments — for privacy, spending discipline or familiarity — and in some markets prepaid top-up is habitual, not an exception. Excluding them is a market-access problem, not just a checkout preference.

Available methods:

• Paysafecard
• Other selected prepaid and voucher-based methods

Configured only where they match:

• Merchant category
• Customer profile
• Market

Availability is use-case specific — evaluated against the merchant setup and confirmed during onboarding, not surfaced by default.

Worth raising early if you’re in digital goods, digital entertainment or content-driven services with established prepaid behaviour.

Relevant when — your customer base includes a segment that actively avoids card payments, or your market has established prepaid behaviour that card-only checkout would exclude.

Subscription businesses carry payment-layer risk that one-off processing doesn’t: credentials must be stored securely and used within scheme rules, retry logic must follow method-specific rules rather than a generic loop, and card data must not sit in the merchant environment expanding the team’s compliance perimeter.

Where the method supports it, recurring flows can combine:

• Card-on-file
• SEPA Direct Debit
• Approved recurring setups

Card data & scope

Card data

managed to PCI-DSS standards, designed to keep it out of the merchant environment.

Merchant scope

reduced, so there’s less for your team to manage directly.

Handled as part of the setup, not default checkout behaviour:

• Method rules
• Credential handling
• Retry logic

For complex subscription structures, multiple billing cycles or mixed recurring methods, the setup conversation should cover the full credential and method logic before integration begins.

What CFO and Compliance teams should notice — how credentials are handled at the payment layer affects what your team must certify and audit. A provider designed to keep card data out of your environment is worth evaluating carefully against your compliance workload.

ISO, PayFac, Referral and Reseller models aren’t variants of one contract. Commercial structure, technical setup, merchant onboarding and regulatory considerations differ in ways that matter before the first merchant goes live — a PayFac agreement doesn’t work cleanly for a Referral model, and vice versa.

Four partner models:

• ISO
• PayFac
• Referral
• Reseller

They differ across:

• Commercial structure
• Technical setup
• Merchant onboarding
• Regulatory considerations

Approach — DaoPay shapes the contracting and operating structure around the model, starting from how you bring merchants: the referral or processing relationship, the merchant profile and the markets involved.

The Onboarding PreCheck applies to the cases a partner brings forward. Partners who pre-qualify enter with a clearer merchant case and less friction; broad, unqualified portfolios create more complexity for both sides. DaoPay supports partners building a structured, sustainable processing relationship — not just volume.

Before you talk to us — be ready to describe your portfolio’s merchant types, their markets, and the processing volumes or categories involved. The more precisely you frame the merchant case, the more productive the fit assessment.

DaoPay gestaltet die Vertrags- und Betriebsstruktur entsprechend diesem Modell, ausgehend davon, wie Sie Händler gewinnen: über die Vermittlungs- oder Abwicklungsbeziehung, das Händlerprofil und die beteiligten Märkte.

Der Onboarding-PreCheck gilt für die von einem Partner vorgelegten Fälle. Partner, die die Vorqualifikation bestehen, können mit einem klarer definierten Händlerfall und weniger Reibungsverlusten einsteigen; umfangreiche, nicht qualifizierte Portfolios führen für beide Seiten zu einer höheren Komplexität. DaoPay unterstützt Partner beim Aufbau einer strukturierten, nachhaltigen Abwicklungsbeziehung – es geht nicht nur um das Volumen.

Automated scoring handles volume efficiently, but a system working from signals alone can’t always read context — and merchants with legitimate operational complexity get declined on an incomplete picture rather than a genuine risk finding.

DaoPay reviews applications with a human risk analyst, not only an automated score. The analyst weighs the full business case — model, market, category, transaction profile and regulatory context. It takes longer than a form submission, and produces a better-documented, accountable decision.

Three outcomes, each with reasoning:

Go

accepted; setup proceeds.

Review

not a rejection; a structured dialogue to find a workable path where one exists.

No-Fit

not the right counterpart; given with reasoning, protecting both sides.

At transaction level

Risk signals, 3-D Secure strategy and human oversight work together so payment decisions stay accountable at every layer. When disputes reach the scheme, representation support is available within the agreed operating model.

How this connects to onboarding — the Onboarding PreCheck is the first stage: before you commit to integration, DaoPay assesses fit. The risk review is the natural continuation of that qualification, not a separate gate that appears later.

Risikosignale, die 3-D-Secure-Strategie und die menschliche Überwachung wirken zusammen, sodass Zahlungsentscheidungen auf jeder Ebene nachvollziehbar bleiben. Wenn Streitfälle das Zahlungsverkehrssystem erreichen, steht im Rahmen des vereinbarten Betriebsmodells Unterstützung bei der Vertretung zur Verfügung.

Wie dies mit dem Onboarding zusammenhängt: Der „Onboarding PreCheck“ ist die erste Phase: Bevor Sie sich zur Integration verpflichten, prüft DaoPay die Eignung. Die Risikoprüfung ist die logische Fortsetzung dieser Qualifizierung und kein separates Hürdenverfahren, das erst später zum Tragen kommt.

Finance teams rarely get the full cost structure before the first settlement file arrives — blended rates obscure scheme fees, reconciliation files that don’t map to invoice lines create audit overhead, and settlement timing that’s never confirmed operationally creates cash-flow uncertainty at the worst moment.

DaoPay structures the settlement and reconciliation layer before go-live, not after.

Settlement

Timing and funding route are agreed upfront. Where the business case supports it, settlement runs T+1 with direct funding to your nominated account in covered acquiring categories.

Confirmed before go-live, so your finance team operates from a known structure:

• Timing
• Currency baseline
• Funding route

Reconciliation

Available at transaction, scheme-fee and payout level — through the merchant portal, scheduled export or API pull.

Every fee line visible

Shown separately per transaction, where the commercial setup supports it:

• Interchange++
• Scheme fee
• DaoPay margin

Line-by-line visibility for period close, audit preparation and operational cost review.

Blended pricing is available on request, for merchants whose volume and model support it.

What finance teams should ask before go-live — “Can you show me the settlement structure, timing and reconciliation format before we sign?” If a provider can’t answer clearly before onboarding, it won’t improve afterwards.

Zusätzliche Währungen, die über den Standardumfang hinausgehen, werden auf Anfrage im Rahmen der geschäftlichen Einrichtung bestätigt, sodass der Währungsbedarf bereits in der Vertragsphase eingeplant werden kann und nicht erst nach der Inbetriebnahme festgestellt wird.