For a funded startup, a payment provider is not a
vendor choice. It is a runway choice.
For a funded scale-up between €2–5M ARR and Series A diligence, the payment counterparty sits on the same balance sheet as the runway. A silent freeze, a rolling reserve rewritten mid-quarter or an agentic-transaction clause that lands with the wrong merchant of record does not show up in the Board pack as a payment issue. It shows up as runway spent on what was never just a vendor decision.
- 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
Three rooms inside the company decide whether the next quarter extends the runway or spends it.
A funded scale-up between €2–5M ARR is not scaling a payment stack. It is scaling the runway model underneath it. Three rooms inside the company deal with a payment provider before the next Board window: the CFO’s ledger, the founder-CEO’s Legal review and the CTO’s sprint plan. Each one has its own failure mode, and each one costs runway in a different currency.
An automated reserve rewrites the cash position before the Board reads it.
Structural causeAutomated portfolio-ratio events, dispute-ratio drifts, or algorithmically-sized rolling reserves on the settlement layer arrive without visibility into the funding calendar. The scoring system that produces them cannot see when the next tranche closes.
Commercial consequenceThe runway model that Finance walks into the Board with is rewritten mid-quarter. What was a working-capital position becomes a cash-visibility question. The CFO plans around the reserve rather than against it. The gap is not a fee negotiation. It is a governance question: who decides on a portfolio-ratio event, against what documented file, and where is that decision written down.
An agentic transaction posted against a card is a Legal question before it is a payment question.
Structural causeAutonomous and agentic transactions post charges without a rider or checkout session. On a US-centric platform, the merchant-of-record clause and the chargeback path default to the platform’s own ToS, and the balance-sheet exposure sits with the funded startup regardless of who initiated the charge.
Commercial consequenceLegal review at Series A diligence surfaces the exposure late. The Board risk committee reads a payment counterparty as a legal counterparty. The runway model absorbs a liability position that was never priced in. The question is not which platform is faster. The question is which regulatory boundary the merchant-of-record clause is written against.
An integration started before the underwriting answer spends a sprint on the wrong assumption.
Structural causeMost provider relationships open with a self-service signup and a sandbox before the underwriting decision has been made against the actual business. The engineering sprint is committed on the assumption the answer is Go, and the manual rejection arrives weeks in on processing-history requirements or regulatory-boundary reasons that never surfaced upfront.
Commercial consequenceThe lean team spent sprint capacity on an integration the underwriting file was never going to approve. The founder-CTO reallocates against a roadmap that was already tight. Runway is spent on rework, not on the product. The pre-commit fit-check is not a nice-to-have. It is the difference between a runway model that survives contact with underwriting and one that does not.
Three rooms, three ways to spend runway. The next section shows how a funded scale-up wins each one back.
A payment counterparty your team can take into Series A diligence and keep across three growth cohorts.
The three rooms from the section above are the three places where a different payment operator earns runway back for a funded scale-up. Not through faster processing, but through where the decisions sit, in whose hands, and on which regulatory footing. Below are the three counter-patterns.
Does the counterparty on your merchant contract hold its own licence?
DaoPay is licensed by the competent Austrian financial market authority as a payment institution, with 25+ years of operations and direct scheme memberships. The merchant contract sits with a payment institution licensed in Austria, not with an aggregator or a US-centric platform ToS. What the Board risk committee reads on the payment counterparty line matches what a Series A audit reads on the same line.
The regulatory footing is documented at the licence level, not at the marketing level. The merchant-of-record clause is written against the licence of a payment institution supervised in Austria, not against a platform’s terms of service. Card-scheme obligations sit with DaoPay under its own direct memberships. The scaling team carries one licence-scope statement into the Board pack, not a chain of intermediary references.
Are reserve position, payout rhythm and dispute-ratio treatment in the contract?
The reserve position is agreed on the record at onboarding. The payout rhythm is contractual, with T+1 where the business case supports it. Dispute-ratio treatment sits inside a documented file, handled by a named human. The CFO plans against these positions, not around them.
Portfolio-level and merchant-level decisions run through a named contact against a documented merchant file. There is no automated portfolio-ratio-based freeze on the runway model. Where a rolling reserve applies, it is a contractual position visible at signature, not a scoring-system output produced mid-quarter. The runway model that Finance walks into the Board with is the runway model that lands on the settlement layer.
Is the underwriting answer on the record before the sprint is committed?
The Free Onboarding PreCheck returns a Go, a Review or a No-Fit against the actual merchant file, in the first days, in writing from a named human. The engineering sprint is committed on an answer, not on an assumption. If the answer is No-Fit, the runway is not spent on the wrong integration.
The PreCheck runs the underwriting read against the real business first, and the outcome is written down before the sandbox opens. One integration follows, protocol-neutral, covering cards, European APMs, wallets and recurring under one master contract. The founder-CTO reallocates against a sprint plan the underwriting file already agreed with.
Three counter-patterns. The next section shows where DaoPay sits in the payment chain that connects them.
A scale-up’s payments don’t break inside a layer. They break at the handover between two.
DaoPay operates the payment chain that begins at the pre-authorisation on the scale-up’s side of a transaction and ends at the reconciliation line Finance reads at month-end. Between the two, one operator carries the settlement, the reporting and the reconciliation trail, so the handovers between them do not become the failure surface.
- Checkout
- Authorisation
- Capture
- Settlement
- Payout
- Finance ops
- Layer 1
ACCEPTANCE
Local payment methods, cards, wallets, tokenisationThe methods your customers 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 funded scale-up 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 Board window, not four weeks after the runway model has been rewritten.
Answer five short questions on the right. You get a Go, Review or No-Fit in the first days, so you don’t find the merchant-of-record clause after the first agentic transaction has posted, or a rolling reserve on the settlement layer, when the runway model 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.
The four functions that sign off on a payment counterparty before the Board reads the next diligence pack.
Four functions read a payment counterparty differently. Below is what each of them looks for at a funded scale-up, and how DaoPay answers it.
Where does the merchant-of-record clause actually sit for an autonomous or agentic transaction on DaoPay?
Inside a European regulatory boundary, on a licensed payment institution, in a merchant contract you signed with a European party.
An automated buying agent posting a transaction against a card creates a chargeback path and a liability path. On a US-centric platform, both paths default to the merchant of record inside the platform’s own ToS, and the balance-sheet exposure sits with the funded scale-up regardless of who initiated the charge. On DaoPay, the merchant of record is contracted with a payment institution licensed in Austria, so the chargeback path and the liability position are set in a European merchant contract rather than in a US-centric platform’s terms.
Ask any provider: which entity in your chain holds the licence the merchant-of-record clause is written against, and what happens to the chargeback path when an autonomous agent posts a wrong transaction inside your ToS?
How does DaoPay decide on a portfolio-ratio event or a rolling reserve, and who talks to whom when it happens?
A named human on a documented merchant file. Reserve positions are contractual, agreed on the record before signature.
The failure mode on an automated platform is a portfolio-ratio event or a dispute-ratio drift that returns as a silent freeze or an automatically sized rolling reserve, produced by a scoring system with no visibility into the funding calendar. On DaoPay, portfolio-level and merchant-level decisions are made against a documented file by a named human, and the reserve position, the dispute-ratio treatment and the payout rhythm are contractual positions agreed on the record at onboarding, so the CFO plans against them rather than around them.
Put this to any provider: on your rail, when a portfolio-aggregation event or a dispute-ratio drift arrives, who exactly makes the first call to the merchant, a status page, an escalation queue or a named human, and where is that decision written down?
What does the Free Onboarding PreCheck return, and what is it checked against?
A Go, a Review or a No-Fit against your real merchant file, in the first days, in writing from a named human.
Most provider relationships open with a self-service signup and a sandbox before the underwriting decision has been made against the actual business. The engineering sprint is committed on the assumption the answer is Go, and the manual rejection arrives weeks in, on processing-history requirements or regulatory-boundary reasons that never surfaced upfront. The Free Onboarding PreCheck runs the underwriting read against the real file first, and returns a Go, a Review or a No-Fit in writing from a named human, before the sprint is committed.
The question for any provider: before I commit a sprint to your integration, what underwriting decision can you give me in writing against my actual business, and at what stage in your process can that decision still change?
Request the Board Review Pack
Regulatory footing, merchant-of-record and liability position, portfolio-ratio and rolling-reserve mechanics, integration scope, and the PreCheck workflow. The substance a funded scale-up carries into the next diligence pack. Fill in four fields (name, role, company, email) and the pack opens straight away as a PDF in a new tab.