When the next licence goes live, the payment portfolio either
goes live with it, or becomes its own project.
A method that renewed in one licensed market may not renew in the next. A reserve calculation that held in one jurisdiction may reset in another. And when the payment partner changes with the licence, so does the evidence chain Compliance carries into the next audit.
- CheckoutBuyer selects a method and confirms
- AuthorisationIssuing bank approves or declines in real time
- CaptureAuthorised amount is submitted for clearing
- SettlementFunds settle from the issuer to the acquirer
- PayoutMerchant receives cleared funds
Licensed Austrian Payment Service Provider and Acquirer with 25+ years of operation
Four business realities that show up on a multi-jurisdiction operator’s quarterly review, not on any provider dashboard.
The method-portfolio that renewed in one licensed market breaks quietly in the next.
Structural causeA method reviewed and accepted for the operator’s licence book in one jurisdiction may be out of scope for the next licence on file. Card rails renew on the existing contracts, local wallets and account-based methods often need a jurisdiction-specific scheme review, and some methods are simply out of scope for the licence being opened.
Commercial consequenceThe operator finds this out method by method during integration, running the review alongside the launch calendar instead of before it. Engineering weeks get spent again on the same rails across markets.
At the restricted gambling merchant category, scheme-level dispute-rate thresholds apply to the whole licence book.
Structural causeA dispute rate inside the scheme-level range in one licensed market can move outside it when the next market goes live and the exposure spreads across a broader operator profile.
Commercial consequenceThe threshold applies per operator, not per market, and it triggers monitoring programmes with structural cost. Pre-dispute interception matters because a cardholder query resolved upstream of a formal chargeback does not enter the count that scheme monitoring watches.
The evidence extract mapping deposits, withdrawals and holds to the segregation trail is often rebuilt after the auditor asks, not generated on demand.
Structural causePlayer funds must sit in segregated accounts at licensed EU credit institutions, operationally separate from the payment institution’s working capital. When the auditor asks for the segregation trail at renewal, the extract has to be reproducible in the format the regulator reads.
Commercial consequenceA trail rebuilt from a settlement report and a reconciliation spreadsheet after the request lands is not an audit-grade extract. Either Compliance hands the auditor one file, or the auditor waits.
Affordability thresholds shift by jurisdiction, and the payment side has to follow spend-level rules the operator has not yet integrated.
Structural causeFinancial vulnerability checks apply once a customer’s deposits minus withdrawals cross a threshold in a rolling window, and staged Financial Risk Assessment rollouts set separate spend thresholds for customers under 25 and customers 25 and over.
Commercial consequenceWhen the payment partner does not carry these thresholds into the transaction-level record, the operator’s compliance team has to rebuild them from raw settlement data instead of reading them straight from the payment file. The audit-extract format has to be reproducible before the assessment window closes.
Four questions any multi-jurisdiction operator should put to a payment partner before the next licence goes live.
Does one master agreement carry your method-portfolio across licensed markets, or is each market a new contracting round?
The 100+ payment methods across 72+ countries have to sit under one contracting surface, so that opening the next licensed market does not restart the contract-and-integration cycle from scratch.
One contracting surface means one master agreement, one commercial framework and one operational escalation path, not fifteen. When the next licensed market opens, the review runs against the operator’s licence scope in that market, not against a new commercial round. Methods that carry over on the existing contracts stay on them. Methods that need a jurisdiction-specific scheme review are flagged before the launch calendar is set, not after the integration work has started.
Does one API reconcile across your licensed jurisdictions with jurisdiction-tagged records, or does each market bring its own reconciliation shape?
Sandbox validates the integration end-to-end before production credentials are issued, and one API supports reconciliation across licensed jurisdictions with jurisdiction-tagged records at the transaction level.
The sandbox-to-production path has to validate the integration end-to-end before production credentials are issued: an operational gate the operator can run against the actual method-portfolio for the target market, not a documentation exercise. In production, one API supports reconciliation across the operator’s licensed jurisdictions with jurisdiction-tagged records at the transaction level, so the operator’s finance team reads one payment ledger instead of a set of parallel reports joined by hand before every close.
Is the evidence extract (segregation trail, identity-and-risk-review record, affordability-threshold log) reproducible on demand in the regulator’s format?
The audit-extract for the segregation trail, the identity-and-risk-review record and the affordability-threshold log is generated on request in the format the regulator reads, not reconstructed after the request lands.
The extract has to be reproducible in the regulator’s format, not in the payment partner’s default report format. That means the segregation trail maps deposits, withdrawals and holds at the transaction level, with the timestamps and identifiers the regulator’s audit format requires. The identity-and-risk-review record keeps the payment file aligned with the operator’s own compliance obligations. The affordability-threshold log carries the spend-level rules into the transaction file directly. Ask any provider: at renewal, how long between the request and the file, and in whose format?
At the restricted gambling merchant category, is your risk profile underwritten by a named person on the file, or by a scoring model with a status page?
The restricted merchant category for gambling requires human-underwritten risk assessment. A named person on the underwriting file, a written decision trail, a phone call when the numbers move.
Automated onboarding does not fit this merchant category. The underwriting is human and the file has a named person on it. When traffic, volume, dispute pattern or basket composition moves outside the profile the file already documents, that person opens a conversation: a call, a documented question, a written decision, instead of a scoring model closing the account and leaving the reason to be reconstructed afterwards. The trail is on file, not in a log.
The four criteria are what to check in the RFP. The layers below decide whether those answers hold up.
The payment chain that carries a licensed market is the chain that carries the next one.
DaoPay operates the payment chain from the multi-jurisdiction checkout to the evidence extract Compliance hands to the auditor. In between, one operator carries the method-portfolio across licensed markets, the dispute-rate exposure at the restricted merchant category for gambling, the segregated client funds under §17 ZaDiG 2018 and the identity-and-risk-review alignment under FM-GwG §6, which today sit across three provider boundaries. Two handovers stay visible: one at the acceptance boundary, where a new licensed market’s method mix enters the chain, and one at the audit boundary, where a regulator-reproducible evidence extract leaves it. DaoPay carries the operational weight between them, under one master contract.
- Checkout
- Authorisation
- Capture
- Settlement
- Payout
- Finance ops
- Layer 1
ACCEPTANCE
Local payment methods, cards, wallets, tokenisationThe methods your players use in each country, in the right currency and with the right authentication flow.
- Handover 1 · Acceptance → ProcessingWhere routing decisions set your capture rate
- Layer 2
PROCESSING
Routing, retries, capture, network communicationRouting per transaction across acquirers, with cascading retries when one path fails.
- Handover 2 · Processing → ReconciliationWhere settlement files meet your ledger, usually left to Finance
- Layer 3
RECONCILIATION & PAYOUT
Settlement matching, fee accounting, payout schedulingOne reconciliation feed across all methods and acquirers, with payouts on an agreed schedule.
Which layer owns each journey station, and the two handovers where multi-provider stacks break.
Not sure if a licensed operator fits our setup?
We built one page for each industry we know how to serve. Pick the one closest to your business, or use the visual guide below to see where your business fits.
Prefer a head start?Pick your industry below to see the journey built for it.
A fit answer before the next licensed market goes live, not after integration work has started.
Answer five short questions on the right. A human underwriter reads them. You get a Go, Review or No-Fit in the first days, so an underwriting mismatch, a segregation-evidence gap or a compliance-alignment question does not surface when the next licensed market is already integrated and the launch calendar is the only thing still open. Free Onboarding PreCheck: Go, Review or No-Fit.
Answer what you can, and anything you are unsure of can stay blank. Nothing is sent until you press the button.
Payments, Finance, Compliance and Platform each read this decision differently before the Board signs off on the next licensed market.
Payments reads the method-portfolio that has to carry into the next licensed market without a re-contracting round; Finance, the dispute-rate exposure on the licence book; Compliance, the identity-and-risk-review trail and the audit-extract format; Platform, the sandbox-to-production path and multi-jurisdiction reconciliation. Below is the short answer for each.
When the next licensed market goes live, which payment methods carry over and which have to be replaced?
The method-portfolio is reviewed against the operator’s licence scope in the target market before the launch calendar is set, so what carries and what has to be replaced is on the file before the integration work starts.
The review happens against the concrete licence scope in the target market, not against a generic method list. Card rails, local wallets and account-based methods each carry a different relationship to a new licensed jurisdiction: some renew on the existing contracts, some need a jurisdiction-specific scheme review, some are simply out of scope for the licence on the file. The output is a portfolio-level answer per licence, not a per-method conversation running in parallel to the launch calendar.
Because the review sits on one contracting surface, a method that already runs in one licensed market and remains in scope for the next one is not re-contracted, re-integrated or re-tested from scratch. The engineering weeks the operator would otherwise spend re-plumbing the same rails across markets stay available for the market-specific work that actually needs them.
Ask any provider: When we open a new licensed market, which of the methods we already run with you carry over on the existing contracts, and which ones will you need to re-scope, and by when?
Where do the segregated player funds sit, and how does the auditor get to the trail at renewal?
Client funds are held in segregated accounts at licensed EU credit institutions, and the evidence extract that maps deposits, withdrawals and holds to the segregation trail is reproducible on demand in the format the regulator reads.
The segregation is an account structure, not a policy statement: accounts at a licensed credit institution in the European Union, kept operationally separate from the payment institution’s own working capital. Deposits, withdrawals and holds against those funds are logged with the timestamps and identifiers the regulator’s audit format requires, at the transaction level rather than as a daily aggregate.
When renewal comes and the regulator asks for the trail, the extract is generated on request in the format the regulator reads, not reconstructed after the fact from a settlement report and a reconciliation spreadsheet. Compliance hands one file to the auditor, and the auditor reads it in the format they already expect.
A useful test for any provider: at renewal, when the regulator asks for the segregation trail, in what format does your evidence extract arrive, and how long between the request and the file?
What happens when something unusual moves on our account during a licence renewal window?
A named underwriter on the file, a written decision trail, and a phone call rather than a status page when the numbers move.
Merchants onboarded through the DaoPay portfolio have a named person on the underwriting file. When traffic, volume, dispute pattern or basket composition moves outside the profile the file already documents, that person opens a conversation: a call, a documented question, a written decision, instead of a scoring model closing the account and leaving the reason to be reconstructed afterwards. The trail is on file, not in a log.
For a licensed operator inside a renewal window, this is the difference between a renewal that keeps running while the profile is re-evaluated and a renewal that stops while someone tries to reach support. The mechanism is operational: a person, a phone number and a written record, applied to a restricted merchant category on the record.
Worth asking any provider: who is the named person on our file, and how is a decision on our account documented on your side when volume or dispute pattern moves during a renewal window?
The pack for the meeting.
Fill in your details and the Internal Review Pack opens straight away as a PDF in a new tab: a short document for the four functions that each read this decision from their own angle. Method-portfolio, dispute-rate exposure, identity-and-risk-review trail and sandbox-to-production path, in one file.